wfx-loot 是一起针对持续集成（CI）环境的凭证窃取行动。攻击者利用被盗用的 GitHub 账号探测代码仓库；如果账号拥有写入权限，就可能把窃密代码引入 CI 流程。Aikido 报告称，4,837 个账号曾在 61,764 个仓库发起探测式拉取请求；其公布的统计显示，至少 1,835 个仓库运行了载荷并发生凭证外传。49

行动持续了多久？

活动约于 2026 年 11 月 10 日 12:45（UTC） 开始。一份报告将探测式拉取请求的时间窗口记至 11 月 11 日 15:00（UTC），前后约 26 小时 15 分钟。67 这是已观察到的探测窗口，并不代表所有载荷活动或被盗凭证的后续使用都在那一刻停止。

几个规模数字对应攻击的不同阶段，不能混为一谈：

• 4,837 个账号被报告为遭到入侵。
• 61,764 个仓库收到探测式拉取请求。这代表被测试的仓库数量，不等于已确认运行恶意代码的数量。
• Aikido 公布的统计显示，至少 1,835 个仓库运行了载荷，且发生凭证外传。9

部分同期报道引用了较低的 1,806 个统计数字。610 现有报道没有解释两者差异，因此应视为不同时间或口径下公布的统计，而非简单相加。现有材料也不足以证实后来出现的“超过 66,000 个目标、约 1,970 起已确认公开案例”这一说法。

先试权限，再把窃密代码放进 CI

攻击者从名为 wfx-docs 的分支发起拉取请求，标题为 docs: dependency audit notes。这类请求的作用是探测：被盗账号是否有权向目标仓库写入内容。349

在权限允许的情况下，攻击者会将窃取凭证的载荷引入 CI 环境。根据现有报告，行动利用的是有效的被盗凭证，而不是 GitHub Actions 本身的漏洞。49 OX Security 将恶意程序描述为一份约 1,500 行的 Shell 脚本。31

部分报告还提到，恶意改动和工作流日志在某些情况下会被删除，增加了后续调查难度。16 目前的证据支持“探测权限、投放载荷、清理痕迹”这一总体模式，但不能据此断言每一种被报道的部署方式或提交信息都出现在每次感染中。

载荷试图窃取什么？

已记录的目标包括 CI 任务能够读取的凭证，例如 GitHub Actions 密钥和云服务凭证；报道也提到攻击者试图获取 AI 服务令牌。39 OX Security 的分析列出 AWS、Azure 和 Google Cloud 的凭证。31 另有报道指出，恶意程序可能搜索运行器进程内存中的密钥；但现有摘录无法说明这种方式成功的频率。1729

一份汇总材料提到，载荷还试图通过修改 AWS 信任策略、向 Azure 添加联合凭证来延续访问。5 这些属于被报道的行为，并不能证明每个受影响仓库或云账号都遭到修改。现有证据聚焦于凭证窃取，并未证明攻击者窃取了源代码或客户数据库。915

如何理解其他告警信号

一份报告称，在通过协作者或组织权限发出的 10,431 个探测式拉取请求中，检查时仍有 92% 处于未关闭状态。1019 这说明当时有许多探测请求尚未得到处理，但不能据此断定仓库所有者或安全团队都没有发现它们。这个比例也不应被误读为适用于全部拉取请求。

一份调查手册还记录了 19 个账号通过 Fly.io GitHub App 使用令牌发出的 173 个探测式拉取请求。这一观察本身并不能证明 Fly.io 基础设施遭到入侵，也不能证明这些令牌触及的每个仓库都运行了载荷。37

防守方可以先做什么

如果组织可能受到影响，评估时应区分遭到探测、载荷被植入、载荷已运行、凭证已外传这几个阶段。它们不是同一件事。

• 搜索探测痕迹。 检查账号有权写入的仓库中，是否出现标题为 docs: dependency audit notes 的拉取请求，或名为 wfx-docs 的分支。9
• 核对 CI 与审计记录。 检查工作流运行记录、提交、分支活动及可用的云端日志。报道提到运行记录和日志可能被删除，因此工作流运行编号缺口可以作为调查线索；但单凭缺口不能证明已遭入侵。124
• 撤销可疑访问。 撤销疑似被盗用的 GitHub 令牌，并复查账号、协作者和 GitHub App 的访问权限。
• 全面轮换暴露的密钥。 如果载荷确已运行，应将该工作流能够访问的密钥和云角色都视为可能泄露，而不只是仍能在日志中看到的凭证。39
• 排查云端持久化。 检查是否存在异常的 AWS 信任策略变更、Azure 应用或联合凭证变更，以及未经授权的密钥或其他访问控制改动。5
• 先保留证据。 在清理之前保存仍可获取的审计记录和日志，并记录现有证据支持攻击链中的哪一个阶段。

wfx-loot 是一起针对持续集成（CI）环境的凭证窃取行动。攻击者利用被盗用的 GitHub 账号探测代码仓库；如果账号拥有写入权限，就可能把窃密代码引入 CI 流程。Aikido 报告称，4,837 个账号曾在 61,764 个仓库发起探测式拉取请求；其公布的统计显示，至少 1,835 个仓库运行了载荷并发生凭证外传。49

行动持续了多久？

活动约于 2026 年 11 月 10 日 12:45（UTC） 开始。一份报告将探测式拉取请求的时间窗口记至 11 月 11 日 15:00（UTC），前后约 26 小时 15 分钟。67 这是已观察到的探测窗口，并不代表所有载荷活动或被盗凭证的后续使用都在那一刻停止。

几个规模数字对应攻击的不同阶段，不能混为一谈：

• 4,837 个账号被报告为遭到入侵。
• 61,764 个仓库收到探测式拉取请求。这代表被测试的仓库数量，不等于已确认运行恶意代码的数量。
• Aikido 公布的统计显示，至少 1,835 个仓库运行了载荷，且发生凭证外传。9

部分同期报道引用了较低的 1,806 个统计数字。610 现有报道没有解释两者差异，因此应视为不同时间或口径下公布的统计，而非简单相加。现有材料也不足以证实后来出现的“超过 66,000 个目标、约 1,970 起已确认公开案例”这一说法。

先试权限，再把窃密代码放进 CI

攻击者从名为 wfx-docs 的分支发起拉取请求，标题为 docs: dependency audit notes。这类请求的作用是探测：被盗账号是否有权向目标仓库写入内容。349

在权限允许的情况下，攻击者会将窃取凭证的载荷引入 CI 环境。根据现有报告，行动利用的是有效的被盗凭证，而不是 GitHub Actions 本身的漏洞。49 OX Security 将恶意程序描述为一份约 1,500 行的 Shell 脚本。31

部分报告还提到，恶意改动和工作流日志在某些情况下会被删除，增加了后续调查难度。16 目前的证据支持“探测权限、投放载荷、清理痕迹”这一总体模式，但不能据此断言每一种被报道的部署方式或提交信息都出现在每次感染中。

载荷试图窃取什么？

已记录的目标包括 CI 任务能够读取的凭证，例如 GitHub Actions 密钥和云服务凭证；报道也提到攻击者试图获取 AI 服务令牌。39 OX Security 的分析列出 AWS、Azure 和 Google Cloud 的凭证。31 另有报道指出，恶意程序可能搜索运行器进程内存中的密钥；但现有摘录无法说明这种方式成功的频率。1729

一份汇总材料提到，载荷还试图通过修改 AWS 信任策略、向 Azure 添加联合凭证来延续访问。5 这些属于被报道的行为，并不能证明每个受影响仓库或云账号都遭到修改。现有证据聚焦于凭证窃取，并未证明攻击者窃取了源代码或客户数据库。915

如何理解其他告警信号

一份报告称，在通过协作者或组织权限发出的 10,431 个探测式拉取请求中，检查时仍有 92% 处于未关闭状态。1019 这说明当时有许多探测请求尚未得到处理，但不能据此断定仓库所有者或安全团队都没有发现它们。这个比例也不应被误读为适用于全部拉取请求。

一份调查手册还记录了 19 个账号通过 Fly.io GitHub App 使用令牌发出的 173 个探测式拉取请求。这一观察本身并不能证明 Fly.io 基础设施遭到入侵，也不能证明这些令牌触及的每个仓库都运行了载荷。37

防守方可以先做什么

如果组织可能受到影响，评估时应区分遭到探测、载荷被植入、载荷已运行、凭证已外传这几个阶段。它们不是同一件事。

• 搜索探测痕迹。 检查账号有权写入的仓库中，是否出现标题为 docs: dependency audit notes 的拉取请求，或名为 wfx-docs 的分支。9
• 核对 CI 与审计记录。 检查工作流运行记录、提交、分支活动及可用的云端日志。报道提到运行记录和日志可能被删除，因此工作流运行编号缺口可以作为调查线索；但单凭缺口不能证明已遭入侵。124
• 撤销可疑访问。 撤销疑似被盗用的 GitHub 令牌，并复查账号、协作者和 GitHub App 的访问权限。
• 全面轮换暴露的密钥。 如果载荷确已运行，应将该工作流能够访问的密钥和云角色都视为可能泄露，而不只是仍能在日志中看到的凭证。39
• 排查云端持久化。 检查是否存在异常的 AWS 信任策略变更、Azure 应用或联合凭证变更，以及未经授权的密钥或其他访问控制改动。5
• 先保留证据。 在清理之前保存仍可获取的审计记录和日志，并记录现有证据支持攻击链中的哪一个阶段。