Vercel CEO：攻击者目标已超Context.ai正系统性窃取云平台密钥
Vercel 首席执行官 Guillermo Rauch 在最新安全通报中表示，公司已完成一轮“深入安全调查”，分析范围覆盖近 1 PB 的 Vercel 网络与 API 日志，远超最初由 Context.ai 账户入侵引发的内部系统访问事件。 调查结果显示，相关攻击者并非只针对单一 Context.ai 账户，而是在更大范围分发信息窃取类恶意软件，系统性搜集包括 Vercel 在内多家云与开发平台的账户密钥；一旦获取密钥，攻击者会快速而全面地枚举所有未标记为敏感的环境变量，以便进一步横向移动与扩大访问范围。
Rauch 表示，目前 Vercel 已与 Microsoft、AWS、Wiz 等安全与云服务伙伴深化协作，共享攻击指标与入侵路径情报，以保护更大范围的互联网开发生态，并已主动通知其他疑似受影响的机构和个人，建议立即轮换 API 密钥、OAuth 令牌与数据库凭证，并严格区分、加密和标记敏感环境变量，强化零信任与最小权限等安全实践。
来源：公开信息
ABAB AI 解读
这次事件的重要性，已经远远超出“Vercel 被黑一次”本身，而是暴露了一条完整的“AI 工具→OAuth→云环境→环境变量→全网扩散”的现代攻击链。攻击最初来自 Context.ai 用户侧终端被 Lumma Stealer 类恶意软件感染，窃取了 Google Workspace 与各类 SaaS 凭证；随后利用 OAuth 授权接管 Vercel 员工账户，再从中枚举未标记为敏感的环境变量，进而获取更多云平台、代码仓库与数据库的访问密钥。 这一链条说明，在“到处接第三方 AI/SaaS 工具”的时代，企业的安全边界正在被用户侧 OAuth 权限与浏览器扩展彻底重写。
从结构上看，攻击者并没有先去碰最硬的“加密存储”，而是优先捡“未标记为敏感的环境变量”这类软肋——这些变量往往被开发团队视作“不那么重要”，却在现实中包含了足够多的 API key、访问令牌与内部系统地址，可以作为进一步渗透的跳板。 这暴露的是现代云开发模式的一个系统性问题：环境变量已经成为事实上的秘密分发层，但管理和分级策略远远落后于其真实敏感性，一旦被高权限账号访问，攻击者就相当于拿到了一份跨云、跨服务的“钥匙清单”。
Rauch 强调与 Microsoft、AWS、Wiz 等伙伴协同，本质上是在承认：单一平台级厂商已经无法独立应对这种“多云、多 SaaS、跨 AI 工具”的供应链攻击。攻击者利用被攻陷的 OAuth 应用和浏览器扩展，横跨多家云厂商与开发工具，这迫使云服务商、安全厂商与大型 SaaS 建立更高频的威胁情报共享与联合响应机制。 对整个开发者生态而言，这意味着安全基线将被抬升：从简单的“轮换密钥”，升级到系统排查第三方 OAuth 授权、浏览器扩展以及 AI 工具接入策略，把“能访问部署和代码的所有外部应用”当成潜在供应链风险来管理。
从更长的技术周期看，这起 Vercel–Context.ai 事件是“AI 工具融入开发流程”后的第一批大规模教训之一。开发者为提高效率，把越来越多敏感工作流程（代码、部署、日志、工单）接入第三方 AI 产品，而这些产品自身往往运行在更松散的安全环境下；一旦其中某一个环节被攻破，攻击者就能沿着 OAuth 和 API 权限一路向上爬，直达生产环境。 这迫使整个行业重新评估“AI+SaaS 提效”的真实成本：未来真正成熟的做法，必然是在“能帮你写代码和看日志”的工具和“能控制你部署和密钥的权限”之间画出更清晰的墙，把安全边界重新从“企业网络”移动到“每一段授权与每一个环境变量”的粒度上。