2026 年 4 月，Vercel 披露了一起由第三方 OAuth 应用被攻破引发的安全事件。攻击者通过被入侵的 Context.ai Google Workspace OAuth 应用获取了 Vercel 员工账号访问权限，进而横向移动至内部系统，导致部分非敏感环境变量被读取。这一事件暴露出 OAuth 授权流程中的隐蔽风险，同时也为云平台环境变量安全管理提供了重要教训。
攻击路径解析：OAuth 供应链的薄弱环节
此次攻击的核心在于 OAuth 供应链的信任链被突破。攻击者并非直接攻击 Vercel 本身，而是通过入侵 Vercel 员工使用的第三方集成应用获得了初始入口。具体攻击链可分解为三个关键阶段：
第一阶段为 OAuth 应用妥协。Context.ai 作为 Vercel 生态中的第三方工具，其 Google Workspace OAuth 应用被攻击者攻陷，这意味着任何通过该应用进行 OAuth 授权的用户，其账号访问权限都会被攻击者截获。这一步揭示了 OAuth 授权模型中第三方应用的安全性往往成为整个信任链条中最脆弱的一环。
第二阶段为凭据横向移动。获取员工 OAuth 令牌后，攻击者成功登录 Vercel 内部系统。由于 OAuth 令牌具备较长的有效期和广泛的权限范围，攻击者能够访问原本需要多重认证才能触及的内部资源。
第三阶段为环境变量读取。在内部系统中，攻击者访问了部署环境配置，其中未被标记为敏感的环境变量以明文形式存储于系统可读区域，导致这些配置值被攻击者获取。Vercel 在事件披露中明确指出，被标记为敏感的环境变量受到加密保护且无法被读取回显，而未被分类的非敏感变量则暴露在风险之中。
这一攻击路径表明，OAuth 授权并非单向的信任授予，而是一个需要持续监控的动态过程。当第三方应用的的安全性无法得到保障时，其所获得的授权范围将直接成为攻击者的横向通道。
环境变量暴露的技术根因
环境变量在现代云原生应用部署中承担着配置管理、密钥注入和服务编排的关键角色。Vercel 平台允许开发者通过项目设置界面管理两类环境变量：普通环境变量和敏感环境变量。两者的核心区别在于存储方式与访问控制策略。
普通环境变量以加密形式存储在服务端，但在特定运维场景下可通过仪表板读取回显。这种设计初衷是为了方便开发者在调试过程中快速查看配置值，但在遭受内部人员账号或类似 OAuth 令牌被窃取的攻击场景下，这些变量会变为可读状态。敏感环境变量则采用了更严格的保护机制，其值在存储时使用独立的加密密钥，且不支持通过任何接口读取回显，即使拥有完整的管理员权限也无法直接查看变量内容。
事件中暴露的正是那些被归类为普通环境变量的配置项。攻击者利用获得的内部访问权限，读取了这些本应在特定权限下可访问的变量值。虽然 Vercel 明确表示敏感变量未受影响，但这一事件仍然提醒开发者：任何未被显式保护的配置项，在平台层面都存在被读取的可能性。
工程防护策略：从被动响应到主动防御
基于此次事件的教训，工程团队需要建立系统性的环境变量安全管理机制。以下策略可作为安全加固的参考框架。
敏感信息分级标记是首要原则。 任何具有保密价值的配置，包括数据库连接字符串、第三方服务 API 密钥、加密算法密钥、内部服务令牌等，都应被明确标记为敏感环境变量。Vercel 平台默认不将任何变量自动归类为敏感，这意味着开发者必须在配置阶段主动完成分级。判断标准可参考以下清单：凡是需要最小权限原则访问的凭据、凡是不应在运行时暴露给调试接口的配置、凡是一旦泄露会导致业务风险的密钥，均应纳入敏感类别。
凭据轮换策略需要制度化。 事件披露后，Vercel 官方建议所有受影响项目立即轮换非敏感环境变量中的凭据。轮换操作应覆盖以下范围：所有在非敏感变量中存储的 API 密钥、与外部服务交互的访问令牌、数据库连接凭据、以及可能已暴露的配置文件中的认证信息。轮换周期上，建议对生产环境密钥实行每 90 天轮换的策略，对高风险凭据（如具有服务管理权限的管理员密钥）实行更短的轮换周期。
第三方 OAuth 应用审计应纳入常规安全检查。 此次攻击的起点是第三方应用的 OAuth 凭据被攻破。工程团队应当定期审查已授权的 OAuth 应用列表，移除不再使用或来源不明的集成应用。对于必需的 OAuth 授权，应遵循最小授权范围原则，仅授予应用完成任务所需的最小权限范围。此外，建议为关键账号启用多因素认证，即使 OAuth 令牌被窃取，攻击者仍无法仅凭令牌完成身份验证。
监控与告警体系需要覆盖环境变量访问行为。 建议在运维监控平台中配置针对环境变量读取操作的告警规则。任何异常的大量环境变量读取请求、来自非预期 IP 地址的访问、以及管理员账号对敏感配置的访问尝试，都应触发安全团队的关注。Vercel 平台提供的审计日志功能应当被充分利用，所有对项目配置的修改和读取操作都应被记录并定期审查。
事件响应预案需要包含环境变量泄露场景。 当发生类似安全事件时，响应流程应包括以下步骤：立即隔离受影响的部署环境、评估暴露变量是否包含有效凭据、批量轮换所有可能暴露的密钥、审查是否有异常数据访问或横向移动迹象、重新部署应用并使用新凭据。事件后的复盘应形成书面报告，明确暴露原因并制定针对性的加固计划。
关键配置参数参考
以下参数可作为工程团队实施环境变量安全加固的实际参考：
在 Vercel 平台中，将环境变量标记为敏感的操作为在变量编辑界面勾选「Sensitive」选项。敏感变量在部署时通过环境注入的方式传递到运行时，但不会在任何 API 响应或仪表板界面中回显。对于需要程序化读取敏感变量的场景，应通过安全的密钥管理服务（如 AWS Secrets Manager 或 HashiCorp Vault）进行读取，而非依赖平台的内置回显功能。
OAuth 应用授权审查频率建议设为每季度一次，重点检查应用权限范围、授权账号数量、以及应用的发布者可信度。对于拥有团队管理权限的账号，应强制要求绑定硬件安全密钥或支持 FIDO2 协议的认证方式，以防范令牌被盗用后的账号接管。
凭据轮换自动化可通过 CI/CD 流水线实现。将凭据轮换脚本集成到发布流程中，每次部署前自动检查密钥有效期，超过预设阈值的密钥将被自动轮换。这种机制可以显著降低因人工疏忽导致的凭据长期未更新风险。
此次 Vercel 事件为云平台环境变量安全管理敲响了警钟。OAuth 授权的便捷性不应以牺牲安全边界为代价，而环境变量的分类管理则是最后一道防线。将敏感信息分级、凭据轮换制度化、第三方集成审计常态化、监控告警覆盖全流程，这些措施共同构成了防御类似攻击的纵深体系。
资料来源
- Vercel 官方安全公告（2026 年 4 月）：Vercel April 2026 security incident
- 安全分析报告：Vercel's April 2026 Incident: How a Context.ai OAuth Compromise Led to Environment Variable Exposure