A Roblox cheat, a month of silence, and an enterprise OAuth breach: what the Vercel incident is really teaching

本文档由英文原版机器翻译而成。如果翻译版本与英文原版之间存在任何冲突，请以英文原版为准。 阅读英文原版

一个 Roblox 外挂、一个月的沉默和一场企业 OAuth 泄露：Vercel 事件真正的教训

2026-04-22 · Caiioo Team

Vercel 泄露事件中的三个细节值得关注。它们都不是头条新闻，但都会改变你对安装第三方 AI 工具的看法。

细节 1：Vercel 泄露的供应链始于一个 Roblox 外挂

Vercel 事件的公开叙述是这样的：一名 Vercel 员工安装了 Context AI，授予了其广泛的 Google Workspace 权限，Context AI 被攻破，OAuth 令牌被劫持，攻击者渗透进 Vercel。

这是下游的故事。上游的故事则更加离奇。

根据 Hudson Rock 的分析（目前已成为 Trend Micro、OX Security、Strapi 和 The Hacker News 的共识报道，且截至 4 月 22 日未被 Vercel 或 Context AI 反驳），原始矢量是一名 Context AI 员工，其个人设备在 2026 年 2 月被入侵。入侵工具是 Lumma Stealer，一种现成的个人信息窃取软件。据报道，传播媒介是一个下载的 Roblox “自动刷金”游戏漏洞。

窃取软件执行了它的任务：它外泄了该员工的 Google Workspace 凭据和 AWS 访问凭据。这些凭据成为了后续一切的杠杆点：访问 Context AI 的 AWS 环境，访问 Context AI 代表其消费者用户持有的 OAuth 令牌库，访问 Vercel 员工为其企业 Google Workspace 授予的令牌，并最终访问 Vercel 的内部环境和一部分客户环境变量。

一个员工个人笔记本电脑上的 Roblox 外挂，是这场企业 OAuth 供应链泄露的根本原因，Vercel 称其可能影响“许多组织的数百名用户”。

教训不是“Roblox 不好”。教训是在 SaaS-AI 架构中，攻击面延伸到了供应链中每个供应商的每位员工的个人设备。即使你的公司拥有完美的终端卫生，你也可能因为两个供应商之外的某人下载了错误的文件而遭到入侵。

细节 2：Context AI 在 3 月就知道了。他们只通知了一名客户。

Context AI 自己的安全公告（发布于 context.ai/security-update 并于 2026 年 4 月 21 日更新）披露了这一时间表：

  • 2026 年 3 月： Context AI 检测到托管其已弃用的 AI Office Suite 产品的 AWS 环境存在未经授权的访问。他们聘请 CrowdStrike 进行取证，弃用了受影响的环境，并通知了一名已确认受影响的客户。
  • 3 月至 4 月 19 日之间： 属于“部分”消费者用户的 OAuth 令牌仍处于被盗状态。未进行进一步的用户通知。未进行公开披露。
  • 2026 年 4 月 19 日： Vercel 发布其安全事件公告，通过自己的取证独立追溯到 Context AI。
  • 2026 年 4 月 21 日： Context AI 更新其公告，增加了用户指南。没有承诺通知其余受影响消费者用户的时间表。
  • 2026 年 4 月 22 日（截至本文撰写时）： 仍无通知时间表。那些令牌在 2 月份就被盗的人仍然不知道何时、或者是否会被告知。

这部分内容应该改变技术团队对安装第三方 AI 工具的看法。供应商的漏洞检测并不等同于对你的披露。

在许多情况下，供应商没有合同或监管义务告知你他们的服务已被攻破，即使攻破范围包括你交给他们的 OAuth 令牌。你可以在自己这边做对所有事情——尽可能使用最小权限范围、MFA、条件访问、安全意识培训——但你仍然可能在攻击者的掌控下运行数月，因为唯一有能力警告你的一方是不想发表任何声明的一方。

细节 3：Context AI 自身的产品拆分证实了哪种架构能幸存

在同一份 Context AI 公告中，隐藏着一个比文档其余部分更有分量的条款。

被攻破的产品是 AI Office Suite —— Context AI 已弃用的消费者产品。而他们当前的企业产品 Bedrock 未受影响。Context AI 给出的一条理由是：Bedrock “在客户环境中运行”。

同一家公司，同一个工程团队，构建了两种具有不同架构的产品。SaaS 中间人模式的产品——即代表客户在中心化云端持有 OAuth 令牌的产品——是被攻破并泄露数据的那个。而在客户环境中运行的产品——即让 AI 靠近数据而非让数据靠近 AI 的产品——幸存了下来。这并非因为它拥有更好的安全工程，而是因为根本没有中心化金库供攻击者触及。

您不必只听信 Caiioo 关于中心化 SaaS AI 存在结构性问题的说法。Context AI 自己的产品线已经证实了这一点。

这对任何评估 AI 工具的人意味着什么

安全研究社区（Trend Micro、Varonis、Halborn、OX Security、Strapi）的一致结构性教训是：广泛的“允许所有” OAuth 范围是促成因素。一旦签发，这些令牌就会绕过 MFA 和条件访问。供应商的沦陷就变成了每个下游账户的沦陷。

以下是三个要点：

  1. 如果供应商提供最小权限范围，请优先选择。 如果一个 AI 工具为了实现日历功能而要求对你的整个 Google Workspace 进行读写访问，那么这个要求本身就是危险信号。
  2. 优先选择其架构根本不需要长期中心化令牌的供应商。 这是结构性的举措。自带身份验证 (BYOA) 模型中，OAuth 客户端配置在你自己的云项目中，令牌保留在你的设备上，从而将供应商完全从信任链中移除。
  3. 不要依赖供应商的披露作为预警系统。 Context AI 的时间表——3 月检测，通知一名客户，4 月 21 日更新公告但仍未承诺进行更广泛的用户通知——并非特例。这是在缺乏严格法律义务的情况下，事件披露的经济学所产生的结果。你的控制措施必须假设供应商不会及时告诉你。

Caiioo 是如何围绕这一点构建的

Caiioo 是一个强大且隐私优先的工作区，拥有在侧边栏运行的智能体编排器和聊天界面。其架构建立在 Context AI 产品拆分意外证实的同一见解之上：工作区应该在您的数据旁边运行，而不是将您的数据持有在它旁边。

简而言之：您的 Workspace OAuth 令牌加密存储在您的设备上，而非 Caiioo 数据库中。您的 Gmail/Calendar/Drive API 调用直接从您的设备发送到 Google，我们的基础设施绝不在数据路径中。我们运行的转发器——用于设备间协作、OAuth 交换以及许可/账单流量——构建在每用户 Cloudflare Durable Objects 之上（每个用户在硬件上与其他用户隔离），并在其 WebSocket 消息总线上使用端到端加密（我们可以路由消息但无法读取）。我们的中央数据库存储账户身份、账单状态和路由元数据——不存储您的内容、Workspace 令牌或对话。完整的技术细分，包括您可以使用 Little Snitch 或 Wireshark 自行验证的流量表，请参阅我们的关于此泄露事件架构响应的配套文章。

这意味着针对 Caiioo 的 Context AI 式事件不会产生 Context AI 式的后果。不会有被泄露的令牌库，因为根本没有令牌库。也不会有一个月的沉默期来决定何时告知用户，因为我们的基础设施中没有任何东西可以被攻击者从任何用户那里夺走。当供应商从一开始就没有持有您的任何东西时，“供应商检测不等于您的披露”这一问题就消失了。

试用 Caiioo

Caiioo 提供浏览器扩展程序、原生 macOS 应用、原生 iOS 应用、原生 Android 应用，以及适用于 Windows 和 Linux 的桌面应用。免费开始使用。

来源：