Vercel 以明文形式存储了您的机密，却称之为一项功能

Vercel 遭到入侵。攻击者在系统内停留了大约两个月才被检测到。他们枚举并解密了客户环境变量——API 密钥、数据库密码、签名密钥、令牌——涵盖所有未使用 Vercel 可选 "sensitive" 标志的项目。

攻击链是这样的：一个名为 Context.ai 的第三方 AI 工具被攻破。攻击者以此为立足点，接管了某位 Vercel 员工的 Google Workspace 账户。随后，他们以此为跳板进入 Vercel 的内部系统，并开始读取机密。

据称，这批数据目前正以 200 万美元的价格在 BreachForums 上出售。

那个默认未勾选的"敏感"复选框

以下是关键之处。

Vercel 有两类环境变量。一类是常规变量，它们"静态加密"，但可由 Vercel 的系统解密读取。另一类是"敏感"变量，采用额外的加密措施，据 Vercel 称可防止内部访问。

攻击者能够读取所有常规变量。只有"敏感"变量得到了保护。

问题在于："敏感"是可选项，并非默认设置。每一位设置 DATABASE_URL、STRIPE_SECRET_KEY 或 JWT_SIGNING_KEY 时没有勾选该复选框的开发者——也就是其中的绝大多数——其对应的值都以一种拥有内部访问权限的攻击者可以解密的格式存放着。

Vercel 事后的处置建议是："为加密存储启用敏感环境变量功能。"换言之：您以为在保护您机密的那层加密，实际上并没有防止我们读取它们，也没有防止任何进入我们系统的人读取它们。

两个月的驻留时间

最初的入侵发生在 2026 年 2 月。Vercel 于 4 月 19 日发布了第一份安全通告。这意味着攻击者拥有对内部系统的访问权限大约两个月。

Vercel 自己的安全团队将该攻击者描述为"从其行动速度和对 Vercel 产品 API 面的深入理解来看，属于高度复杂的对手"。当托管您基础设施的公司表示攻击者对其系统的了解超出预期时，您应当有所警觉。

在这两个月里，攻击者有时间枚举受影响客户项目中所有可访问的环境变量，有时间进行数据外传，也有时间将其出售。

OAuth 供应链

入口甚至不在 Vercel 自己的代码中。一名 Vercel 员工通过 Google OAuth 授权了 Context.ai——一款 AI 生产力工具。当 Context.ai 被攻破时，攻击者便继承了该 OAuth 授权所提供的全部权限。

这是一个不断重演的模式。组织精心加固自身的主认证体系，却把 OAuth 令牌发放给那些安全防护往往更弱的第三方工具。链条中只要有一个应用被攻破，攻击者就继承了您员工的访问权限。

被攻破的 OAuth App ID 是公开的：110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com。如果您的组织曾授权过该应用，请立即撤销授权。

您应该采取的措施

如果您在 Vercel 上部署：

• 立即轮换每一个环境变量——不要等到确认自己是否"受影响"再行动
• 此后为所有环境变量启用敏感标志
• 审计您的 Google Workspace OAuth 应用权限，撤销一切未在实际使用的授权
• 检查 Vercel 部署日志，排查 2026 年 2 月至 4 月期间的异常变更
• 检查下游服务（数据库、支付处理方、API），排查是否有人使用存储在 Vercel 中的凭证进行了未授权访问

真正的教训

Vercel 的架构以一种内部访问即可解密的方式存储客户机密。它提供了更强的选项，却没有将其设为默认。两个月里，没有人察觉到攻击者正在读取这些机密。

这正是"信任我们"式安全的问题所在。Vercel 确实对您的环境变量进行了静态加密——技术上属实。但解密密钥掌握在他们手中。当他们的系统被攻破时，您的机密也随之失守。

另一条路是零知识架构，服务提供方在数学上无法解密您的数据。不是"选择不解密"，而是无法解密。无论多么严重的内部失陷、无论哪位心怀不轨的员工、无论多么复杂且在您基础设施中潜伏两个月的攻击者，都无法读取服务器从未持有解密密钥的内容。

Vercel 正在要求客户勾选一个复选框来启用真正的加密。值得追问的是：为什么从一开始这不是唯一的选项？