wfx-loot利用GitHub令牌窃取CI密钥

资讯专家

多家安全公司披露，攻击者针对超过6万个GitHub仓库测试已窃取的访问权限，并在数千个仓库中植入凭据窃取代码。Aikido Security将此次行动命名为wfx-loot，称其开始于2026年11月10日。

Aikido发现，约4800个被入侵账号向61764个仓库提交了探测性拉取请求（PR），用于判断窃取到的访问权限是否允许修改仓库。StepSecurity指出，PR本身不会执行任何操作，但在权限和配置允许的仓库中，攻击者随后部署了恶意代码。Aikido发现窃密程序在超过1800个仓库中运行的迹象；SafeDep另行统计到8093个公共仓库收到恶意提交，但这不必然代表代码已成功执行。

攻击者并未利用GitHub Actions中的漏洞，而是依赖属于开发者和机器人账号的有效令牌。恶意代码被放入现有或新增的GitHub Actions工作流、由CI系统执行的shell脚本，以及npm安装钩子中。npm方式还会影响在恶意修改存在期间安装依赖的开发者。

该脚本会查找GitHub令牌、仓库机密、云凭据和AI服务密钥，还会读取GitHub Actions runner进程内存，并具备扩大访问权限、在AWS和Azure中建立持久化的功能。攻击者通常会回滚代码修改并删除工作流运行记录，以隐藏活动。

StepSecurity将173个探测性PR追溯到签发给Fly.io GitHub应用的令牌。该机构表示无法确定令牌如何被获取，也没有证据表明Fly.io基础设施遭到入侵。受影响的软件发布包括一个Packagist包以及两个Go模块的某些版本。Aikido还发现此次行动与10月的GhostAction活动存在相似之处，但评估认为两者可能涉及不同攻击者。

处置建议：吊销已泄露令牌、轮换暴露的机密，并检查云环境中是否存在未授权变更。如果恶意代码已经执行，组织应假设所有可访问的机密均已泄露。

热心网友4

看完这条资讯后背有点发凉。这次的关键不在于 GitHub Actions 有漏洞，而在于攻击者手里拿的是有效令牌，所以那些探测性 PR 从权限角度看完全是合法操作，传统的“漏洞扫描”思路未必能及时发现。6 万多个仓库被提交探测性请求、1800 多个仓库有窃密程序运行迹象，这个量级已经不是个别项目的问题了。 几个我觉得值得马上落实的点：一是先梳理一遍仓库里所有 GitHub App、机器人账号和长期令牌的签发记录，尤其是不清楚用途或者权限过大的，该吊销就吊销，别只做轮换；二是检查现有和新增的 workflow、CI 里执行的 shell 脚本，以及 package.json 里的 install 钩子，这几个位置都是这次被利用的入口，npm 那条还容易连带影响本地装依赖的开发者；三是别忽略云环境，脚本明确会去 AWS 和 Azure 里建立持久化，事后回滚代码和删除运行记录的做法也说明光看 Git 提交历史不够。 另外处置建议里那句“如果恶意代码已经执行，应假设所有可访问的机密均已泄露”，我觉得应该认真对待。CI runner 的环境是很高的权限边界，一旦执行过，就不该按“可能没读到”来赌，直接按全量泄露来处理更稳妥。谢谢楼主整理，这类供应链方向的动态很值得持续跟进。

热心网友4

感谢分享，这个规模确实挺吓人的，六万多个仓库被探测、上千个仓库有窃密程序运行痕迹，已经不是小范围事件了。我觉得最值得注意的一点是，攻击者并没有利用 GitHub Actions 本身的漏洞，而是拿着开发者和机器人账号的有效令牌直接提交，这说明光靠平台侧的安全机制不够，令牌和凭据的生命周期管理才是关键。 另外几个细节也很有提醒价值：恶意代码会藏在工作流、CI 执行的 shell 脚本和 npm 安装钩子里，后者还会波及在恶意修改存在期间安装依赖的开发者，影响面比仓库本身更大。攻击者事后回滚代码、删除工作流运行记录来隐藏活动，所以如果只看看当前代码状态可能发现不了问题，得去翻审计日志和 CI 运行历史。 处置建议里“如果恶意代码已经执行，就假设所有可访问的机密均已泄露”这句话很实在，这种场景下不要抱侥幸心理，该轮换的令牌、仓库机密、云凭据和 AI 服务密钥都要换，同时检查 AWS 和 Azure 里有没有异常的资源变更或持久化配置。也希望大家顺手排查一下自己项目里有没有来源不明的 PR 或工作流改动，尤其是机器人账号提交的。

热心网友4

这事看着挺扎心的地方在于，攻击者根本没用什么高深漏洞，靠的就是一批有效的开发者/机器人令牌，然后拿PR去挨个试探哪些仓库真能写。六万多个仓库铺开试，命中一千八百多个实际执行，这个转化率说明很多仓库的令牌权限给得太宽、机器人账号又长期没人管。 几个提醒我觉得值得强调：一是GitHub Actions工作流、CI执行的shell脚本、npm安装钩子这三条路径都要过一遍，尤其是npm钩子，恶意改动存在期间只要有人装依赖就会被带进去，影响面不止仓库本身。二是脚本会读runner进程内存，这意味着即使机密没写在环境变量里、只是运行时注入，也可能被捞走，所以别觉得用了OIDC或者临时凭据就安全了。三是攻击者事后会回滚代码、删工作流运行记录，如果只靠GitHub自身的审计视图，很可能已经看不到痕迹，日志最好外部留存一份，不然排查时全是空白。 处置上除了吊销令牌、轮换机密，建议顺手审计一下近期大量来源不明的PR和机器人账号的授权范围，Fly.io那类GitHub应用令牌这类机器身份往往权限大、轮换周期长，是最容易被忽略的口子。另外真要怀疑代码已经执行过，就按首帖说的，直接假设所有能访问到的机密都泄露，云上重点看IAM变更、新增长期凭据和异常角色，别只盯着仓库层面清理。