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上运行工作负载，请假设以下情况属实，直至证明并非如此：
- 在暴露窗口期内，任何Vercel项目上未标记为"敏感"的环境变量可能已被读取。
- 通过仪表盘或
vercel env CLI推送到Vercel且未轮换的任何凭据均为持续存在的风险。
- Vercel ↔ GitHub 和 Vercel ↔ Linear 集成路径内的令牌可能已被访问。
- 您不会很快收到明确的"你受影响/你未受影响"的信号。先轮换，再调查。
已知与声称：在简报中需将其分开
这一区别对于高管沟通以及避免过度响应（或响应不足）至关重要。
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分钟）
两个目标：防止新损害，保留证据。
-
冻结部署。 暂停生产分支上的自动部署。您希望防止攻击者修改后的构建上线，并希望阻止审计日志持续滚动。
-
禁用Vercel的GitHub App。 如果您安装了Vercel GitHub App（当您将新代码推送到GitHub时自动部署到Vercel，则必然会安装），可以在此处找到已安装的GitHub Apps：https://github.com/organizations/<GitHub-Organization>/settings/installations
-
确定GitHub App拥有的访问权限。 单击上述配置按钮，审计Vercel App有权访问哪些仓库。这告诉您现在需要重点关注什么。前往GitHub → 组织 → 设置 → GitHub Apps → Vercel。审查：
- 仓库访问权限（所有仓库 vs. 选定仓库）
- 已授予的权限
- 安装日期及安装者
- 为您的团队快照Vercel审计日志。 立即导出或截屏。保留窗口有限且UI并未暴露所有内容。在开始进行会污染日志的更改之前获取它。您可以在 https://vercel.com/activity-log 找到它。
- 启用"Observability Plus"。 这是Vercel的一项额外付费功能，建议您启用并为此付费很讨厌，但在这种情况下，我认为这是事件响应期间的最佳做法。我当然对此不满意，但已启用它，因为它保存审计日志的时间比默认的非常短的时长更长。
- 盘点暴露范围。 对于您控制的每个Vercel团队/账户，列出：
- 项目及其关联的Git仓库
- 已连接的集成（GitHub App、Linear、Slack、市场集成）
- 团队成员及其角色
- 在团队下签发的个人访问令牌/API令牌
- 部署钩子
- 审查GitHub组织审计日志。 在暴露窗口期（保守起见，2026年4月1日至15日至今）内查找。过滤：
repo.add_member、repo.add_topicorg.invite_member、org.add_memberintegration_installation、integration_installation.repositories_addedprotected_branch.destroy、protected_branch.updategit.ref.force_push 或推送事件上的强制推送标志- 新的部署密钥、新的webhook、新的Actions机密或变量
- 任何组织成员创建的新PAT、新细粒度令牌
oauth_access.create、
此时不要发布公告或轮换密钥。您需要先获取快照。
阶段1：检查入侵指标（IOC）
Vercel公告中的细节相当有限：
据我们所知，他们建议您前往Google Workspace管理控制台并查找这个googleusercontent.com应用。以下是在控制台中查找的方法：
-
在工作区管理控制台中，转至安全 > 访问和数据控制 > API控制，找到已访问和待处理的应用。
-
然后在不同列表中查找该入侵指标，即一个OAuth应用：110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
如果找到，立即移除并咨询事件响应合作伙伴。这超出了我的能力范围。
阶段2：凭据轮换
轮换是单一最高价值行动。按优先顺序进行，以便如果中断，最危险的内容已处理。
您需要轮换的内容取决于您的GitHub和Vercel环境中暴露了什么。从GitHub PAT等开始，使用本指南逐步展开。
优先级层级
第0层 — 今天轮换，优先于其他所有内容：
第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的仓库：
- 将
main/master HEAD 与事件窗口前您已知安全的标签/提交进行差异比较。
- 查找对以下内容的更改：
package.json → scripts（尤其是 postinstall、prepare、preinstall）package-lock.json / pnpm-lock.yaml / yarn.lock — 意外的依赖添加或版本升级.github/workflows/*.yml — 新工作流、新 run: 步骤、新 uses: 使用未固定SHAvercel.json — 构建命令更改、可能窃取流量的新重写/重定向- / 框架配置 — 新 、指向攻击者基础设施的新
如果您从这些仓库发布npm包
这是Vercel初始入侵可能演变为供应链事件的地方。即使您不使用Vercel发布，如果攻击者获取了您的GitHub令牌并且您的发布工作流使用该令牌：
- 检查npm发布历史：
npm view <pkg> time --json 查找意外版本。
- 将每个最近版本的tarball与其声称来源的git标签进行比较。攻击者从与注册表中内容不匹配的标签发布。
- 审计工作流中的
NPM_TOKEN 使用 — 轮换令牌，审查谁有权访问。
- 检查是否有新维护者添加到您的包：
npm owner ls <pkg>。
- 如果您维护任何重要内容，注意tarball中的后安装脚本执行 — 解压并检查。
如果发现未授权发布的证据，向npm安全部门（[email protected]）报告，并考虑向OSV.dev提交。弃用错误版本；不要取消发布（取消发布有时间限制且会破坏下游消费者）。
关于Vercel自有包的说明：Vercel 4月20日的更新指出Next.js、Turbopack及其开源项目已被分析并相信安全。这是Vercel关于其自身发布路径的声明 — 您仍应如上所述审计您的包。如果您使用Next.js或Turbopack，根据当前信息您无需作为预防措施固定到事件前版本，但请关注Vercel公告以了解该立场的任何变化。
阶段4：Linear集成审查
如果您的团队使用Vercel ↔ Linear集成：
- 审查Linear审计日志（工作区设置 → 安全 → 审计日志），查看暴露窗口期。
- 查找：
- 新签发的API密钥
- 新添加的集成
- 服务账户发布的评论
- Webhook目标地址的更改
- 成员邀请
- 问题数据视图/导出（集成具有问题的读取权限，问题中常包含客户名称、错误详情，有时还有粘贴到工单中的凭据）
- 特别关注：Linear问题中经常包含开发者调试时粘贴的秘密。在您的Linear工作区中搜索常见泄露模式（
AKIA、sk_live_、ghp_、ghs_、npm_、eyJ、----BEGIN）。找到的任何内容都应轮换。
阶段5：下游系统日志审查
轮换凭据在大多数情况下会清除攻击者的持久化手段，但他们可能已经使用了该访问权限。检查您的已轮换密钥的消费者，看是否在暴露窗口期内有使用迹象。
要检查的时间窗口
使用2026年4月1日至今作为保守下限。事件于4月19日披露，但初始访问在披露之前。如果Vercel发布更具体的日期，我们将相应缩小范围。
要查询的内容
- AWS CloudTrail — 来自受损IAM密钥的异常API调用，特别是针对S3存储桶的
GetObject 爆发，CreateUser、AttachUserPolicy、来自新ASN/国家/地区的控制台登录。
- 数据库审计日志 — 对敏感表的异常
SELECT *、大量导出、来自意外源IP的连接。
- Stripe / 支付日志 — 异常的客户创建、转账创建、API密钥创建。
- 身份验证提供商日志（Auth0、Clerk、Cognito、Firebase）— 不可能旅行登录、管理员用户的密码重置触发、新应用注册。
- 电子邮件提供商（SendGrid、Postmark 等）— 意外的外发活动、新API密钥、发送者身份更改。
- GitHub — 克隆、复刻创建、具有仓库访问权限的用户账户上的新SSH密钥。
有用的入侵指标搜寻原语
将Vercel或事件响应合作伙伴发布的任何攻击者控制的主机名或IP粘贴到：
- 您前端的HTTP访问日志（攻击者有时会在行动前预先探测以确认访问权限）。
- DNS日志 — 从您的服务器到异常域名的出站解析。
- 出站代理/VPC流日志。
截至发布时，Vercel尚未发布任何入侵指标。请关注Vercel公告和知名事件响应公司的博客文章以获取更新。
阶段6：检测持久化入侵
平台层入侵后，攻击者的持久化手段通常采用以下形式。主动搜寻每种形式：1. Vercel 团队中的新成员或协作者、GitHub 组织、Linear 工作空间或云账户。日期在暴露窗口内。
2. 已连接 SSO 提供商（Google Workspace、Okta、Entra ID）上为开发者账户新增的 OAuth 授权。
3. 已修改的 CI/CD 配置 — 现在含回连功能的工作流、新的自托管运行器、名称无害的新机密。
4. Vercel 中意外的部署 — 检查部署历史，查找无法映射到已知作者已知提交的部署。
5. Serverless 函数日志中的反向 Shell 指标 — 正在写入/执行的 Base64 数据块、来自 Edge/Serverless Functions 的异常出站连接。
6. DNS 漂移 — 新的子域名、CNAME 更改、通过 vercel.json 或框架配置添加的重定向。
7. 身份验证更改 — MFA 被禁用、恢复代码重新生成、密码在用户未操作的情况下更改。
沟通
内部
指定一名事件指挥官。在轮换进行期间，至少每日开一次站会。一份单一信息源文档，记录“已轮换内容、待处理内容、已发现内容”。如果 Linear 在事件范围内，请勿使用 Linear 进行记录——使用侧信道。
面向客户
咨询法律顾问。通知门槛因地区而异，但：
- GDPR：对于影响欧盟居民的可通知违规行为，时限为 72 小时。
- 澳大利亚（《不可通知的数据泄露计划》，OAIC）：在可能造成严重损害的情况下，尽快通知。
- 美国：各州规定不同；部分州有 30 至 60 天的窗口，其他则要求针对特定数据类别立即通知。
- 加州（CCPA）：如果涉及加州居民的个人信息，有特定义务。
- SOC 2 / ISO 27001 客户：合同中的通知条款通常比法规最低要求更早。请阅读您的 MSA。
如果您没有证据表明数据已从您的系统中外泄，您可能尚未触发通知义务——但仅凭“我们使用 Vercel，而 Vercel 发生了事件”通常不足以触发通知，除非敏感数据确实存在重大风险。记录您的推理过程。
准备声明
在需要之前起草好这些声明：
- 内部全体会议
- 面向客户的建议书
- 监管机构通知模板
- 状态页面更新（如公开）
公开归因规范
不要公开将攻击者的声明当作事实进行复述。以 Vercel 公告为主要来源，链接到它。让 Vercel 自行描述他们的事件——您只需在自己的范围内描述自己的暴露情况。
中期加固（事件后）
此事件暴露了即使您最终未受影响也值得修复的结构性问题。
- 将所有机密迁移到 Vercel 的敏感环境变量功能。 将其设为团队默认设置。培训开发人员在创建时标记。
- 尽可能采用短期凭据。 使用 GitHub OIDC 联合到 AWS/GCP/Azure，而不是将长期存在的访问密钥镜像到 Vercel 环境变量中。使用云原生机密管理器（AWS Secrets Manager、GCP Secret Manager）在运行时访问，而不是嵌入环境变量。
- 清点与您的 Google Workspace、Microsoft 365、GitHub 组织以及 Vercel 团队连接的所有第三方 OAuth 应用。 Vercel IAV 是 Context.ai——一个通过 OAuth 集成到员工 Google Workspace 的 AI 平台。同样的风险类别存在于每个对 SaaS 和 AI 工具集成采取宽松审批政策的组织中，而在过去 18 个月的 AI 工具淘金热中，“什么可以获批”的门槛已大幅降低。具体行动：
- 拉取您的 Google Workspace OAuth 应用报告（管理控制台 → 安全 → API 控件 → 应用访问控制）。审查所有具有敏感范围（
gmail.readonly、calendar、drive、admin.directory）的应用。
- 对 Microsoft 365 执行相同操作（Entra ID → 企业应用程序）。
- 设立季度审查。对于携带敏感范围的新的 OAuth 授权，要求安全团队签字。
- 考虑将 OAuth 应用的安装限制为允许列表，而非由用户自行批准。
- 在 GitHub App 权限上遵循最小权限原则。 如果 Vercel 不需要组织级别的仓库访问，则限制到它实际部署的仓库。
- 将部署钩子轮换作为常规工作。 每季度一次。
- 在您的 pre-commit 和 CI 中构建机密扫描。 Trufflehog、gitleaks 或类似工具。对仓库历史进行追溯扫描，查找任何可能已被提交然后轮换的内容——假设曾经提交的内容仍存在于某个 clone 中。
- 审计 Vercel 账户配置，而不仅仅是机密。 轮换令牌可以处理泄露，但会留下结构性的暴露：最终出现在客户端的
NEXT_PUBLIC_ 值、没有到期时间或范围的令牌、在预览中关闭的部署保护、悬空别名、未签名的 Webhook。这些存在于 Vercel API 配置中，而非源码树中，因此机密扫描器会错过它们。一个开源选项：vercelsior。
- 将您的 Vercel 集成足迹记录为 SOC 2 / ISO 证据的一部分。 客户将会询问您。
- 在 Q3，针对另一个平台提供商上假设的类似事件，运行此行动手册作为桌面推演。 该事件并非 Vercel 独有；肌肉记忆具有通用性。
参考
变更日志
- 2026-04-20 (v2) — 根据 Vercel CEO Guillermo Rauch 4 月 20 日的声明进行更新。将几个项目从“报告”提升到“已确认”：Context.ai 被命名为被攻破的上游供应商，Vercel 员工的 Google Workspace 账户作为支点，枚举非敏感环境变量作为平台内横向移动。添加了针对 Context.ai 直接暴露的并行范围界定。添加了 Vercel 关于 Next.js、Turbopack 和 OSS 项目保持安全的声明。添加了 Mandiant 参与。强化了 OAuth 应用清点建议。
- 2026-04-20 (v1) — 初始版本。基于 2026-04-19 的 Vercel 公告和同期公开报道制作。随着 Vercel 发布更多细节、IOC 或更窄的暴露窗口进行更新。
