你的密钥已经泄露，而且你刚才的"紧急修复"可能完全没用
一个OAuth授权，掀翻了半个前端生态的底裤。
Vercel最近摊牌了：攻击者从2024年底就开始在他们系统里闲逛，直到今年4月才被发现。手法老套得令人发指——先黑掉一个第三方AI工具（Context.ai）的OAuth应用，骗过某个Vercel员工的Google账号，然后就像回自己家一样，开始翻箱倒柜。
但真正让开发者脊背发凉的，不是入侵本身，而是你以为已经堵住的漏洞，其实还在漏水。
当"一键部署"变成"一键脱库"
先给非技术读者科普一下Vercel的地位。
这是前端开发者的"圣地"，Next.js的亲爹，现代JAMstack架构的布道者。 millions of projects rely on it to host their code. 而环境变量（Environment Variables）是这些项目的"命门"——数据库密码、AWS密钥、Stripe支付令牌，全都藏在这里。
攻击者的路径堪称教科书级别的供应链打击：
第一步：OAuth钓鱼。 通过入侵的Context.ai应用（Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com），获取Google Workspace权限。
第二步：横向移动。 有了Google账号，就能访问Vercel的内部系统。攻击者开始搜索邮件里的"API key"、"secret"、"password"，翻Drive里的工程文档。
第三步：环境变量收割。 最终触及客户数据——那些未被标记为"sensitive"的环境变量。
老实讲，这种攻击链条并不新鲜。新鲜的是Vercel的特殊设计让灾难被放大了。
最致命的"特性"：旋转了，但没完全旋转
这里有个反常识的细节，足以让正在读这篇文章的工程师跳起来检查自己的部署。
在Vercel里，即使你"轮换"（rotate）了泄露的密钥，旧的部署实例仍然在使用旧密钥。
换句话说，除非你**重新部署（redeploy）**每一个环境，否则攻击者之前偷走的凭证依然有效。你的"紧急修复"可能只是给自己制造了虚假的安全感。
"Rotation without redeploy leaves the compromised credential live in any previous deployment artifact that is still reachable."
这意味着什么？如果你只是改了AWS密钥但没重新部署，攻击者依然能用旧密钥通过CloudTrail都记录不到的渠道访问你的S3 bucket。这种"幽灵凭证"状态可能持续数月。
更讽刺的是，Vercel的"sensitive"标记功能——现在用来保护密钥的开关——是在2022年才推出的。在此之前，所有环境变量都是明文存储，没有加密选项。
一个OAuth失误，串起了两年的技术债。
AI背锅？还是人的疏忽？
有意思的是，Vercel的CEO公开声称这次攻击的"异常速度"归因于AI增强的攻击手法（AI-accelerated tradecraft）。
但社区显然不买账。
热门评论直接开怼："Attributed without evidence"（毫无证据的归因）。更多人指出，这不过是基本的网络安全 hygiene 失败：
- 员工账号权限过大
- 缺乏有效的2FA或ZeroTrust架构
- 对第三方OAuth应用的管控形同虚设
"这根本不是什么高科技攻击，"一位评论者写道，"就是有人授权了一个AI工具访问整个Google Workspace，包括邮件和网盘。这种错误在初创公司常见，但在Vercel这种级别的平台..."
把基础安全疏失包装成"AI超级攻击"，是2026年最时髦的挡箭牌。
这不是孤例，是供应链的连环崩塌
Vercel事件之所以引发恐慌，是因为它恰好踩在一连串供应链攻击的节点上：
三周前，LiteLLM的CI/CD凭证被盗，恶意包大规模收割开发者密钥；
几周前，Axios的维护者账号被劫持，数百万开发环境被植入RAT；
现在，Vercel的平台级泄露证明：PaaS（平台即服务）本身也成为了供应链的一环。
攻击者正在系统性地瞄准信任边界——不是直接攻击你的代码，而是攻击你信任的维护者、你依赖的平台、你授权的SaaS工具。
当LiteLLM、Axios、Vercel接连倒下，我们不得不面对一个 uncomfortable truth：现代开发的基础设施建立在流沙之上。
现在该做什么？（如果你在用Vercel）
别慌，但请立即行动：
48小时内：
- 检查并轮换所有非敏感标记的环境变量（用
vercel env ls列出所有变量） - 必须重新部署每一个生产环境，否则轮换无效
- 在Google Workspace Admin Console搜索那个恶意的OAuth Client ID，发现即撤销
长期架构调整：
- 把密钥从平台环境变量迁移到专用密钥管理器（HashiCorp Vault、AWS Secrets Manager）
- 实施OIDC认证，彻底消灭长期凭证
- 把OAuth应用当作"第三方供应商"进行风险评估，定期审计
监控重点：
查AWS CloudTrail、GCP Audit Logs、Stripe Dashboard，寻找2026年2月至今的异常IP访问。特别关注那些使用python-requests、curl或Go-http-client的调用。
信任的代价
这次事件最深刻的启示，或许是关于信任边界的重构。
我们习惯了信任Vercel这样的平台，就像信任AWS或GCP。但Vercel的披露表明：平台内部的OAuth管理、员工权限控制、第三方应用审计，任何一环的松懈都会 cascading 成客户数据的暴露。
"Design for the assumption of provider-side compromise"（为供应商侧被攻破而设计）——这是报告里的建议，也是一句残酷的忠告。
当你的数据库密码、支付密钥、AI API令牌都托管在别人的平台上，"零信任"不再是个可选项，而是生存必需。
下一次当你点击"Sign in with Google"授权某个 productivity 工具时，想想那个Vercel员工。一个看似无害的OAuth弹窗，可能就是多米诺骨牌的第一张。
你的密钥，真的只在你手里吗？
【锐评】：把基础OAuth管控失败包装成"AI超级攻击"是2026年最时髦的遮羞布，真正的漏洞不在技术，而在把便利凌驾于安全之上的工程文化。
参考链接：
https://www.trendmicro.com/en_us/research/26/d/vercel-breach-oauth-supply-chain.html