Vercel 泄露事件：OAuth 供应链攻击暴露平台环境变量中的隐藏风险

关键要点

• 一个遭到入侵的第三方 OAuth 应用程序使攻击者得以在不依赖密码的情况下长期访问 Vercel 的内部系统，表明 OAuth 信任关系能够绕过传统的边界防御。
• Vercel 的环境变量模型进一步放大了影响：凡未被明确标记为敏感的信息凭证，在获得内部访问权限后均可被读取，从而在平台层面暴露了客户机密。
• 一则在披露前就已公开报告的凭证泄露警报表明，从发现到通知的延迟是平台遭入侵时的关键风险因素。
• 此次事件符合 2026 年更广泛的趋同攻击模式（LiteLLM、Axios）：攻击者持续针对开发者存储在 CI/CD、包注册表、OAuth 集成和部署平台中的凭证下手。
• 有效防御需要架构层面的改变：将 OAuth 应用视为第三方供应商，消除长期有效的平台密钥，并在设计时假定提供商侧可能遭到入侵。

事态仍在发展——最后更新于2026年4月20日，星期一

本分析反映了截至发布时公众已知的有关 Vercel OAuth 供应链遭入侵事件的信息。该事件仍由 Vercel 及受影响各方积极调查中，随着更多信息披露，关键细节——包括下游影响的完整范围、确切的初始访问向量以及归因——都可能发生变化。对于存在信息空白之处，我们已明确指出，而非进行推测。防御建议和检测指引基于已确认的攻击链以及既有的供应链入侵模式；各组织应立即据此采取行动，而不是等待全貌完全清晰。随着新的技术细节、厂商披露或第三方研究出现，我们将更新本分析。

在一起始于 2024 年 6 月左右、并于 2026 年 4 月披露的入侵事件中，攻击者利用对 Context.ai 的 Google Workspace OAuth 应用程序的入侵，获得了进入 Vercel 内部系统的立足点，导致一部分未披露但据报数量有限的客户项目环境变量遭暴露。Vercel 是一个广泛用于前端和无服务器应用的云部署与托管平台。

2026 年 4 月 19 日，Vercel 发布了安全公告，首席执行官 Guillermo Rauch 也在 X 上发长帖，确认了此次攻击链，并点名 Context.ai 为遭入侵的第三方。

此次事件意义重大，因为它表明，OAuth 供应链中的信任关系会形成可绕过传统边界防御的横向移动路径；同时，Vercel 对环境变量的敏感性分类模型使非敏感凭证在静态存储时未被加密，从而可被具备内部访问权限的攻击者读取。

本分析梳理了攻击链，评估了放大影响范围的平台设计决策，将此次安全事件置于日益加剧的供应链入侵浪潮之中加以审视（LiteLLM、Axios、Codecov、CircleCI），并为在 Vercel 及类似 PaaS 平台上运营的组织提供可执行的检测与加固建议。

此次事件揭示了什么

值得注意的并非此次事件的复杂程度——所使用的技术手法早已广为人知——而是它所体现出的三项更广泛影响，使其尤为重要：

• OAuth 放大效应。 单一的 OAuth 信任关系层层传导，最终演变为一次波及整个平台的暴露事件，影响到了与遭入侵供应商并无直接关系的下游顾客。
• AI 加速的攻击技法。 该公司 CEO 公开将攻击者异常迅速的行动归因于 AI 增强——这成为 2026 年围绕“AI 加速对手攻击技法”讨论中的一个早期且备受关注的数据点。
• 从发现到披露的时滞。 至少有一份来自公开顾客的报告显示，在 Vercel 披露此事前九天，相关凭证已被标记为在野外泄露——这也引发了外界对平台遭入侵事件中“从发现到披露时滞”的质疑。

事件时间线

此次攻击从最初的 OAuth 妥协到 Vercel 公开披露，持续了约 22 个月。这一潜伏期与其他基于 OAuth 的入侵事件一致；在这类事件中，攻击者利用合法的应用程序权限，而这类行为很少触发标准检测控制。

从时间线中可以看出的一个关键现象是，从最初的 OAuth 妥协到公开披露，攻击者的潜伏时间长达约 22 个月。虽然对于复杂入侵而言，较长的潜伏期并不罕见——Codecov 事件在约 2 个月后才被发现，CircleCI 则持续了数周——但这也表明，利用合法应用权限进行横向移动的基于 OAuth 的攻击极难被检测出来。

使这一问题雪上加霜的是，在许多订阅层级中，Google Workspace 的 OAuth 审计日志默认仅保留六个月，这意味着在调查人员着手查看之前，对最早期入侵活动进行取证所需的可见性很可能就已经消失。

攻击链

此次攻击利用了现代 SaaS 环境中普遍存在的一条信任链：被授予访问企业 Google Workspace 账户权限的第三方 OAuth 应用程序。

阶段 1：第三方 OAuth 遭入侵（T1199）

提供 AI 分析工具的公司 Context.ai 有一款 Google Workspace OAuth 应用已获 Vercel 员工授权。攻击者入侵了这款 OAuth 应用——Context.ai 遭入侵的具体方式尚未公开披露。Rauch 在 X 上发文称，Vercel 已“联系 Context，协助了解此次事件的全部规模”，这一表述暗示 Context 可能并未自行发现此次入侵。

这是至关重要的初始访问向量。OAuth 应用一旦获得授权，就会保有持续有效的访问令牌，这些令牌会：

• 不要求用户提供密码
• 挺过密码轮换
• 通常具有广泛权限（可访问电子邮件、云端硬盘、日历）
• 在初始授权后很少接受审计

第二阶段：Workspace 账户接管（T1550.001）

攻击者利用已被攻陷的 OAuth 应用程序访问权限，转而入侵了一名 Vercel 员工的 Google Workspace 账户。这使其能够访问电子邮件（存在进一步收集凭证的可能）、通过 Google Drive 访问内部文档、查看日历中的会议及相关资源，并可能进一步访问其他通过 OAuth 连接的服务。

第 3 阶段：访问内部系统（T1078）

攻击者利用被攻陷的 Workspace 账户，进一步渗透至 Vercel 的内部系统。Rauch 将此次升级描述为“从我们同事被攻陷的 Vercel Google Workspace 账户开始的一系列操作”。具体的横向移动技术——无论是通过 SSO 联合、从电子邮件/Drive 中获取的凭证，还是其他与 OAuth 相连的内部工具——尚未披露。

第 4 阶段：枚举环境变量（T1552.001）

攻击者以足够权限访问了 Vercel 的内部系统，从而能够枚举顾客项目的环境变量。根据 Rauch 的公开声明：Vercel 将所有顾客环境变量以完全加密的方式静态存储，但该平台提供了一项可将变量指定为“非敏感”的功能。攻击者通过枚举这些非敏感变量，获得了进一步访问权限。

第五阶段：潜在的下游利用（T1078.004）

暴露的环境变量通常包含下游服务的凭证。Andrey Zagoruiko 于 2026 年 4 月 19 日发布的一份公开客户报告称，他在 4 月 10 日收到了 OpenAI 关于泄露密钥的通知；根据该报告，这个 API 密钥仅存在于 Vercel 中——这表明，至少有一个暴露的凭证在 Vercel 披露此事之前，就已在实际环境中被检测到。

该报告揭示了检测与披露时间线之间可能存在的异常，值得进一步审视，下一节将对此展开分析。

披露时间线异常

针对 Guillermo Rauch 4 月 19 日在 X 上发帖的一则公开回复披露了一个值得独立关注的时间线细节。Vercel 顾客 Andrey Zagoruiko 表示，他于 2026 年 4 月 10 日收到了 OpenAI 发出的密钥泄露通知——而据这名顾客称，该 API 密钥此前从未存在于 Vercel 之外。

OpenAI 的泄露凭证检测系统通常会在 API 密钥出现在不应公开出现的位置时触发（例如 GitHub、粘贴网站及类似来源）。从 Vercel 环境变量到 OpenAI 通知的传导路径，并非一目了然。值得注意的是，这一日期形成了一个为期九天的时间窗口，即从最早的公开暴露证据到 Vercel 披露之间相隔九天。

这九天的间隔意味着什么，又不意味着什么

需要指出的是，这只是一份公开报告，而非取证结论。不应将其解读为 Vercel 在 4 月 10 日就已知晓此次入侵的证据。

然而，这表明，至少有一项凭证在客户被正式通知需要轮换密钥之前，就已在外部环境中被发现。这一区别对三类受众尤为重要：

• 监管机构：根据《通用数据保护条例》（GDPR），72 小时的数据泄露通报时钟从数据控制者知悉泄露事件时开始计算。关于 Vercel 何时知悉此事的问题，如今已进入公开视野。
• 审计人员：SOC 2 和 ISO 27001 评估人员将把从发现到通知的时间延迟，作为持续监控证据的一部分进行审查。
• 客户：其凭证可能已暴露的组织，不能假设暴露窗口在 4 月 19 日结束。它很可能早在此之前就已开始被积极利用。

从事件响应规划的角度来看，这一数据点也印证了一个实际判断：来自 OpenAI、Anthropic、GitHub、AWS、Stripe 等提供商的非主动发出的凭证泄露通知，如今已成为平台遭入侵的主要早期预警渠道。安全团队应将其视为高优先级信号，而非例行噪音。

AI 加速的攻击战术（CEO 评估）

Vercel 首席执行官 Guillermo Rauch 在 4 月 19 日于 X 上发布的帖子中明确表示：

“我们认为，该攻击组织技术极其娴熟，而且我强烈怀疑其行动在很大程度上受到了 AI 的加速。他们行动速度惊人，并且对 Vercel 具有深入透彻的理解。”

这是受影响平台首席执行官公开作出的一项值得关注的表态，应当予以谨慎评估。基于“速度”进行归因本质上带有解释性，但出于若干原因，这一说法仍值得重视，我们将在本节中加以讨论。

“AI 加速”在证据中可能呈现出的样貌

如果 Rauch 的评估反映的是某种真实情况，而非事后合理化，那么其底层取证信号很可能包括以下一种或多种：

• 枚举速度超过人工操作节奏。仅靠脚本就能在一定程度上解释这一点，但由 LLM 驱动的侦察能够以比人工构造查询更快的速度，并行完成模式发现、端点探测和凭证格式识别。
• 具备上下文感知的查询构造。这些查询似乎了解 Vercel 特有的术语（项目 slug、部署目标名称、环境变量命名惯例），却没有明显的先前侦察迹象。
• 针对错误的自适应响应行为。在 LLM 辅助下，攻击者往往比静态脚本更流畅地从 API 错误和速率限制中恢复，并实时调整策略。
• 经过提示工程生成的社交伪装内容。无论是网络钓鱼诱饵、提交信息还是支持工单，读起来都像是本地真实写作，而非翻译稿或模板化文本。

这为何在 Vercel 事件之外也至关重要

无论 Rauch 的判断能否经得起正式取证审查，这一类别本身——AI 增强的对手行动——已不再只是推测而已。Microsoft 于 2026 年 4 月发布的关于 AI 支持的设备代码钓鱼（Storm-2372 后续攻击活动）的报告记录了真实威胁行为者如何利用生成式 AI 进行动态代码生成、高度个性化诱饵以及后端自动化编排。这意味着，按照人类节奏的攻击者行为校准的遥测基线，在面对 AI 加速的攻击行动者时，可能会产生漏报。

检测工程方面的启示

如果由 AI 加速的攻击者压缩了枚举和横向移动的时间线，那么基于旧有事件数据中停留时间和速率阈值调校的检测规则，可能会出现告警不足。尤其是，各团队应考虑重新审视以下阈值：每个会话的唯一资源枚举速率、错误与成功比率的恢复曲线，以及短时间窗口内查询模式的多样性。

环境变量设计问题

此次安全事件中影响最为深远的方面，并非最初的访问路径——OAuth 遭入侵是已知且经过充分研究的风险。真正的问题在于 Vercel 的环境变量敏感性模型，它为顾客机密信息造成了一种默认不安全的配置。

Vercel 环境变量在此次泄露发生时的工作方式

Vercel 项目使用环境变量将配置和密钥注入无服务器函数和构建流程中。这些变量带有一个“敏感”标记，用于控制访问限制，如表 2 所示。

这一关键设计选择

敏感性标记默认处于关闭状态。开发者添加的每一个 DATABASE_URL、API_KEY、STRIPE_SECRET_KEY 或 AWS_SECRET_ACCESS_KEY，如果未明确切换开启该标记，都会在 Vercel 的内部访问模型中以静态未加密形式存储。

任何要求对每一项单独密钥都必须明确选择加入、且没有防护措施或默认设置的安全控制，在实际应用中的采用率都会很低。

Vercel 的回应

Rauch 证实，Vercel 已经推出了仪表板改动：新增环境变量总览页面，并改进了敏感变量的创建和管理界面。这些调整提升了可发现性，但截至本文撰写时，并未改变默认设置——开发者仍必须对每个变量逐一选择加入。Vercel 是否会调整默认设置，仍是一个悬而未决的问题，客户应就此持续施压。

与行业同行的比较

行业趋势正转向专门构建的密钥存储方案，如 Vault、AWS Secrets Manager、Doppler 和 Infisical，而非采用按敏感级别分层的环境变量存储。此次泄露事件印证了这一架构选择。

表 3 总结了 Vercel 基于环境变量的方法与类似平台常见做法之间的对比。

凭证扩散：量化下游风险

“凭证扇出”一词描述的是：单一平台遭入侵后，风险会级联扩散至所有使用存储在该平台上的凭证进行身份验证的下游服务，导致其一并暴露。

对于这一特定案例，我们在表 4 中总结了 Vercel 项目环境变量通常可能包含的内容及其下游影响。

单个 Vercel 项目通常包含 10 到 30 个环境变量。在组织层面上，一个由 50 个项目组成的投资组合，可能在平台内拥有 500 到 1,500 组凭证。每一组凭证都可能成为横向移动的切入点，进入一个完全独立且具有自身影响范围的系统。

这正是将一次平台入侵从单纯的机密性事件，升级为可能在软件供应链中引发连锁反应的倍增器 。

为什么 OAuth 信任关系会绕过边界防御

此次攻击之所以能持续约 22 个月，一个根本原因在于，基于 OAuth 的入侵能够绕过大多数原本可以发现传统基于凭证攻击的安全控制。

左侧栏中的每一项防御控制，都是安全团队用来检测或阻止账户被攻陷所依赖的手段。而在 OAuth 应用被攻陷这一路径中，这些控制要么不相关，要么早已被满足。正是这种不对称性，使得 OAuth 治理正逐渐成为一门独立的安全学科，与身份与访问管理相区分。

将 OAuth 治理视为供应商风险职能

大多数组织将 OAuth 授权视为开发人员自助问题：每名员工自行授权所需工具，几乎没有集中的审查。此次事件表明，OAuth 授权应被视为第三方风险管理的一部分——每个已获授权的 OAuth 应用，实际上都相当于一个可持续访问企业数据的供应商，因此应接受供应商审查、定期重新授权，并持续监测其异常使用情况。

威胁行为者的声称与归因

地下论坛上威胁行为者的说法本身就不可靠。以下内容仅为提高认知和进行威胁追踪而记录，并不代表已获证实的事实。数据泄露事件中的归因向来极为困难，而论坛上的说法往往存在夸大、捏造，或由仅与事件有间接关联的一方提出的情况。

自称与 ShinyHunters 有关联的说法

一名声称与 ShinyHunters 组织有关联的威胁行为者在 BreachForums 上发帖，称其持有 Vercel 的数据。

有多个因素使得将该事件归因于自称与 ShinyHunters 有关联的行为者变得复杂：

• 已知的 ShinyHunters 成员已公开向 BleepingComputer 否认参与其中。
• 据称，有人通过 Telegram 提出了 200 万美元的赎金要求——这既是合法也可能是伪造数据泄露声明中常见的牟利模式。
• 自该组织最初发起行动以来，“ShinyHunters”这一品牌已被多个可能彼此无关的行为者所使用。
• Vercel 的安全公告并未提及这些说法；Rauch 的帖子讨论了攻击链，但没有直接回应该论坛发帖。

供应链发布路径：Vercel 的立场

Rauch 直接回应了影响最大的情景，称：“我们已经分析了我们的供应链，确保 Next.js、Turbopack 以及我们的众多开源项目对社区保持安全。”

截至本文撰写时，对发布路径完整性的独立核实仍在进行中。使用 Next.js、Turbopack 或其他 Vercel 开源项目的组织，应继续将监测包完整性信号（校验和、签名、来源证明）作为标准做法。

在未对论坛所称数据进行独立核实的情况下，这些说法应被视为尚未证实。Vercel 所描述的基于 OAuth 的攻击链在技术上是成立的，且并不需要论坛发帖者所声称的那种访问权限范围，这表明这些说法可能被夸大、可能指向另一起无关的独立事件，或可能纯属捏造。

MITRE ATT&CK 映射

经确认的攻击链可清晰对应到既有的 MITRE ATT&CK 技术，如表 6 所示。该映射反映了 Vercel 披露中明确描述的行为，并符合广为人知的 OAuth 滥用模式，而非新型利用手法。

基于这一映射，从 OAuth 应用程序访问转向内部系统访问（T1199 至 T1078）是最具价值的检测点。

因此，企业应监测异常的 OAuth 应用程序行为，尤其是那些访问超出预期范围资源或来自异常 IP 地址段的应用程序。

供应链围攻：LiteLLM、Axios 与趋同模式

Vercel 遭入侵并非孤立事件。2026 年 3 月至 4 月期间，软件供应链攻击出现了前所未有的高度集中，这表明要么是协同开展的活动，要么——更有可能——是多个威胁行为者同时发现了同一种结构性弱点：包注册表、CI/CD 系统、OAuth 提供商与部署平台之间的信任边界。

2026 年 3 月 24 日：LiteLLM PyPI 供应链遭入侵

恶意 PyPI 软件包 litellm 1.82.7 和 1.82.8 版本，系使用从 Trivy（Aqua Security 的漏洞扫描器）窃取的 CI/CD 发布凭证上传。此次攻击瞄准了 LiteLLM——这一被广泛使用的 LLM 代理，其日下载量约为 340 万次。

• 初始访问：攻击者（被追踪为“TeamPCP”）入侵了 Trivy 的 CI/CD 流水线凭证，而这些凭证拥有向 PyPI 发布的权限。
• 载荷：一个分三个阶段实施的后门，瞄准主要云服务提供商中的 50 多种凭证类型，并通过 Kubernetes DaemonSet 实现持久化，以便横向移动。
• 驻留时间：这些恶意软件包在被发现并移除前，在线存在了约 40 分钟至 3 小时。
• 涉及的 CVE：CVE-2026-33634。

2026 年 3 月 31 日：Axios npm 供应链遭入侵

npm 包 axios（每周下载量为 7000 万至 1 亿次）因维护者账户遭劫持而被入侵。恶意版本 1.14.1 和 0.30.4 被注入了对 plain-crypto-js@4.2.1 的依赖，而该包中包含一个跨平台远程访问木马（RAT）。

• 初始访问：维护者账户遭劫持（具体方式未披露；疑似为凭证填充攻击或网络钓鱼）。
• 规模：检测到135个端点与攻击者的命令与控制基础设施通信。
• 驻留时间：在被检测到之前为2至3小时。
• 归因：Microsoft 将此次攻击归因于“蓝宝石雨夹雪”（Sapphire Sleet），一个由朝鲜国家支持的威胁行为体。

汇聚模式

三周内三次攻击。三种不同的攻击途径。目标却相同：开发者存放在其工具链中的凭证和密钥。

以往平台遭入侵事件揭示了什么

Vercel 遭入侵事件延续了一种有充分记录可查的平台层级攻陷模式，即大规模暴露顾客机密信息。

Codecov Bash Uploader 遭入侵事件（2021 年 1 月至 4 月）

发生了什么： 攻击者篡改了 Codecov 的 Bash Uploader 脚本（用于 CI/CD 流水线），以窃取顾客 CI 环境中的环境变量。此次入侵约两个月未被发现。可能受影响的顾客超过 29,000 家，其中包括 Twitch、HashiCorp 和 Confluent。

与 Vercel 的相似之处： 这两起事件都暴露出，由于平台遭到攻陷，存储为环境变量的客户凭证被泄露。

CircleCI 安全事件（2023 年 1 月）

事件经过： 攻击者通过个人设备上的恶意软件窃取了一名员工的 SSO 会话令牌，并利用该令牌访问 CircleCI 内部系统，窃取了客户机密和加密密钥。CircleCI 建议所有客户轮换存储在该平台上的所有机密信息。

与 Vercel 的相似之处： 模式几乎完全一致——员工账户被攻陷 → 访问内部系统 → 客户机密被窃取。

Snowflake 顾客凭证攻击（2024 年 5 月至 6 月）

威胁行为者 UNC5537 利用通过信息窃取型恶意软件获取的凭证，访问了未启用多因素身份验证（MFA）的 Snowflake 顾客账户。超过 165 家组织受到影响，其中包括 Ticketmaster、Santander Bank 和 AT&T。

Okta 支持系统遭入侵（2023 年 10 月）

攻击者利用窃取的凭证访问了 Okta 的顾客支持案例管理系统，并查看了包含会话令牌的 HAR 文件，这些令牌涉及 Cloudflare、1Password 和 BeyondTrust 等 Okta 顾客。

模式总结

这一模式已十分清晰。平台层面对顾客机密信息的访问是一种系统性风险，并且在 CI/CD、身份、数据仓库和部署平台中一再被利用。每起事件都遵循同样的路径：通过信任关系或凭证获得初始访问权限，随后横向移动至内部系统，并大规模窃取顾客机密信息。

仍未知的事项

尽管围绕此次事件已有大量公开报道、高管声明和第三方评论，但公开记录中仍存在重大信息缺口。严谨的分析不仅需要审视已知事实，还必须明确承认哪些内容尚未披露或未经独立核实。

以下尚未解决的问题表明，当前公开可得信息中存在重大缺口，而这些信息与理解此次事件的根本原因、影响范围及后果直接相关：

• Context.ai 是如何遭到入侵的。OAuth 应用程序遭入侵的根本原因尚未披露。Rauch 表示 Vercel 已“联系 Context 提供协助”，这表明事件影响范围对 Context.ai 自身而言可能仍不明朗。
• Vercel 首次发现异常活动的时间。一名 Vercel 顾客于 4 月 10 日收到 OpenAI 通知，这使这一问题显得尤为突出。Vercel 尚未公布其内部发现时间线。
• 为何从最早公开出现凭证滥用证据到 Vercel 披露此事之间相隔了九天。这一情况可能有多种解释（协调披露、调查仍在进行、客户通知尚未完成）；现有公开记录尚无法确定究竟适用哪一种。
• 受影响客户的数量。Rauch 将影响描述为“相当有限”；但尚未披露具体数字。
• ShinyHunters 论坛所称情况是否出自同一攻击者。这些说法究竟与已确认的攻击链相符，还是属于另一起独立事件，目前仍未得到证实。
• Context.ai 当前状态及对下游顾客的通知情况。目前尚不清楚 Context.ai 是否已发布其自身的事件报告，或是否已通知其他顾客。
• 内部访问的完整范围。除环境变量外，攻击者在长达 22 个月的潜伏期间还访问了 Vercel 哪些其他内部系统或数据，仍有待查明。

检测与狩猎指南

本节为可能受此次事件影响的组织提供切实可行的检测与威胁狩猎指导。

致 Vercel 客户（立即）

1. 通过在 Vercel 项目中输入以下代码，对所有环境变量进行审计，以核实配置

# 通过 CLI 列出所有 Vercel 项目中的全部环境变量
vercel env ls –environment production
vercel env ls –environment preview
vercel env ls –environment development

# 检查哪些变量未被标记为敏感
# （Vercel CLI 目前不显示敏感标记——
# 请通过仪表板或 API 查看）

2. 搜索已暴露凭证的未授权使用情况

• 查询云服务提供商的 CloudTrail/审计日志，查找是否存在使用已暴露访问密钥、且来自异常 IP 范围或用户代理的 API 调用。
  • AWS CloudTrail：筛选 eventSource 包含 sts.amazonaws.com、iam.amazonaws.com、s3.amazonaws.com 的事件。搜索 userIdentity.accessKeyId 与任何已轮换的、存储于 Vercel 的访问密钥相匹配的记录。标记所有 sourceIPAddress 不在已知 CIDR 范围内，或 userAgent 包含 python-requests、curl、Go-http-client 或其他陌生自动化字符串的事件。时间范围：2024 年 6 月至今。
  • GCP 审计日志：查询 protoPayload.authenticationInfo.principalEmail，查找其密钥曾存储于 Vercel 的服务账户。根据已知范围筛选 protoPayload.requestMetadata.callerIp。重点关注来自异常来源、且 protoPayload.methodName 包含 storage.objects.get、compute.instances.list 或 iam.serviceAccountKeys.create 的记录。
  • Azure 活动日志：筛选 caller 与任何应用程序 ID 或其凭证曾出现在 Vercel 环境变量中的服务主体相匹配的记录。标记 callerIpAddress 超出预期范围的事件。优先查询：Microsoft.Storage/storageAccounts/listKeys、Microsoft.Compute/virtualMachines/write、Microsoft.Authorization/roleAssignments/write。
• 数据库访问日志：对于每个连接字符串曾存储为 Vercel 环境变量的数据库，查询完整暴露时间窗口内（2024 年 6 月至 2026 年 4 月）的连接日志。搜索源自应用程序已知出口范围之外 IP 的连接（Vercel 边缘 IP、你的 VPN、你的办公室）。标记在正常部署时间窗口之外使用已暴露凭证发生的连接。对于 PostgreSQL：查询 pg_stat_activity 和 log_connections 日志。对于 MySQL：查询 general log 或审计插件。对于 MongoDB Atlas：查询项目活动源中来自未知 IP 的 DATA_EXPLORER 和 CONNECT 事件。
• 支付处理商：对于 Stripe，请检查 Dashboard → Developers → Logs，查看是否有使用已暴露密钥的 API 调用。筛选 source_ip 不属于你们服务器的记录。重点查看你无法识别的 /v1/charges、/v1/transfers、/v1/payouts 和 /v1/customers 调用。对于 Braintree/Adyen，请查询相应的 API 交易日志。优先处理：任何以非敏感环境变量形式存储在 Vercel 中且尚未轮换的 api_key。审计电子邮件发送服务日志，查看是否存在异常发送。
• 检查在暴露时间窗口内，是否收到了来自 OpenAI、Anthropic、GitHub、AWS、Stripe 及类似提供商的非请求式泄露凭证通知。这些自动化检测系统如今已成为此类攻击的主要早期预警渠道。

3. 轮换并重新部署

需要注意的一个关键运行细节是，轮换 Vercel 环境变量并不会追溯性地使旧部署失效。根据 Vercel 的文档，此前的部署会继续使用旧的凭证值，直到它们被重新部署。

如果只进行轮换而不重新部署，任何仍可访问的旧部署制品中被泄露的凭证都将继续有效。每次轮换凭证后，都必须重新部署所有使用该变量的环境，或者明确禁用这些旧部署。

• 轮换优先顺序：
• 云服务提供商凭证（AWS、GCP、Azure）。
• 数据库连接字符串。
• 支付处理器密钥。
• 认证密钥（JWT 密钥、会话密钥）。
• 第三方 API 密钥。
• 监控和记录令牌。

对于安全团队（主动防御）

OAuth 应用程序审计——Google Workspace

• 管理控制台 → 安全 → API 控制 → 第三方应用访问。
• 审查所有已获授权的 OAuth 应用。
• 标记具有广泛权限范围的应用（云端硬盘、Gmail、日历）。
• 调查来自无现行业务关系供应商的应用。
• 监控来自异常 IP 段的 OAuth 令牌使用情况。
• 搜索已知恶意的 OAuth 客户端 ID：110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

用于 SIEM 实施的检测逻辑

以下检测模式对应已确认攻击链的各个阶段。每种模式都说明了可观测行为、需要接入的日志来源，以及应触发调查的条件。各组织在根据其特定日志源架构验证字段名称后，应将这些模式转换为其 SIEM 平台原生的规则（Sigma、Splunk SPL、KQL、Chronicle YARA-L）。

OAuth 应用程序异常（第 1–2 阶段）

监控 Google Workspace 代币以及管理员审计日志中的三种模式。首先，任何与已知恶意 OAuth 客户端 ID（110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com）相关的代币刷新或授权事件，都应立即触发警报；这就是已被攻陷的 Context.ai 应用程序。

其次，任何授予广泛权限范围（包括完整邮件访问、Drive 读/写、日历访问）的 OAuth 应用程序授权事件，都应结合你们当前活跃的供应商库存进行审查；不再用于当前业务的应用程序应被撤销授权。第三，任何已获授权的 OAuth 应用程序的令牌使用行为，如其来源 IP 超出你们预期的企业及供应商 CIDR 范围，都应被标记并展开调查，因为这可能表明令牌遭窃或应用程序已被入侵。

内部系统访问与横向移动（第 3 阶段，T1078）

一旦攻击者控制了被入侵的 Google Workspace 账户，他们就会转向那些信任该身份的内部系统。检测应重点关注四项指标：

• 异常的 SSO/SAML 认证事件。监控身份提供商日志，查看被入侵的 Workspace 账户是否从陌生的 IP 地址、地理位置或设备指纹登录内部应用程序（Vercel 仪表板、CI/CD 平台、内部工具）——尤其是首次访问该账户此前从未接触过的系统。
• 电子邮件和 Drive 凭证收集。审查 Google Workspace 审计日志，关注批量电子邮件搜索查询（关键词如“API key”“secret”“token”“password”“.env”）、异常的 Google Drive 文件访问模式（打开共享凭证存储、工程运行手册或基础设施文档），以及在被入侵账户上创建邮件转发规则的行为。
• 通过 OAuth 连接的内部工具访问。遭入侵的 Workspace 身份很可能已对内部工具（Slack、Jira、GitHub、内部仪表板）授予现有的 OAuth 权限。应监控这些下游服务是否出现与受损用户相关、发生在正常工作时间之外，或来自与该用户历史访问模式不一致基础设施的会话创建或 API 活动。
• 权限提升尝试。留意受损身份是否请求更高权限、加入新的群组或角色，或访问其此前未曾使用过的管理控制台。尤其是在 Google Workspace 中，应监控 Directory API 调用、委派变更，或试图枚举其他用户 OAuth 令牌的行为。

环境变量枚举（第四阶段）

监控 Vercel 团队审计日志中异常的环境变量访问模式。具体事件类型将取决于 Vercel 的审计日志架构，但需要关注的目标行为是：任何读取、列出或解密环境变量的 API 调用，其数量或频率与正常部署活动不符。

先为正常的部署节奏建立基线——CI/CD 管道在构建时会合法读取环境变量——随后对在访问量、时机或来源身份上偏离该基线的访问模式发出警报。尤其要关注任何来自用户账户而非服务账户的环境变量访问，或来自通常不会与被访问项目交互的账户的访问。

下游凭证滥用（阶段 5）

对于在暴露时间窗口内（2024 年 6 月—2026 年 4 月）以非敏感 Vercel 环境变量形式存储的每一项凭证，都应查询相应服务的访问日志，检查是否存在来自异常来源的使用记录。在 AWS 中，这意味着按特定访问密钥 ID 过滤 CloudTrail 查询，查找来自已知应用程序、CI/CD 和企业网络范围之外 IP 地址的 API 调用。

在 GCP 和 Azure 中，对应的方法是按相关服务账户或应用程序身份过滤审计日志查询。对于 SaaS API（Stripe、OpenAI、Anthropic、SendGrid、Twilio），应检查提供商的控制面板或 API 日志，查看是否存在来自无法识别 IP 地址的密钥使用记录，或发生在应用程序未处于活动状态时间窗口内的调用。任何显示出无法归因于自身基础设施使用情况的凭证，都应视为已泄露，立即轮换，并调查攻击者利用其执行了哪些操作。

第三方凭证泄露通知

为来自实施自动密钥扫描的提供商配置针对非主动泄露凭证通知的监控，包括但不限于 GitHub（密钥扫描合作伙伴计划）、AWS（泄露密钥检测）、OpenAI、Anthropic、Stripe 和 Google Cloud。这些通知如今已成为平台级凭证暴露的主要早期预警渠道。对于任何仅存在于部署平台中的密钥所收到的此类通知，都应视为平台遭入侵的潜在迹象，而非例行的密钥卫生噪音。

威胁狩猎

Google Workspace 管理员控制台——手动搜索步骤：

1. 管理员控制台 → 报告 → 审计与调查 → OAuth 日志事件
2. 筛选：应用程序名称 = “Context.ai” 或 Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
3. 日期范围：2024年1月至今
4. 导出所有结果。任何命中结果 = 立即撤销并开展事件调查。

Google Workspace——所有具有广泛权限范围的第三方 OAuth 应用程序：

1. 管理控制台 → 安全 → API 控制 → 第三方应用访问 → 管理 Google 服务
2. 按以下方式排序：“应用访问权限”→“不受限制”
3. 对每个应用，核实：（a）是否存在有效的供应商合作关系；（b）权限范围是否有业务用途支撑；（c）最近使用日期是否为近期。任何超过 90 天未使用的应用：予以撤销。

防御建议

本节根据此次事件中已确认的攻击战术，概述相应的防御建议。

立即采取的行动（0—48小时）

• 轮换所有未被标记为敏感的 Vercel 环境变量，无论你是否认为它们已被访问。与凭证遭到泄露所带来的代价相比，不必要轮换的成本微不足道。
• 轮换后重新部署所有环境——仅进行轮换并不会使旧部署失效。
• 为所有包含任何形式凭证、令牌、密钥或机密信息的环境变量启用敏感标记。审查每个项目。
• 在您的 Google Workspace（或 Microsoft Entra）管理控制台中审计 OAuth 应用程序授权。撤销任何不再被积极使用的应用程序的访问权限。
• 检查所有凭证曾存储为 Vercel 环境变量的服务的访问日志，涵盖 2024 年 6 月至今的时间段。

短期加固（1—4周）

• 将密钥迁移到专用的密钥管理器（HashiCorp Vault、AWS Secrets Manager、Doppler、Infisical）。在运行时注入密钥，而不是将其存储为平台环境变量。
• 在支持的情况下，为 CI/CD 和部署流水线实施基于 OIDC 的认证，彻底消除长期有效的凭证。
• 部署 OAuth 应用监控——可采用商业解决方案（Nudge Security、Grip Security、Valence Security），或使用 Google Workspace 内置的 OAuth 应用管理功能。
• 建立凭证轮换自动化机制——无论是否发生安全事件，密钥都应按照预先设定的周期（30 至 90 天）进行轮换。
• 将 OAuth 授权视为供应商关系——除签约供应商外，也应将其纳入第三方风险库存。

架构变更（1至6个月）

• 对环境变量采取零信任态势——假定存储在部署平台中的任何密钥都可能在平台级安全漏洞中暴露。系统设计应确保单一凭证泄露不会引发连锁扩散。
• 对所有凭证实施最小权限范围控制——数据库凭证应仅具备最低必要权限，API 密钥应限定于特定操作，云凭证应使用基于角色的临时凭证，而非长期有效的访问密钥。
• 对任何访问企业身份系统的 OAuth 应用程序或集成建立第三方供应商安全审查机制，并定期对现有授权进行复审。
• 将 PaaS 平台纳入你的 SBOM/ASPM 清单——此次泄露事件表明，部署平台应被视为一级供应链依赖，而非外部服务。

建议监控项

• 在 Google Workspace 管理员控制台中审计上述 OAuth 客户端 ID。
• 监控 Vercel 审计日志中是否存在意外的 env.read 或 env.list API 调用。
• 检查 CloudTrail、GCP 审计日志和 Azure 活动日志，查看在 2024 年 6 月至 2026 年 4 月期间，是否有来自异常 IP 或用户代理、使用存储为 Vercel 环境变量的凭证的情况。
• 如果这些软件包位于你的依赖树中，请监控各自公告中发布的与 LiteLLM 或 Axios 相关的任何 IOC。
• 在暴露窗口期间，留意来自主要 API 提供商的未经请求的凭证泄露通知。

监管与合规影响

因 Vercel 泄露事件导致凭证暴露而受影响的组织，应评估其在以下法规下的通知义务：

• GDPR（欧盟）：如果暴露的凭证可访问包含欧盟个人数据的系统，那么在确认发生暴露时，72 小时的数据泄露通报时限可能已经开始。OpenAI 于 4 月 10 日发出的通知引发了这样一个问题：某些组织是否早在 Vercel 于 4 月 19 日披露之前就已知悉此事。
• CCPA/CPRA（加利福尼亚州）：若暴露的凭证可访问消费者数据，可能会触发通知义务。
• PCI DSS：如果支付处理商凭证（Stripe、Braintree、Adyen）遭到暴露，则可能适用 PCI 事件响应程序和取证调查要求。
• SOC 2：承担 SOC 2 合规义务的组织应在持续监控证据中记录该事件、已采取的凭证轮换措施以及更新后的控制措施。
• SEC 网络安全规则（8-K）：若上市公司认定此次泄露具有重大性，则负有在 4 个工作日内披露的义务。

问题在于，许多组织可能尚不清楚这些暴露的凭证是否真的被用于未经授权的访问——但监管框架往往在信息暴露时就会触发，而不以已确认遭利用为前提。

结论

Vercel 遭入侵并非孤立事件——它是软件行业管理机密信息和信任关系方式中一种结构性脆弱性的最新体现。在短短三周内，我们已经看到：

• LiteLLM：CI/CD 凭证被窃取 → 恶意软件包大规模收集开发者机密。
• Axios：维护者账户遭劫持 → RAT 被部署到数百万开发者环境中。
• Vercel：OAuth 应用遭入侵 → 获得对顾客部署密钥的平台级访问权限，且至少有一份公开报告显示，在事件披露前，野外环境中已检测到下游凭证滥用。

每一次攻击都瞄准软件供应链中的不同环节。合在一起，它们勾勒出这样一幅图景：在这个生态系统中，凭证是普遍目标，信任关系则是普遍的攻击面。业界长期警告的连锁反应，已不再仅仅停留在理论层面。

前方的防御路径已经很清晰，尽管并不容易：

• 不要再将长期有效的凭证存储在平台环境变量中。应使用专用的密钥管理器，并在运行时注入。
• 不要再对 OAuth 应用给予默认信任。应进行审计、监控，并定期重新授权。
• 不要再想当然地认为平台提供商的内部安全态势万无一失。应按其遭到入侵的情形进行设计。
• 开始主动轮换凭证——并且别忘了随后重新部署。
• 将来自第三方提供商的凭证泄露通知视为高优先级的早期预警信号，而非例行噪音。

能够安然度过下一次平台安全事件的组织，是那些早已假定其会发生，并据此构建其凭证架构的组织。

妥协指标（IoCs）

已确认的 IoC