Vercel 2026年4月事件响应指南

最后更新：2026年4月20日 @ 12:07 PM AEST/布里斯班 - (v2 — 包含Vercel CEO于4月20日的更新)

重要提示：本文并非法律或官方建议。如果您认为自己已遭受入侵，请联系事件响应合作伙伴。此信息由OpenSourceMalware团队出于善意提供。如果您希望获得事件响应公司的引荐，我们可以推荐几家曾合作过的公司。

---

发生了什么？

Vercel于2026年4月19日披露，一名攻击者未经授权访问了内部系统。以下是官方公告：

4月20日，Vercel首席执行官Guillermo Rauch发布了一份详细更新，确认了初始访问路径：一名Vercel员工使用了一个名为Context.ai的AI平台，该平台本身遭到了入侵；攻击者从那里进入该员工的Google Workspace账户，并升级权限进入Vercel环境。环境变量在静态存储时已加密，但攻击者能够枚举未标记为"敏感"的变量。Vercel将攻击者描述为高度复杂且可能借助AI加速。Google Mandiant已参与响应。Vercel声明Next.js、Turbopack及其开源项目仍然安全。

以下是该安全公告中重要的入侵指标部分：

细节相当有限。他们甚至没有告诉你在哪里检查那一个孤立的Google入侵指标。作为Vercel客户，我对这种级别的细节感到相当失望。请帮助我理解应该查找什么！告诉我去哪里了解自己是否已遭入侵！

在Vercel缺乏细节的情况下，我们创建了这份文档

如果您在Vercel上运行工作负载，请假设以下情况属实，直至证明并非如此：

1. 在暴露窗口期内，任何Vercel项目上未标记为"敏感"的环境变量可能已被读取。
2. 通过仪表盘或vercel env CLI推送到Vercel且未轮换的任何凭据均为持续存在的风险。
3. Vercel ↔ GitHub 和 Vercel ↔ Linear 集成路径内的令牌可能已被访问。
4. 您不会很快收到明确的"你受影响/你未受影响"的信号。先轮换，再调查。

---

已知与声称：在简报中需将其分开

这一区别对于高管沟通以及避免过度响应（或响应不足）至关重要。

Vercel确认的信息（公告 + 4月20日CEO更新）

• 对某些Vercel内部系统的未授权访问。
• 初始访问向量：Context.ai，一名Vercel员工使用的AI平台，遭到入侵。攻击者利用该立足点入侵该员工的Vercel Google Workspace账户，然后从那里升级权限进入Vercel环境。
• 客户环境变量在静态存储时已加密。但标记为"非敏感"的变量一旦攻击者进入内部仍可被枚举。
• 客户影响被描述为"相当有限"；Vercel已直接联系其关心的客户。
• Next.js、Turbopack和Vercel的开源项目已被分析，并相信仍然安全（即，截至Vercel 4月20日的声明，这些项目的发布路径中无恶意产物）。
• 攻击者被描述为高度复杂，且可能显著借助AI加速。
• 响应合作伙伴：Google Mandiant正积极参与；外部事件响应公司、行业同行及执法部门已介入。
• Vercel已联系Context.ai以帮助了解完整范围。
• Vercel已推出UI改进：环境变量概览页面，改进的敏感环境变量管理。

第三方及攻击者报告/归因（未经Vercel确认）

• Linear和GitHub集成受到不成比例的影响（社区报告，尤其是Theo Browne在X平台上的说法）。
• 列在BreachForums上待售的数据：内部数据库、员工账户、GitHub令牌、npm令牌、源代码片段、活动时间戳——标价约200万美元。
• 攻击者自称为ShinyHunters；历史上与该代号相关的其他行为者已否认参与。
• 超出Vercel直接与客户确认范围之外的特定客户数据类型被窃取。

将未经确认的报告视为合理且可操作，用于您自身的分类排查，但在Vercel证实或您获得独立证据之前，勿在客户或监管机构沟通中将其作为事实引用。"可枚举的环境变量"（Rauch确认）与"在BreachForums上出售的npm + GitHub令牌"（攻击者声称）之间的差距，对于供应链风险最为关键——为轮换目的假设最坏情况，但在沟通中坚持已确认的版本。

---

范围界定：谁需要执行此手册

最高紧急程度——您收到了Vercel的直接联系，或符合以下任一条件：

• 您拥有（或曾拥有）具有仓库写入权限的Vercel ↔ GitHub集成。
• 您拥有（或曾拥有）Vercel ↔ Linear集成。
• 您将未加密的秘密（未标记为敏感）存储为Vercel环境变量。
• 您从运行在Vercel基础设施上或通过其运行的CI/CD发布npm包。

标准紧急程度——任何拥有活跃Vercel项目的团队，即使只是营销网站。营销网站通常包含CMS API密钥、分析令牌和表单处理webhook，这些可能转向更敏感的系统。

仍然要执行——即使您的项目在事件发生前已被删除。问题不在于项目是否仍然存在，而在于秘密是否曾以可读形式驻留在Vercel中。

并行问题：您的组织是否直接暴露于Context.ai？

4月20日的更新指出Context.ai是遭到入侵的上游供应商。如果您组织中的任何人独立于Vercel使用Context.ai——用于会议情报、知识管理、CRM增强或任何其他工作流程——您可能拥有独立于Vercel事件的自身暴露窗口。

并行执行这些检查：

• 查询您的SSO/IdP（Okta、Entra、Google Workspace），查找任何已向Context.ai或与Context相关的OAuth应用进行身份验证的用户。
• 在您的Google Workspace管理控制台 → 安全 → OAuth应用访问日志中搜索context.ai或关联的应用ID。
• 检查企业费用/SaaS支出管理工具中是否有Context.ai订阅。
• 审查已授予的OAuth范围——Gmail读取、日历、云端硬盘和Workspace目录范围影响重大。

如果您发现环境中使用了Context.ai，撤销OAuth授权，轮换任何经过Context.ai工作流程的凭据，并监控受影响用户的Google Workspace账户，查找Vercel在其员工账户上看到的相同入侵指标。直接联系Context.ai获取您自身的事件详情；Vercel已公开表示他们正在与Context协调以帮助其他受影响组织。

---

阶段0：止损（前60分钟）

两个目标：防止新损害，保留证据。

1. 冻结部署。 暂停生产分支上的自动部署。您希望防止攻击者修改后的构建上线，并希望阻止审计日志持续滚动。

2. 禁用Vercel的GitHub App。 如果您安装了Vercel GitHub App（当您将新代码推送到GitHub时自动部署到Vercel，则必然会安装），可以在此处找到已安装的GitHub Apps：https://github.com/organizations/<GitHub-Organization>/settings/installations

   

3. 确定GitHub App拥有的访问权限。 单击上述配置按钮，审计Vercel App有权访问哪些仓库。这告诉您现在需要重点关注什么。前往GitHub → 组织 → 设置 → GitHub Apps → Vercel。审查：

   • 仓库访问权限（所有仓库 vs. 选定仓库）
   • 已授予的权限
   • 安装日期及安装者

1. 为您的团队快照Vercel审计日志。 立即导出或截屏。保留窗口有限且UI并未暴露所有内容。在开始进行会污染日志的更改之前获取它。您可以在 https://vercel.com/activity-log 找到它。
2. 启用"Observability Plus"。 这是Vercel的一项额外付费功能，建议您启用并为此付费很讨厌，但在这种情况下，我认为这是事件响应期间的最佳做法。我当然对此不满意，但已启用它，因为它保存审计日志的时间比默认的非常短的时长更长。
3. 盘点暴露范围。 对于您控制的每个Vercel团队/账户，列出：
   • 项目及其关联的Git仓库
   • 已连接的集成（GitHub App、Linear、Slack、市场集成）
   • 团队成员及其角色
   • 在团队下签发的个人访问令牌/API令牌
   • 部署钩子
4. 审查GitHub组织审计日志。 在暴露窗口期（保守起见，2026年4月1日至15日至今）内查找。过滤：
   • repo.add_member、repo.add_topic
   • org.invite_member、org.add_member
   • integration_installation、integration_installation.repositories_added
   • protected_branch.destroy、protected_branch.update
   • git.ref.force_push 或推送事件上的强制推送标志
   • 新的部署密钥、新的webhook、新的Actions机密或变量
   • 任何组织成员创建的新PAT、新细粒度令牌
   • oauth_access.create、oauth_authorization.create
5. 识别您的"皇冠宝石"环境变量。 标记任何能让攻击者横向移动的内容：支付处理器密钥、数据库URL、身份验证密钥、云提供商密钥（AWS/GCP/Azure）、第三方SaaS的管理API密钥。
6. 创建跟踪工单/事件频道。 即使最终发现未受影响，运行本手册的产物也值得保留。

此时不要发布公告或轮换密钥。您需要先获取快照。

---

阶段1：检查入侵指标（IOC）

Vercel公告中的细节相当有限：

据我们所知，他们建议您前往Google Workspace管理控制台并查找这个googleusercontent.com应用。以下是在控制台中查找的方法：

1. 在工作区管理控制台中，转至安全 > 访问和数据控制 > API控制，找到已访问和待处理的应用。

   

2. 然后在不同列表中查找该入侵指标，即一个OAuth应用：110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

   

3. 如果找到，立即移除并咨询事件响应合作伙伴。这超出了我的能力范围。

---

阶段2：凭据轮换

轮换是单一最高价值行动。按优先顺序进行，以便如果中断，最危险的内容已处理。

您需要轮换的内容取决于您的GitHub和Vercel环境中暴露了什么。从GitHub PAT等开始，使用本指南逐步展开。

优先级层级

第0层 — 今天轮换，优先于其他所有内容：

• 立即轮换所有GitHub PAT并终止所有现有会话。个人访问令牌（PAT）有以下两种类型：
  • 细粒度令牌可在此处找到： https://github.com/settings/personal-access-tokens
  • 经典令牌可在此处找到： https://github.com/settings/tokens
• 立即轮换任何敏感的Vercel环境变量： http://vercel.com/all-env-vars

第1层 — 今天轮换，取决于您的应用暴露了什么：

• 支付处理器密钥（Stripe、Adyen、Braintree等）
• 身份验证签名密钥（NextAuth AUTH_SECRET / NEXTAUTH_SECRET、JWT签名密钥、会话cookie密钥、CSRF令牌）
• 具有写入权限的数据库连接字符串（DATABASE_URL、直接的Postgres/MySQL URL、Mongo URIs、带身份验证的Redis）
• 云提供商根级或广泛范围密钥（AWS IAM访问密钥、GCP服务账户JSON、Azure客户端密码）
• Webhook签名密钥（Stripe、GitHub、Slack — 轮换并更新发送方配置）

第2层 — 本周轮换：

• 第三方SaaS API密钥（分析、电子邮件提供商、短信、CRM）
• 您拥有应用的OAuth客户端密码
• SMTP凭据
• 应用层加密的加密密钥（通过版本升级轮换，而非直接替换）
• CDN清除密钥、图片服务密钥
• 功能开关提供程序密钥

第3层 — 方便时轮换，但仍需轮换：

• 只读分析令牌
• Sentry/日志记录DSN（注意：如果您能接受短暂的事件丢失窗口，DSN轮换并非关键）
• 公钥和匿名密钥（仍需轮换——它们可能暴露项目存在性并有时允许枚举）

操作顺序陷阱

• 会话签名密钥轮换将使所有活跃会话失效。 计划强制登出事件。进行沟通。
• Webhook密钥必须在两端同时轮换。 先更新发送方（Stripe、GitHub）使用新密钥发送，然后接收方使用新密钥验证。或临时同时支持两者。
• 数据库凭据——先创建新用户，部署，然后撤销旧用户。不要直接替换，否则会导致中断。
• AWS密钥 — 如果您要轮换IAM用户的访问密钥，先创建第二个密钥，滚动部署，然后删除第一个。不要仅停用并寄希望于它。
• 环境变量更改后重新部署。 对于许多框架配置，Vercel环境变量在构建时嵌入。仅更改环境变量而不重新部署，更改不会完全生效。
• 同时检查您的CI密钥。 如果某个密钥已镜像到GitHub Actions、CircleCI或类似平台，轮换镜像。

不要忘记这些常见的遗漏

• .env.local 提交到私有仓库（仍是个问题——源代码可能已被窃取）
• Vercel预览/开发环境中的密钥，不仅仅是生产环境
• 存储为Vercel"团队级别"共享环境变量的密钥
• 部署钩子（轮换它们；它们是完整的部署触发器）
• 在您的账户下签发的Vercel个人访问令牌
• 授权Vercel GitHub App安装的GitHub个人访问令牌（与应用本身分开）

---

阶段3：仓库级别排查

对于连接到Vercel的仓库：