适用对象：在 GitHub 上开发或管理仓库的个人和组织，以及使用 GitHub Actions 或云凭据（包括 OIDC 联合）的人。本文依据调查的安全公司的公开文章和一家相关服务商的通知，不涉及攻击步骤。
続報待ち：この記事は公式発表に合わせて更新します
- 适用对象
在 GitHub 上开发或管理仓库的个人和组织，以及使用 GitHub Actions 或云凭据（包括 OIDC 联合）的人。
- 已确认的影响范围查看表格 ↓
- 约 4,800 个账户被滥用
- 向 61,764 个仓库发送试探性拉取请求
- 有恶意变更的仓库
另外3项
- 恶意代码运行并发送出凭据
- 密钥和云凭据被窃
- 已发布软件包被污染
被列为可能涉及的项目
- 云端持久化（轮换后仍然存在的设置）
- 尚未确认的事项
- 受影响账户和仓库的最终数量（调查的各公司统计口径不同）
- 令牌最初是如何被盗的（除云服务商的情形外，整个攻击活动尚未查明）
- GitHub 的官方声明（截至 11 月 14 日我们查看时未说明）
另外2项
- 与同一攻击者此前 10 月另一次攻击活动的关系（A、C 公司不断言为同一攻击者）
- 云服务商令牌撤销的完成情况（该服务商补充说明撤销中途停止）
- 现在要做的事查看步骤 ↓
- 检查是否有不认识的拉取请求、分支和 Actions 运行记录
- 撤销被攻陷账户的令牌、授权和会话
- 如果恶意变更可能已运行，请轮换该仓库能够读取的所有密钥和云权限
另外3项
- 检查云端是否有在轮换后仍然存在的变更
- 盘点您的令牌和第三方应用
- 检查您自己的应用没有暴露版本控制文件夹
- 核实来源（出处）全部来源 ↓
- GitHub，《Changelog》和《Security》（官方博客和更新日志；没有关于此事的条目；11 月 14 日查看）— github.blog / github.blog
- 最后核实
- 截至 2026 年 11 月 14 日
续报计划与核实记录
调查的各公司的文章均发布于 11 月 12 日，并可能有所修订。截至 11 月 14 日，GitHub 的博客、更新日志和状态历史中均没有关于此事的条目。
仓库所有者和开发者今天应该做什么
检查是否有不认识的拉取请求、分支和 Actions 运行记录
在您的账户有写入权限的每个仓库中（包括您作为协作者的组织），检查 11 月 10 日以来的以下三项。据 A 公司称，在 61,839 个试探性拉取请求中，有 10,431 个发往该账户并非所有者的仓库，是通过协作者或组织权限到达的。
- 您和队友都没有提交过的拉取请求。即使标题看起来无害（如更新文档），在大量仓库中出现同样的模式也是一个警告信号
- 不认识的短期分支，或分支被创建后又删除的迹象
- Actions 运行历史中有不认识的运行，或运行编号出现缺口。A、C 两家公司写道，攻击者会在约一分钟内删除运行记录和日志，因此编号缺口是一条线索。也请检查组织的审计日志
如果发现其中任何一项，请继续往下看。A 公司写道，有试探性拉取请求的账户，即使后一阶段没有运行，也应视为已被攻陷。
撤销被攻陷账户的令牌、授权和会话
此顺序依照 B、C 两家公司的建议。
- 撤销个人访问令牌、对第三方应用（OAuth 应用和 GitHub 应用）的授权、SSH 密钥和活动会话，然后只重新创建所需的
- 启用双重认证。已经被盗的令牌无需它也能使用，因此先撤销令牌（本站的看法）
- 关闭试探性拉取请求，并删除不认识的分支。删除前，请记录它们是在哪个账户下创建的
如果恶意变更可能已运行，请轮换该仓库能够读取的所有密钥和云权限
A、B 两家公司写道，如果恶意变更已运行，则该工作流可用的所有密钥和云角色都应视为已被窃取。
- 重新签发 Actions 密钥和变量（仓库、环境和组织级别）、发布令牌（包括用于软件包的）和部署密钥，并使旧的失效
- 如果您使用 OIDC 访问云账户，请把该云权限包括在内（下一步）
- 如果您在开发机上构建过可能收到恶意变更的仓库，也请轮换该机器可读取的凭据（SSH 密钥、云凭据、软件包发布令牌等）。B、C 两家公司报告了在软件包安装时运行的变更
- 如果您在 11 月 10 日以来发布过软件包，请检查已发布的版本是否含有恶意变更；如果有，请撤回并从干净状态重新发布
检查云端是否有在轮换后仍然存在的变更
A 公司列举的在密钥轮换后仍然存在的变更包括：改写 AWS 角色信任策略，以及添加 Azure 联合凭据（B 公司还提到遗留的 AWS 访问密钥）。请在审计日志和当前设置中检查这两个方面。
- AWS：新创建的访问密钥，以及角色信任策略的变更（信任是否扩大到了意料之外的账户或条件）
- Azure（Entra ID）：添加到应用上、指回某个仓库的联合凭据
另外，作为对利用被盗凭据提升权限的检查，也请查看 Google Cloud（异常的服务账号使用或令牌签发调用）以及 Vault 或 Kubernetes（不认识的 GitHub OIDC 登录）。
即使没有发现任何异常，也请检查您的 OIDC 信任条件是否已收窄到仓库、分支和环境（见下文“应检查什么”）。
盘点您的令牌和第三方应用
在 GitHub 设置中，列出以下内容，并移除不需要的或不认识的。
- 个人访问令牌：删除不用的；对其余的，限制仓库、权限和有效期
- 您授权的 OAuth 应用和 GitHub 应用，包括为托管或 CI 部署而连接的。对不再使用的，移除其授权
- SSH 密钥和部署密钥：移除不用的和没有所有者的密钥
- 机器人和自动化账户的权限：检查是否有可以绕过受保护分支规则的
据该云服务商的通知，该服务商的应用需要重新连接。如果您使用它，请按服务商的说明操作。
检查您自己的应用没有暴露版本控制文件夹
同一服务商解释说，部分通过 GitHub 部署的应用公开了整个构建目录，因此留在那里的令牌可能被获取。请检查您应用的公开 URL 是否提供了版本控制文件夹（.git）的内容。如果是，请将其从镜像中排除，重新部署，并轮换其中包含的所有凭据。也请检查您的部署平台是否使用类似的机制。
发生了什么（依据调查的各公司和相关服务商）
以下内容依据 A、B、C 三家安全公司的公开文章（均发布于 2026 年 11 月 12 日）以及一家云服务商的通知（11 月 12 日晚得知，11 月 13 日补充）。这些是各方和调查者自己的说法，尚未得到 GitHub 的确认。除非另有说明，时间均为 UTC。
11 月 10 日，约 12:45
据 A 公司称，攻击者开始用被盗令牌，在每个令牌有写入权限的仓库中行动。在每个仓库中，它先发送一个试探性拉取请求，然后做出恶意变更，约一分钟后将其还原，并删除运行记录和日志。B 公司也将第一次恶意变更记在 12:46。11 月 11 日，15:00
A 公司统计的 61,839 个试探性拉取请求的时间窗口结束。11 月 12 日，04:36
B 公司统计的 8,093 个有恶意变更的公开仓库的时间窗口结束。11 月 12 日，07:40
C 公司统计出超过 63,000 个试探性拉取请求的时间。A、B、C 三家公司当天发布了各自的文章。11 月 12 日，22:00（未说明时区）
一家云服务商发布通知，称其（11 月 12 日，未给出时间）得知，发给其 GitHub 应用的令牌被未经授权的一方用于客户的仓库（服务商的通知）。11 月 13 日，15:54
该服务商补充说，撤销所有用户令牌的操作中途停止，GitHub 正在调查（服务商的通知）。
有效的被盗令牌
用试探性拉取请求测试能否写入
↓→
恶意变更
收集 CI 密钥和云凭据并发送出去
↓→
掩盖痕迹
还原变更，删除运行记录和日志；设置可能仍留在云端
各来源的数字（请勿相加）
| 来源（角色） | 统计的内容 | 数字 | 备注 |
|---|---|---|---|
| A 公司（最先报告） | 发送试探性拉取请求的账户 / 收到的仓库 | 4,837 个账户 / 61,764 个仓库 | 约 92% 仍处于打开状态（分母是发往该账户并非所有者的仓库的 10,431 个拉取请求） |
| A 公司 | 恶意代码运行并发送出凭据的仓库 | 至少 1,835（别处为 1,806） | 文章中的两个数字；该公司称该数字可能是下限 |
| A 公司 | 可发布软件包的账户 | 至少 50 | 据了解，具有 npm、Go、PyPI、Packagist 和 crates 的发布权限 |
| B 公司 | 有恶意变更的公开仓库（11 月 10 日 12:46 至 11 月 12 日 04:36） | 8,093 | 不是代码运行的数量。明细合计为 8,096；差异未作说明 |
| B 公司 | 试探性拉取请求 | 61,879 个拉取请求 / 4,833 个账户 / 61,734 个仓库 | 不包含在 8,093 中 |
| C 公司 | 试探性拉取请求（截至 11 月 12 日 07:40） | 超过 63,000 | 约 90% 处于打开状态。其中 173 个（19 个账户）来自发给某云服务商 GitHub 应用的令牌 |
| 云服务商（自己的通知） | 在受影响客户账户中发现的试探性拉取请求 | 超过 250 | 称有少数客户受影响 |
B 公司写道，其数字来自 GitHub 搜索，只覆盖公开仓库的默认分支，因此真实总数可能更高。
- 被窃取的内容
- GitHub Actions 密钥和变量、工作流令牌、云凭据（AWS、Azure、Google Cloud），以及开发者和 AI 服务的凭据（A 公司）
- 原因（调查者的说法）
- 滥用有效的被盗令牌，而非 GitHub Actions 的缺陷（C 公司）。提交以真实用户的名义出现且未签名，这指向令牌被盗（B 公司的推断）
- 令牌是如何获取的
- 整个攻击活动尚未查明。对于通过该云服务商应用而来的部分，C 公司也称无法查明令牌是如何获取的，且没有该服务商基础设施被入侵的证据
- 云服务商的说法
- 其基础设施未遭入侵。在基于 GitHub 的部署中，令牌被留在构建目录的配置文件中，部分应用公开了整个目录，因此可被获取。少数客户受影响，已逐一联系。该服务商开始撤销发给该应用的所有用户令牌，并更改了部署流程。该服务商称，通过其命令行工具的部署、其 API 令牌以及运行中的应用不受影响
- 对软件包的影响
- B 公司检查了源仓库收到恶意变更的 218 个 npm、Go 和 Packagist 软件包。有 3 个软件包存在恶意版本（1 个 Packagist，2 个 Go），其清单中合计 5 个版本；未发现其他。PyPI 等未作检查。A 公司也认为攻击者的目标是 CI 密钥，软件包污染是自动发布带来的副作用
- 与 10 月另一次攻击活动的关系
- A 公司称，受 10 月攻击活动影响的账户在这次更可能被攻击，但判断为不同攻击者的不同行动。C 公司也称，重叠并不表明是同一攻击者（被盗令牌会被共享和出售）
- GitHub 官方声明
- 未说明（2026 年 11 月 14 日查看了博客、更新日志和状态历史）
已知与未知的事项
截至 2026 年 11 月 14 日的状态。有新消息时，我们会更新状态栏。
| 项目 | 已公布内容 | 状态 |
|---|---|---|
| 约 4,800 个账户被滥用 | 有效的被盗令牌被用来发送试探性拉取请求 | 已确认（A、B 公司） |
| 向 61,764 个仓库发送试探性拉取请求 | 与之后是否有变更是不同的数字 | 已确认（A 公司；B 公司统计为 61,734） |
| 有恶意变更的仓库 | 8,093 个公开仓库 | 已确认（B 公司；仅限公开仓库和默认分支） |
| 恶意代码运行并发送出凭据 | 至少 1,835 个仓库 | 已确认（A 公司；也给出 1,806） |
| 密钥和云凭据被窃 | 在代码运行的仓库中 | 已确认（A、B 公司） |
| 云端持久化（轮换后仍然存在的设置） | 改写 AWS 角色信任策略和添加 Azure 联合凭据（A 公司）；B 公司还提到遗留的 AWS 访问密钥 | 可能（A、B 公司） |
| 利用 GitHub Actions 的缺陷 | 未使用 | 未包含（C 公司） |
| 已发布软件包被污染 | 3 个软件包（1 个 Packagist，2 个 Go），合计 5 个版本（未发现其他） | 已确认（B 公司；PyPI 等未检查） |
| 云服务商基础设施被入侵 | 没有证据（C 公司）；该服务商否认遭入侵 | 未确认（C 公司、该服务商） |
| 令牌最初是如何被盗的 | 对云服务商应用令牌的一部分已有说明；整体不明 | 调查中 |
| 与 10 月另一次攻击活动的关联 | A 公司认为是不同的行动；C 公司不作断言 | 调查中 |
| GitHub 官方声明 | 未发现 | 未说明 |
| 经确认的受影响组织名单 | 未公布 | 未说明 |
如何解读：这些数字统计的是不同的东西，且在两天内有所变动
A 公司的 1,835 是对运行次数的估计，B 公司的 8,093 是有恶意变更的公开仓库，C 公司的 63,000 是试探性拉取请求。它们并不是同一回事。许多只收到试探性拉取请求的仓库，可能并没有变更或窃取。不过，据 A 公司称，发送过试探性拉取请求的账户，即使之后没有变更，也应视为已被攻陷。
使用有效的被盗令牌可能发生什么
以下是一般性说明，并不意味着这些情况在此发生了。调查的各公司报告实际发生的情况，见上文“发生了什么”。
如果令牌有效，攻击者就能以合法用户的身份写入。这里没有可利用的 GitHub 功能弱点，软件更新也无法阻止。如果有写入权限的账户可以修改 CI 工作流，那么该工作流能读取的密钥和云权限会一并成为目标。如果到云账户的 OIDC 信任设置得很宽松（任何分支或工作流都能进入），那么即使没有存储的密钥，也可以签发临时凭据。如果您的账户是另一个组织的协作者，损害会超出您自己拥有的范围。
应检查 CI 和云权限的哪些方面
本节不是对受影响各方的评估。依据调查者的报告，它以本站的看法为主，聚焦于您自己的环境中应检查的内容。
不要大范围或长期持有令牌
这次被利用的是有效的被盗令牌。将个人访问令牌限定于特定仓库和权限，设置较短的有效期，不再使用时删除（使用细粒度类型）。第三方应用只授权其所需的范围（本站的看法）。
收窄工作流权限和进入云端的条件
将工作流的默认权限设为只读，仅在需要时授予写入。将云端 OIDC 信任收窄到仓库、分支和环境，使并非所有工作流都能进入。为环境密钥设置审批人，意味着被改写的工作流无法直接读取生产环境密钥（本站的看法）。
用必需的评审来巩固分支保护
A 公司写道，该代码包含一种意图绕过分支保护的机制。不要只依赖检查名称：要求代码所有者的批准评审，并且不给机器人账户留例外（本站的看法）。
检测运行编号缺口和云配置变更
这次的情况是运行记录和日志被删除，编号缺口成为线索。保留组织的审计日志，并为工作流变更以及云端访问密钥创建、信任策略变更和新增身份联合设置告警。C 公司还建议将 CI 的出站流量限制在允许列表内。
不要把密钥放在仓库里
除了 CI 密钥，代码历史中的凭据也会随任何能读取它们的人的被盗令牌一同被带走。关于如何在提交前拦截，请参见用 gitleaks 在提交前拦截密钥；关于撤销的顺序，请参见GitHub 上暴露的 54 万条凭据仍然有效。
参考来源（公开记录）
本文中的事实来自以下公开信息。GitHub 对此没有官方声明（11 月 14 日查看）。攻击步骤的细节不在涵盖范围内。
- GitHub，《Changelog》和《Security》（官方博客和更新日志；没有关于此事的条目；11 月 14 日查看）— github.blog / github.blog
- GitHub Status（官方事件历史；没有关于此事的条目；11 月 14 日查看）— githubstatus.com
- 某云服务商的通知，《Security: GitHub tokens exposed by apps deployed from GitHub》（官方社区论坛；11 月 12 日得知，11 月 13 日补充；11 月 14 日查看）— community.fly.io
- A 公司（安全公司；最先报告），《wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories》（2026 年 11 月 12 日；11 月 14 日查看）— aikido.dev
- B 公司（安全公司），《wfx: GitHub Actions Credential Stealer Hits 8,000 Repos》（2026 年 11 月 12 日；11 月 14 日查看）— safedep.io
- C 公司（安全公司），《WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks》（2026 年 11 月 12 日；11 月 14 日查看）— stepsecurity.io
- 媒体：BleepingComputer，《Hackers compromise 4,800 GitHub accounts to steal cloud credentials》（11 月查看；对 A 公司文章的报道）— bleepingcomputer.com
更新记录
2026-11-14：首次发布。依据三家安全公司的公开文章（均为 11 月 12 日）和一家云服务商的通知。GitHub 没有官方声明。媒体报道有出入时，以各方的原始文章为一手来源。有更多信息发布时，我们将更新。
延伸阅读
- 因未撤销而仍然有效的已公开凭据：GitHub 上暴露的 54 万条凭据仍然有效
- 另一起以基于 GitHub 的开发为目标的案例：TanStack 和 Nx 供应链攻击
- 撤销的顺序与软件包带来的损害：防御 npm 供应链攻击
- 保护您的账户：GitHub 双重认证 / 环境变量与 API 密钥基础
- 使用合法凭据发生的事件：2026 年的入侵都是用合法凭据发生的
- 2026 年的其他事件：2026 年的数据泄露与网络攻击