昨天晚上 10 点，Vercel 官方 X 账号发了一条让前端圈瞬间坐不住的推文。

原文是这样的：

“

We've identified a security incident that involved unauthorized access to certain internal Vercel systems, impacting a limited subset of customers.

翻译过来：我们发现了一起安全事件，有人未经授权访问了 Vercel 的部分内部系统，波及了一小部分客户。

"一小部分"这四个字很微妙，具体是多少，官方没说。但对于把项目跑在 Vercel 上的前端开发者来说，这条推文就是一颗深水炸弹。

Vercel 是谁就不用多介绍了。它是 Next.js 的母公司，是前端部署平台里的头部玩家。SvelteKit、Nuxt、Astro、Remix 这些主流框架的官方推荐部署方案几乎都指向它。全球不知道有多少独立开发者、多少初创公司、多少大厂的前台项目都跑在 vercel.com 上。如今这家公司自己被人捅了。

更精彩的是整个攻击链，源头压根不在 Vercel 自己身上，而是一个第三方 AI 工具。

攻击从一个 AI 工具开始

根据 Vercel 在 4 月 20 日发布的官方安全公告，事情是这样发生的：

1. 攻击者先是攻破了一个叫 Context.ai 的第三方 AI 工具

2. 这个 AI 工具被 Vercel 的某位员工授权访问过自己的 Google Workspace 账号

3. 攻击者顺着这层 OAuth 权限，接管了这位员工的 Vercel Google Workspace 账号

4. 然后进入了 Vercel 的部分内部环境，翻到了未标记为"敏感"的环境变量

看懂这条链条没有？Vercel 自己没被直接攻破，被攻破的是它员工用的一个 AI 工具。

Vercel 甚至在公告里公开了这个被攻陷的 OAuth 应用 ID：

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

并且建议所有 Google Workspace 管理员立刻去自查：企业里有没有员工授权过这个应用。

这个攻击路径值得所有前端和 Node.js 开发者警惕。过去一年多，大家为了提效装了各种 AI 插件、AI Agent、AI 写作助手，很多工具在安装时都会弹一个 OAuth 授权页，问你能不能读邮件、能不能访问 Drive、能不能连 Calendar。大多数人眼睛一闭就点了"允许"。

Context.ai 这次等于用真实案例告诉我们：你每一次点"允许"，都是在给某家 AI 公司的安全团队投票。只要他们拉胯一次，你的账号就是别人的跳板。

泄露的是什么数据？

这才是开发者最关心的部分。

Vercel 给环境变量提供了两档保护：

• 普通环境变量：可以在控制台里被查看，属于正常读取态

• 敏感环境变量（Sensitive）：加密存储，设计上是不可读取的，就算内部也看不到值

这次攻击中，攻击者拿到的主要是 没有标记为 Sensitive 的普通环境变量。敏感变量的保护机制扛住了，目前官方没有发现被读取的证据。

问题是，绝大多数开发者根本没开启过 Sensitive 标记。打开你自己的 Vercel 项目看一下 Environment Variables 页面，是不是长这样：

DATABASE_URL=postgres://...
OPENAI_API_KEY=sk-proj-...
STRIPE_SECRET_KEY=sk_live_...
CLERK_SECRET_KEY=sk_live_...
RESEND_API_KEY=re_...
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...
GITHUB_TOKEN=ghp_...
NEXTAUTH_SECRET=...

全是明文，全是普通变量。这些东西一旦被拿到，意味着什么？

• DATABASE_URL 泄露：你的数据库门户大开，用户数据可以被拖

• OPENAI_API_KEY 泄露：账单瞬间炸出几千美金，OpenAI 扣费毫不留情

• STRIPE_SECRET_KEY 泄露：支付接口权限被拿，可能触发大规模欺诈交易

• RESEND_API_KEY 泄露：攻击者拿你的域名疯狂发钓鱼邮件，你的域名信誉归零

• GITHUB_TOKEN 泄露：私有仓库可读可写，代码和 CI 配置全部曝光

任何一条都够让独立开发者和小团队一夜白头。

"200 万美元挂出去卖"是什么情况

在官方公告之外，技术社区和社交平台上还流传着另一个说法：这批 Vercel 数据正在某些地下论坛被标价 200 万美元 打包出售。

Vercel 的官方公告没有正面回应这个具体数字，但也没有否认。能确认的是，已有一部分客户收到了 Vercel 发来的单独通知邮件，告诉他们凭据可能已经泄露。没有收到邮件的账号，Vercel 的说法是目前没有发现异常。

换句话说，如果你今晚打开 Vercel 收件箱里有一封标题带 Security Notice 的邮件，请立刻对号入座。如果没有，也不代表你可以高枕无忧，因为这次调查还在继续。

必须做的 6 件事

Vercel 官方给出了一份自查加固清单，不管你是不是受影响的客户，这些事都值得照着走一遍：

1. 翻账户活动日志

登录 Vercel 控制台，进入 Account Settings → Security → Audit Log，翻一下近两周的记录。注意：

• 有没有不认识的 IP 或地理位置登录

• 有没有莫名其妙的项目创建、删除、环境变量读取

• 有没有 Token 被新建或被使用

2. 轮换所有普通环境变量

这是最紧迫的一步。打开每个项目的 Environment Variables 页面，把所有非 Sensitive 的密钥、token、密码全部重新生成。

重点关注：

• 数据库连接字符串（Supabase、Neon、PlanetScale、MongoDB Atlas 等）

• 第三方 API Key（OpenAI、Anthropic、Stripe、Resend、SendGrid 等）

• 认证相关（NEXTAUTH_SECRET、Clerk、Auth0）

• 存储相关（Vercel Blob、Vercel KV、AWS S3、R2 等）

3. 新密钥全部开启 Sensitive

生成新密钥后，在 Vercel 控制台添加变量时，一定要勾选 Sensitive 选项。这样即便将来再发生类似事件，攻击者也拿不到值。

很多人之前懒得勾，想着"反正部署完就不看了"，这次该长记性了。

4. 检查最近的部署记录

进入每个项目的 Deployments 页面，看看最近有没有你没发起过的部署。攻击者一旦拿到权限，有可能悄悄塞一个带后门的部署进来。

如果看到陌生部署，立刻回滚到已知安全版本，并检查相关 commit。

5. 收紧 Deployment Protection

去 Project Settings → Deployment Protection，确保开到 Standard 或以上。免费版默认是 Standard，Pro 及以上可以开到 Only Preview Deployments 甚至 All Deployments。

6. 轮换 Deployment Protection Token

如果你用了 Deployment Protection 的 bypass token（比如给 CI 或第三方工具用的），一并轮换掉。旧 token 直接作废。

Google Workspace 管理员的额外动作

如果你是公司的 Google Workspace 管理员，或者你所在的团队用 Google Workspace 管账号，还有一步必须做：

1. 登录 Google Workspace 管理控制台

2. 进入 Security → Access and data control → API controls → Manage Third-Party App Access

3. 搜索上面那个 OAuth 应用 ID：110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj

4. 如果命中，立刻把所有授权这个应用的账号权限撤销

5. 让被撤销的员工改密码、重新绑定二次验证、检查最近的收件箱和邮件转发规则

第 5 步特别容易被忽略。很多攻击者拿到邮箱权限后，头一件事就是偷偷设置邮件转发，把后续的所有验证邮件都拷贝一份。光改密码不删转发规则，等于白忙活。

这件事对前端圈意味着什么

Vercel 这次的反应算得上快。从发现到公开披露再到公开 IOC（Indicator of Compromise），不到 24 小时，透明度也够高。敏感环境变量的加密保护机制这次确实发挥了作用，把核心损失控制住了。

但这件事暴露的问题，远不止 Vercel 一家。

这两年前端生态疯狂拥抱 AI。Cursor、Windsurf、各种 VS Code 插件、各种 MCP 工具，几乎每个工具在初次启动时都会要求你授权 GitHub、授权 Google、授权 Figma、授权 Linear。能力是真的强，但 OAuth 授权这把钥匙一旦串起来，就变成了多米诺骨牌。

一个小团队的前端工程师，手里可能同时握着：GitHub Organization 的 admin 权限、Vercel 所有生产项目的部署权、公司 Google Workspace 的邮箱、生产数据库的连接字符串。如果这位工程师随手装了一个拉胯的 AI 工具，他就是整条供应链上最脆弱的那一环。

过去我们说"别把 Key 提交到 GitHub"，这是基本功。现在我们还要学一课：别把 Key 放在可能被 AI 工具间接读到的地方。

写在最后

这次 Vercel 事件不会是最后一起，也不会是影响最大的那一起。AI 工具供应链风险会是接下来两三年开发圈绕不开的话题。

短期行动建议很简单：

• 花半小时轮换 Vercel 上所有项目的环境变量

• 新密钥一律打上 Sensitive 标记

• 检查 Google Workspace 里的第三方应用授权，该撤的撤

• 给你的团队同事转发一下这篇文章，提醒一起自查

长期要做的事更重要：把"哪些 AI 工具获得了哪些 OAuth 权限"当成一份资产清单管起来，定期审计。技术再炫酷，落到安全这一层，该做的功课一步都躲不掉。