一个 AI 工具的 OAuth,把 Vercel 送进了黑客手里-夜雨聆风

一个 AI 工具的 OAuth,把 Vercel 送进了黑客手里

2026年4月19日，Vercel 发布安全公告：内部系统遭未经授权访问。黑客组织 ShinyHunters 随即在 BreachForums 发帖，声称掌握了 Vercel 的访问密钥、源代码和数据库，开价 200 万美元。

调查结果出来了：入口不是 Vercel 自身的漏洞，而是一名员工日常在用的 AI 工具——Context.ai。

攻击怎么发生的

Context.ai 是一个 AI 分析工具，员工用它处理产品数据。为了工作，它通过 Google Workspace OAuth 获得了该员工账户的授权。

然后 Context.ai 的 OAuth 应用被攻破了。

OAuth 的逻辑是：应用获得授权后，持有一个 token，这个 token 代表用户的身份和权限。Context.ai 被黑，攻击者拿到了这个 token。接下来，攻击者以那名员工的身份，进入了 Vercel 的内部系统。

攻击链：Context.ai 被黑 → OAuth token 被盗 → 员工 Google Workspace 账户被接管 → Vercel 内部环境被访问

Vercel 事后描述攻击者”基于其操作速度和对 Vercel 系统的深度了解，被评估为高度复杂”。但入口，就是一个 AI 工具的 OAuth 授权。

你的团队接入了多少个 AI 工具？

Cursor、Copilot、Notion AI、Linear AI、Grammarly、Context.ai、各种 AI 代码审查工具……大多数通过 OAuth 接入你的 Google Workspace 或 GitHub。每一个，都持有你团队账户的某种权限。

这些工具的安全性，你审计过吗？

大多数团队的答案是：没有。接入的理由往往是”这个工具很好用”，点了 Allow，就开始用了。没有人去想：如果这个工具的 OAuth 应用被黑，攻击者能访问我们什么？

Vercel 这次付了代价。它的员工用了一个 AI 工具，这个工具被攻破了，攻击者顺着 OAuth 进来了。这个逻辑适用于任何使用了第三方 AI 工具的团队。

Vibe coding 让接入 AI 工具的门槛变得极低——打开 Cursor，一句话让 AI 帮你集成一个新服务，十分钟上线。快是快了，但每次集成，都在扩大你的攻击面。

每个新的 OAuth 授权，都是一个潜在的入口。

有开发者在这次事件后说了一句话，值得记录下来：

“我们需要引导开发人员不要让 AI 替他们做决定。AI 可以辅助决策，但最终还是要进行批判性思考，确保做出正确的选择。这和与任何其他团队成员合作并无二致。”

工具越便捷，越需要人在关键节点上主动思考。

1. 审计所有 OAuth 授权

Google Workspace 管理员：Admin Console → Security → API controls → Manage Third-party app access，看看哪些应用有权限，权限范围是什么。

GitHub：Settings → Applications → Authorized OAuth Apps，同样过一遍。

2. 立即 rotate Vercel 上的环境变量

Vercel 确认，未标记为 sensitive 的环境变量可能已被访问。登录 Vercel，把数据库密码、支付密钥、内部 API token 全部 rotate，不等调查结论。

3. 启用 Vercel Sensitive Environment Variables

Project Settings → Environment Variables，把涉及支付、数据库、内部 API 的变量标记为 sensitive。这些变量即使 Vercel 内部系统也无法读取明文。

4. 对高权限 AI 工具做降权

很多 AI 工具要求的权限远超它实际需要的范围。重新审视每个工具的授权，能只读就不给写权限，能限定范围就不授权全局。

这次事件真正的信号是：AI 工具正在成为供应链攻击的新入口。

以前供应链攻击的目标是 npm 包、CI/CD 插件、IDE 扩展。现在加上了：每个人都在用的 AI SaaS 工具，以及它们持有的 OAuth token。

这个攻击面正在随着 AI 工具的普及快速扩大。接入一个新 AI 工具的时间从几天缩短到了几分钟，但安全审查的时间没有缩短。

不管你用的是 Vercel 还是别的平台，这个问题都适用：你给 AI 工具的 OAuth 权限，是你愿意让攻击者在最坏情况下拿到的权限吗？

如果不是，现在就去改。