Vercel 遭第三方 AI 工具入侵,IPO 前夕遇安全危机

Vercel 因第三方 AI 工具 OAuth 风险遭入侵,环境变量与开发者供应链安全再次成为焦点。

原文标题:靠“AI 云”爆红的 Vercel,栽在一个第三方AI工具手里!IPO前夕遭黑,200万美元赎金谈崩?

原文作者:AI前线

冷月清谈:

Vercel 近日确认发生安全事件,称未经授权人员访问了部分内部系统。官方披露,入侵源头并非 Vercel 核心系统被直接攻破,而是与一款第三方 AI 工具 Context.ai 相关,其 Google Workspace OAuth 应用遭入侵后,攻击者借由员工账号进一步进入 Vercel 内部环境。

攻击者据称获取了部分员工信息、内部系统访问线索、环境变量、API 密钥及部署相关权限,并在黑客论坛兜售数据。Vercel 表示客户服务未受影响,仅少量客户受到数据泄露影响,Next.js、Turbopack 等开源项目未受影响。目前 Google Mandiant 团队正协助调查。

事件焦点集中在“非敏感环境变量”管理上。Vercel 称敏感环境变量具备静态加密保护,但未被标记为敏感的变量可能被枚举并导致权限扩大。官方建议开发者检查环境变量、轮换密钥,并启用敏感变量功能。

这起事件也引发对第三方 AI 工具、OAuth 授权、开发者基础设施供应链安全的关注。Vercel 正值 IPO 前夕,外界还传出攻击者曾索要 200 万美元赎金,相关影响仍在调查中。

怜星夜思:

1、如果公司大量使用第三方 AI 工具,应该怎么判断哪些工具“能接入内部系统”,哪些只能当普通外部服务用?
2、环境变量里到底哪些内容应该标记为敏感?很多团队是不是低估了“看起来不敏感”的配置?
3、这类 OAuth 供应链攻击越来越多,企业是应该减少授权集成,还是加强监控和权限治理?
4、Vercel 这次事件会不会影响开发者对“前端云平台”和自动化部署平台的信任?

原文内容

整理 | 华卫

近日,支撑数百万生产部署、默默承载代码与用户之间底层连接的云平台 Vercel 遭到入侵,有威胁行为者宣称攻击了其系统,并试图出售窃取的数据。作为面向开发者提供托管与部署基础设施的云平台,Vercel 尤其专注于 JavaScript 框架生态,因开发广泛使用的 React 框架 Next.js 而知名,同时还提供无服务器函数、边缘计算、CI/CD 流水线等服务,帮助开发者构建、预览和部署应用程序。

昨晚,Vercel 在社交平台 X 上发布声明,确认了这起 “安全事件”,称“有未经授权的人员访问了 Vercel 部分内部系统”。该公司表示,攻击者是通过一个被入侵的第三方 AI 工具实施入侵,与 Google Workspace OAuth 应用相关联。

在此之前,一名自称是近期入侵 Rockstar Games 幕后组织 ShinyHunters 成员的人士在一个黑客论坛上发帖,称从 Vercel 窃取了访问密钥、源代码、数据库数据以及内部部署环境访问权限和 API 密钥。他在帖子中写道:“这只是来自 Linear(Vercel 内部的项目管理工具)的证明材料,但我即将给你的访问权限包括多个员工账户,可访问多个内部部署系统、API 密钥(包括部分 NPM 令牌和 GitHub 令牌)。”

该威胁行为者还公开了一份包含 Vercel 员工信息的文本文件,共计 580 条数据记录,包括姓名、Vercel 邮箱、账号状态及操作时间戳。此外,他还发布了一张疑似 Vercel 企业版内部管理后台的截图。有报道称,与 ShinyHunters 核心团伙有关联的人员已否认参与此事。

入侵源头是 Context.ai,
谷歌 Mandiant 团队正协助调查

在安全公告中,Vercel 表示,此次事件源于一款第三方 AI 工具,该工具的 Google Workspace OAuth 应用被攻破,可能影响数百个机构的大量用户。并且,Vercel 公布了相关威胁指标(IOC),以协助业界排查环境中可能存在的恶意行为,如下:

OAuth 应用:110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

随后,Vercel 首席执行官 Guillermo Rauch 在 X 上披露了更多细节,详细说明了攻击者的入侵路径。据称,攻击者最初的突破口是一名 Vercel 员工的 Google Workspace 账号,该员工所使用的 AI 平台 Context.ai 遭到入侵,导致其账号被攻陷。攻击者在获取该员工账号权限后,进一步提升权限渗透进入了 Vercel 自身的系统环境,访问了未被标记为敏感、因此未进行静态加密的环境变量。

通常,环境变量中存放着 API 密钥、私有 RPC 端点、部署凭证等机密信息。Rauch 表示,“Vercel 对所有客户环境变量均采用完整静态加密存储,我们拥有多层纵深防御机制保护核心系统与客户数据。但我们确实提供将环境变量标记为‘非敏感’的功能,不幸的是,攻击者正是通过枚举这些非敏感变量,获得了更高权限的访问。”

“我们认为该攻击组织技术水平极高,并且我高度怀疑,AI 极大地提升了他们的攻击效率。Rauch 补充道,攻击者行动 “速度惊人,且对 Vercel 有着深入的了解”。据了解,Context.ai 由前谷歌高管创办,专注于 AI 模型评估与分析,其核心产品为模型数据洞察仪表板。

但 Vercel 称,其服务未受影响,仅有少量客户受到此次数据泄露影响,目前正与受影响客户协同处理。同时,该公司已对其供应链进行排查,确认 Next.js、Turbopack 及其他开源项目均未受影响,保持安全。Vercel 已对管理后台推送更新,包括新增环境变量总览页面,以及优化敏感环境变量的管理界面。

“我们正在展开积极调查,并已聘请事件响应专家协助调查与修复工作。我们已通报执法部门,并将随着调查进展更新本页面信息。”据悉,谷歌 Mandiant 团队正协助调查,Vercel 也已联系 Context.ai,以确定此次事件的完整影响范围。

Vercel 正采取措施保护用户,并强烈建议开发者检查环境变量中是否包含敏感信息,并启用平台敏感环境变量功能,在必要时轮换密钥等敏感凭证,确保相关数据实现静态加密。同时,Vercel 提醒所有 Google Workspace 管理员及谷歌账号用户,立即检查该应用的使用情况,排查可疑行为。

影响范围太广,
可能引发连锁式暴露

针对此次事件,软件开发社区知名开发者 Theo Browne 在 X 上表示,据其消息源透露,Vercel 内部集成的 Linear 和 GitHub 系统是受影响最严重的部分。他指出,Vercel 中标注为敏感的环境变量均受到安全保护;未被标记的其他变量则必须进行轮换,以防遭遇相同风险。该建议也与 Vercel 官方给出的指引一致,即建议客户检查环境变量并启用平台的敏感变量功能。

“这种方式很可能被用来打击除 Vercel 以外的多家公司。”Browne 称。

从数据规模也能看出这次事故带来的影响之大。Vercel 为数千家企业托管应用,涵盖个人开发者、初创公司和世界 500 强企业,他们利用该平台在全球边缘网络部署 Next.js 应用、静态站点和无服务器功能。这类基础设施一旦被攻破,就会引发连锁式的安全暴露。根据发表在 IEEE Xplore 上的研究,开发者基础设施的安全漏洞会在多个系统中对消费者数据造成连锁风险。研究强调,平台层面的泄露可能导致敏感信息在初始目标之外的广泛暴露。

使用 Vercel Pro 和 Enterprise 套餐的企业客户可能面临最高风险,因为这些账户通常包含更敏感的项目数据、自定义域配置以及第三方服务的集成凭证。那些将 GitHub、GitLab 或 Bitbucket 仓库连接到 Vercel 进行自动化部署的组织,如果攻击者获得了存储的认证令牌,其源代码仓库可能会被暴露。

在 Vercel 平台上存储环境变量、API 密钥和数据库连接字符串的开发团队尤其值得关注。对许多开发团队来说,这些数据代表了他们生产系统的关键。如果这些凭证被泄露,攻击者可能获得远超 Vercel 平台的后端系统、数据库和外部服务访问权限,篡改构建流程、注入恶意代码,进而实施更广泛的攻击。

使用 Vercel 免费套餐的个人开发者虽然可能目标更少,但仍面临个人项目暴露和账号被接管的风险。该平台与流行的开发工具和服务的集成意味着被攻破的账户可能成为针对开发者生态系统更广泛攻击的跳板。

但更深远的影响不止于 Vercel 本身,所有使用第三方 AI 工具进行代码生成、数据分析或自动化运营的公司,现在都必须面对同一个问题:哪些服务商可以访问哪些系统,对应的安全验证机制又是什么?

目前尚不清楚此次入侵的渗透深度,也不确定是否有客户部署的应用遭到篡改。Vercel 表示调查仍在持续,将在获取更多信息后向相关方通报,并会直接联系受影响客户。

IPO 前夕被攻击,
200 万美元赎金谈判未果?

值得一提的是,这次入侵发生在 Vercel 的关键时刻。据外媒报道,在营收激增 240% 后,该公司正准备进行首次公开募股 (IPO)。

Vercel 一直将自身定位为面向开发者的 “AI 云平台”,大力推广深度 AI 集成能力。而或许正是这一定位,让它沦为了攻击目标。这起事件在云开发领域引发高度担忧,因为 Vercel 凭借其广受欢迎的前端部署平台,服务着全球数百万开发者。Vercel 在开发流程中处于特殊位置,是许多初创公司和成熟公司用来构建、测试和部署应用的基础设施层。这种级别的泄露不仅暴露了 Vercel 自己的数据,这可能会暴露成千上万信任该平台部署流程的开发团队的下游应用和服务。

更重要的是,此次泄露事件也引发了对 Vercel 安全措施和监控能力的质疑。在安全研究人员发现黑客在试图兜售据称窃取的数据、并出现可疑活动后,Vercel 才意识到系统可能已遭入侵。并且,从该公司最初披露的消息来看,攻击者在被发现前维持访问权限的时间尚不明确。入侵发生与被发现之间的间隔至关重要:攻击者访问时间越长,能泄露的数据越多,对下游系统造成的损害也越大。网络安全事件响应研究表明,消除安全漏洞的长期后果需要立即采取行动,以防止连锁反应在连接系统中蔓延。

不过需要说明的是,攻击者并未直接攻击 Vercel,而是利用了关联 Google Workspace 的 OAuth 访问权限。这类供应链漏洞的确更难被察觉,因为它依托的是受信任的集成服务,而非明显的系统漏洞。近期也有多起域名劫持事件导致用户被跳转至仿冒恶意网站,造成钱包资产被盗。但这类攻击通常发生在 DNS 或域名注册商层面,一般可通过监控工具快速发现异常。托管层入侵则截然不同。攻击者不会将用户导向钓鱼网站,而是直接修改真实的前端代码。用户访问的是合法域名,却加载了恶意代码,对此毫无察觉。

在 Telegram 上分享的信息中,威胁行为者声称已就此事与 Vercel 方接触,双方曾就 200 万美元赎金进行过谈判。无论之后此事如何发展,该公司当前都迫切需要转入防御姿态向投资者展示其稳定性。据传,Netlify 和 Render 等竞争对手正在联系 Vercel 的客户,将其平台定位为更安全的选择。

参考链接:

https://vercel.com/kb/bulletin/vercel-april-2026-security-incident

声明:本文为 AI 前线整理,不代表平台观点,未经许可禁止转载。

会议推荐

世界模型的下一个突破在哪?Agent 从 Demo 到工程化还差什么?安全与可信这道坎怎么过?研发体系不重构,还能撑多久?

AICon 上海站 2026,4 大核心专题等你来:世界模型与多模态智能突破、Agent 架构与工程化实践、Agent 安全与可信治理、企业级研发体系重构。14 个专题全面开放征稿。

诚挚邀请你登台分享实战经验。AICon 2026,期待与你同行。

今日荐文

图片

你也「在看」吗?👇

哥们要是Vercel的技术负责人,第一件事就是亡羊补牢,全面排查所有第三方依赖,堵住安全漏洞。然后,拿出真金白银,给用户提供安全保障,比如免费的安全审计、风险评估,甚至是赔偿金。记住,信任是金,得用实际行动换回来!

我觉得最值得警惕的是供应链安全问题。Vercel这次被攻击,并非直接攻破自身系统,而是通过第三方AI工具的OAuth授权漏洞。这提醒我们,即使自身安全措施做得再好,也可能因为供应链上的薄弱环节而遭受攻击。所以,对第三方服务商的安全评估和持续监控至关重要。

IPO 估计要延期了,得先解决信任危机。Vercel 可以考虑主动发起安全审计,邀请第三方机构进行评估,证明自己的安全能力。此外,还可以推出安全保障计划,承诺对客户损失进行赔偿。这次事件对整个云开发领域都是一次警醒,提醒大家安全是头等大事,不能掉以轻心。安全投入必须加大力度了。

“非敏感”环境变量的设计初衷可能是为了方便开发和调试,毕竟有些配置信息确实不需要特别的保护。但这次事件说明,即使是非敏感信息,如果被恶意利用,也可能造成严重后果。安全和便利性本来就是一对矛盾,需要在不同场景下进行权衡,没有完美的解决方案。

我司的做法比较“土”,敏感信息都加密后存在git里面,然后用专门的工具人肉进行分发,到期强制更换,虽然效率不高,但是人为的隔离可以避免很多自动化工具带来的风险。

AI 绝对是双刃剑。一方面,它可以帮助攻击者更快地发现漏洞、生成更具迷惑性的钓鱼信息、甚至自动化攻击流程。另一方面,我们也可以利用 AI 来增强防御能力,比如通过 AI 驱动的威胁检测系统,可以更准确地识别异常行为,预测攻击趋势。

感觉以后攻防的重点会变成AI之间的对抗。谁的AI模型更强大,谁就能在网络安全中占据优势。以后安全工程师都要懂机器学习了,不然就 out 了。

以后会不会出现一种职业叫“AI安全驯兽师”,专门负责训练和优化用于安全防御的AI模型?感觉很有前景啊!

回答“为什么更危险”:因为它站的位置太靠上游了。普通网站泄露,影响通常先落在自己用户身上;开发基础设施平台一旦出问题,可能把代码、部署凭证、数据库连接、自动化流水线一起带出来,等于是把很多公司的生产链路同时暴露。

答“非敏感环境变量是不是设计问题”这个问题:我觉得首先是产品设计问题。只要系统允许用户轻易低估变量的重要性,就会有人这么做。很多变量表面看不是密钥,实际上能拼出内部拓扑、服务地址、私有端点,最后照样能提权。安全设计不能只看“这个字段是不是密码”,而要看它能不能被拿来当跳板。