OpenSourceMalware/vercel-april2026-incident-response

# Vercel 2026年4月事件响应指南 最后更新：2026年4月20日 12:07 AEST/布里斯班（v2 — 纳入Vercel首席执行官2026年4月20日的更新） ## 重要提示：这并非法律或官方建议 如果您认为自己已被入侵，请联系事件响应合作伙伴。此信息仅由开源恶意软件团队出于善意提供。如果您希望获得我们合作过的事件响应公司介绍，我们可以推荐几家。 ## 发生了什么？ Vercel于2026年4月19日披露，攻击者获得了未经授权的内部系统访问权限。以下是官方[公告](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident)：  4月20日，Vercel首席执行官Guillermo Rauch发布了详细更新，确认初始访问路径：一名Vercel员工使用了一个名为**Context.ai**的AI平台，该平台本身已被攻破；由此攻击者横向移动到该员工的Google Workspace账户，并进一步升级到Vercel环境。环境变量在静态时是加密的，但攻击者能够枚举未标记为“敏感”的变量。Vercel将攻击者描述为高度 sophisticated，并很可能借助AI加速。Google Mandiant已参与响应。Vercel表示Next.js、Turbopack及其开源项目是安全的。 以下是该安全公告中关于“已知指标”的重要部分：  细节相当简略。他们甚至没有告诉您*在哪里*检查那个孤立的Google IOC。作为Vercel客户，我对这个级别的细节感到失望。请告诉我需要查看什么！请告诉我去哪里判断自己是否已被入侵！ ### 在Vercel未提供细节的情况下，我们创建了本文档 **如果您运行在Vercel上的工作负载，请在证实之前假设以下情况：** 1. 环境变量**未**标记为“敏感”的，在任何Vercel项目暴露窗口期间都**可能被读取**。 2. 通过仪表板或`vercel env` CLI推送到Vercel且未轮换的凭据是**持续存在的负债**。 3. Vercel ↔ GitHub和Vercel ↔ Linear集成路径中的**令牌可能已被访问**。 4. 您不会很快得到“您受影响 / 未受影响”的明确信号。**先轮换，再调查**。 ## 已知与声称：请在简报中区分这两者 这一区分对于高管沟通以及避免过度响应（或响应不足）至关重要。 ### Vercel确认（公告与2026年4月20日CEO更新） - 对某些内部Vercel系统的未授权访问。 - **初始访问向量：Context.ai**，一名Vercel员工使用的AI平台已被攻破。攻击者利用该立足点破坏了员工的Vercel Google Workspace账户，随后从中进行横向提升。 - 客户环境变量在静态时加密。**被标记为“非敏感”的变量在攻击者进入后仍可被枚举**。 - 客户影响被描述为“非常有限”；Vercel已直接联系其有顾虑的客户。 - **Next.js、Turbopack和Vercel的开源项目已进行分析，并被认为保持安全**（即，截至Vercel 4月20日的声明，发布路径中未包含恶意工件）。 - 攻击者被描述为高度 sophisticated，并很可能显著借助AI加速。 - 响应合作伙伴：Google Mandiant已积极参与；外部IR公司、行业同行和执法部门已介入。 - Vercel已联系Context.ai以帮助了解完整范围。 - Vercel已推送UI改进：环境变量概览页面、增强的敏感环境变量管理。 ### 第三方报告/归因于攻击者（尚未被Vercel确认） - Linear和GitHub集成受到不成比例的影响（社区报告，尤其是X平台上的Theo Browne）。 - 数据在BreachForums上挂牌出售：内部数据库、员工账户、GitHub令牌、npm令牌、源代码片段、活动时间戳——报价约200万美元。 - 行为者自称ShinyHunters；历史上与该化名关联的其他行为者已否认参与。 - 特定客户数据类别被泄露，超出了Vercel直接向客户确认的范围。 将未经验证的报告视为**合理且可操作的**，以便进行您自己的分类，但不要在客户或监管机构沟通中将其作为事实引用，直到Vercel证实或您获得独立证据。暴露窗口中“**可枚举的环境变量**”（Rauch确认）与“**BreachForums上出售的npm + GitHub令牌**”（攻击者声称）之间的差距对供应链风险最为关键——出于轮换目的假设最坏情况，但在沟通中坚持已确认版本。 ## 范围界定：谁需要运行此剧本？ **最高优先级** — 您已收到Vercel的直接联系，**或**符合以下任一条件： - 您拥有（或曾拥有）Vercel ↔ GitHub集成，且具有仓库写入权限。 - 您拥有（或曾拥有）Vercel ↔ Linear集成。 - 您存储未加密的凭据（未标记为敏感）作为Vercel环境变量。 - 您从CI/CD发布npm包，且运行在或通过Vercel基础设施。 **标准优先级** — 任何拥有活跃Vercel项目的团队，即使是营销站点。营销站点通常持有CMS API密钥、分析令牌和表单处理Webhook，这些都可能横向移动到更敏感的系统。 **仍需执行** — 即使项目在事件发生前已被删除。问题在于凭据是否在Vercel中以可读形式驻留，而不是项目是否仍然存在。 ### 并行问题：您的组织是否直接暴露于Context.ai？ 2026年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读取、日历、驱动器和工作区目录范围具有高影响。 如果在您的环境中发现Context.ai使用，请撤销OAuth授权、轮换通过Context.ai工作流传递的任何凭据，并监控受影响用户的Google Workspace账户是否存在与Vercel描述相同的妥协指标。直接联系Context.ai以获取您自己的事件细节；Vercel已公开表示他们正在协调帮助其他受影响的组织。 ## 第0阶段：止血（前60分钟） 两个目标：防止新损害，保留证据。 1. **冻结部署。** 暂停生产分支上的自动部署。您希望防止攻击者修改后的构建被发布，并希望停止审计日志的变动。 2. **禁用Vercel的GitHub App。** 如果您安装了该App（如果您通过GitHub推送代码到Vercel则已安装）。您可以在以下位置找到已安装的GitHub App：`https://github.com/organizations//settings/installations`  3. **识别GitHub App的访问权限。** 点击上述配置按钮并审核该应用有权访问哪些仓库。这告诉您当前需要重点关注的内容。前往 GitHub → 组织 → 设置 → GitHub Apps → Vercel。审核： - 仓库访问（所有仓库或选定仓库） - 授予的权限 - 安装日期和安装者  1. **立即拍摄Vercel审计日志快照。** 导出或屏幕截图保存。保留窗口有限，且UI未公开全部内容。在开始更改污染日志之前获取这些内容。 您可以在 [https://vercel.com/activity-log](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. 在您的工作区管理[控制台](https://admin.google.com/ac/home)中，转到 **安全** > **访问和数据控制** > **API 控制**，找到已访问和待处理的应用程序。  2. 然后在不同的列表中查找IOC，它显然是一个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/personal-access-tokens) - 经典令牌可在以下位置找到：[https://github.com/settings/tokens](https://github.com/settings/tokens) - 立即轮换任何敏感的Vercel环境变量：[http://vercel.com/all-env-vars](http://vercel.com/all-env-vars) **第1级 — 今天之内、取决于应用暴露范围：** - 支付处理器密钥（Stripe、Adyen、Braintree等） - 身份验证签名密钥（NextAuth `AUTH_SECRET` / `NEXTAUTH_SECRET`、JWT签名密钥、会话Cookie密钥、CSRF令牌） - 具有写入权限的数据库连接字符串（`DATABASE_URL`、直接Postgres/MySQL URL、Mongo URI、带有认证的Redis） - 云提供商根或广泛范围的密钥（AWS IAM访问密钥、GCP服务账户JSON、Azure客户端密钥） - Webhook签名密钥（Stripe、GitHub、Slack — 轮换并更新发送方配置） **第2级 — 本周内轮换：** - 第三方SaaS API密钥（分析、邮件提供商、SMS、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:` 指向未固定SHAs - `vercel.json` — 构建命令变更、新的重写/重定向可能向外泄流量 - `next.config.js` / 框架配置 — 新的 `headers`、新的重定向到攻击基础设施 - 检查 **GitHub Actions运行历史记录**，查找意外运行，特别是手动触发的 `workflow_dispatch` 或来自已不存在分支的运行。 - 查看 **发布和标签创建**，这些并非您所创建。 ### 如果您从这些仓库发布npm包 这是Vercel初始妥协演变为供应链事件的地方。即使您不使用Vercel发布，如果攻击者获得了您的GitHub令牌且您的发布工作流使用该令牌： - 检查 `npm` 发布历史：`npm view time --json` 查找意外版本。 - 将每个最近版本的tarball与它声称来源的git标签进行比较。攻击者从与注册表中不匹配的标签发布。 - 审计工作流中对 `NPM_TOKEN` 的使用 — 轮换该令牌，审查谁有访问权限。 - 检查 `npm owner ls ` 是否有新增维护者。 - 如果您维护重要软件包，请检查tarball中的post-install脚本执行 — 解压并检查。 如果发现未经授权的发布，请向npm安全团队 (`security@npmjs.com`) 报告，并考虑在OSV.dev上提交。不要取消发布（unpublish） — 这有窗口期限制且会破坏下游消费者。 **关于Vercel自有包的特别说明**：Vercel 4月20日的更新表示Next.js、Turbopack及其开源项目已分析并被认为安全。这是Vercel对其自身发布路径的声明 — 您仍应如上审计自己的包。如果您使用Next.js或Turbopack，目前无需基于当前信息预置到事件前版本，但请关注Vercel的公告更新。 ## 第4阶段：Linear集成审查 如果您的团队使用Vercel ↔ Linear集成： - 审查 **Linear审计日志**（工作区设置 → 安全 → 审计日志），覆盖暴露窗口。 - 查找： - 新颁发的API密钥 - 新添加的集成 - 服务账户发布的评论 - Webhook目标变更 - 成员邀请 - 对问题数据的查看/导出（该集成对问题具有读取权限，其中常包含客户姓名、错误详情，有时甚至粘贴在票据中的凭据） - 特别关注：Linear问题中经常**粘贴开发者调试密钥**。对您的Linear工作空间进行Grep，查找常见泄露模式（`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密钥。 ### 有用的IOC探测原语 将攻击者控制的域名或IP地址（由Vercel或IR合作伙伴发布）粘贴到以下位置： - 您前端的HTTP访问日志（攻击者有时会在采取行动前探测以确认访问）。 - DNS日志 — 服务器发起的对非常规域名的解析。 - 出站代理 / VPC流量日志。 截至发布时，Vercel尚未公布IOC。请关注Vercel公告和知名IR公司的撰写内容以获取更新。 ## 第6阶段：检测潜伏性妥协 平台层妥协后的攻击者持久化通常采用以下形式。积极排查每种情况： 1. **团队的新成员或协作者**，在Vercel团队、GitHub组织、Linear工作空间或云账户中。创建时间落在暴露窗口内。 2. **SSO提供程序上的新OAuth授权**，针对您的开发者账户（Google Workspace、Okta、Entra ID）。 3. **CI/CD配置的修改** — 现在会拨打电话回家的新工作流、新的自托管运行器、名称看似无害的新密钥。 4. **Vercel上的意外部署** — 检查部署历史记录，寻找无法追溯到已知作者/提交的部署。 5. **服务器端函数日志中的反向Shell指标** — base64编码的数据块被写入/执行、不寻常的出站连接来自边缘/服务器端函数。 6. **DNS漂移** — 通过 `vercel.json` 或框架配置添加的新子域名、CNAME更改、重定向。 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）在运行时访问，而不是嵌入环境变量。 - **清点第三方OAuth应用。** 连接到您的工作区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应用范围的最小权限原则。** 如果Vercel不需要整个组织的仓库访问权限，请限制到它实际部署的仓库。 - **作为例行操作轮换部署钩子。** 每季度一次。 - **在预提交和CI中构建密钥扫描。** 使用TruffleHog或gitleaks等工具。追溯性扫描仓库历史以查找可能已轮换但仍存在于克隆中的内容。 - **记录您的Vercel集成足迹**，作为SOC 2/ISO证据。您将被客户询问。 - **作为桌面演练运行此剧本**，针对另一个平台提供商的类似形状事件。事件并非Vercel独有，肌肉记忆具有通用性。 ## 参考 - Vercel安全公告： https://vercel.com/kb/bulletin/vercel-april-2026-security-incident - Guillermo Rauch（Vercel首席执行官）2026年4月20日更新：https://x.com/rauchg/status/2045995362499076169 - 敏感环境变量文档：https://vercel.com/docs/environment-variables/sensitive-environment-variables - Vercel审计日志：团队设置 → 审计日志 - GitHub审计日志API：https://docs.github.com/en/rest/orgs/orgs#get-the-audit-log-for-an-organization - npm安全联系人：security@npmjs.com - OAIC可通知数据泄露方案：https://www.oaic.gov.au/privacy/notifiable-data-breaches - BleepingComputer报道：https://www.bleepingcomputer.com/news/security/vercel-confirms-breach-as-hackers-claim-to-be-selling-stolen-data/ ## 更新日志 - **2026-04-20 (v2)** — 根据Vercel首席执行官Guillermo Rauch 2026年4月20日的声明更新。将多项内容从“报告”提升为“确认”：Context.ai被命名为被攻破的上游供应商、Vercel员工Google Workspace账户作为横向移动的跳板、非敏感环境变量的枚举作为平台内的横向移动。添加了并行排查Context.ai直接暴露的章节。添加了Vercel关于Next.js、Turbopack和开源项目保持安全的声明。添加了Mandiant参与信息。加强了OAuth应用清单建议。 - **2026-04-20 (v1)** — 初始版本。基于Vercel 2026年4月19日公告和同时期公开报道。在Vercel发布更多细节、IOC或更窄的暴露窗口时更新。

标签：2026年4月, AI平台, APT, BurpSuite集成, Compromise, Context.ai, Cutter, Google Mandiant, Google Workspace, Incident Response, IOC, OSV, Turbopack, Vercel, 云端安全, 安全事件, 安全通告, 密钥泄露, 工作负载安全, 库, 应急响应, 开源项目安全, 指标妥协, 敏感变量, 漏洞利用检测, 环境变量, 环境枚举