2026-10-15 15:42:13 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

仓库里多出一份安全检查工作流，它专门偷密钥

原创

tcode
tcode

字节脉搏实验室

2026年10月13日 11:12
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

十月八日，两个账号在半小时里改了三百多个仓库

先看时间。按协调世界时记录，十月八日那天有两波操作。第一波从十三点二十分开始，十三点四十四分结束，二十七个仓库被写入同一个文件，提交者是一位开源维护者的账号，他是一套开源游戏引擎的作者。八个小时之后是第二波，从二十一点十分到二十一点二十六分，只有十六分钟，三百一十八个仓库被写入，动手的是另一个账号，它属于某大公司一个数据库驱动的原作者。

两波合计三百四十六个仓库。其中三百一十八个来自第二个账号：三十九个是它名下的源码仓库，二百七十九个是这些仓库的复刻。名单里还有那家公司自己的仓库，它恰好是第二波最后落笔的一个。

被写进去的文件叫 security-audit.yml，提交说明写着“添加安全审计工作流”。举个现场：假设你打开自己仓库的提交列表，最新一条不是你写的，文件名是 security-audit.yml、说明写着“添加安全审计工作流”——先把它当成一次入侵，而不是一次同事改动。这个文件落在约定俗成会自动执行的目录下，触发条件有两个：手工触发，以及对任何分支、任何标签的推送都不加过滤。只要文件进了仓库，你下一次随手推一次代码，它就会自己跑起来。

还有一个细节值得留意：这三百多个仓库里，不少是多年没动过的休眠项目，甚至有早已无人维护的复刻。攻击者没有挑选，他是在自己能写的范围内一个不落地全推了一遍——这种节奏不像是挑目标，更像是枚举。

为什么一个文件就够了

不熟悉这套机制的人会问：光加一个文件，凭什么就能拿到东西？

因为在主流的代码托管平台上，工作流文件本身就是一段会被服务器执行的程序。它可以引用仓库里已经配置好的密钥，可以读取代码，可以调用网络。开发团队平时用它做自动测试、自动发布，攻击者看上的正是同一套能力——他不需要骗你去安装什么，只需要往这个目录里放一份读起来像“安全改进”的文件。

这也解释了这个文件为什么叫那个名字。安全审计、安全检查，是团队最不会质疑的一类改动；而它引用的密钥名字又是从你仓库里真实抄出来的，评审时看起来格外合理。

对防守方来说，排查的关键不在有没有漏洞，而在谁在什么时候动了默认分支。

它偷的东西，比上一轮多了一类

这类活动不是新面孔。早在二〇二五年九月，同样的手法就被记录过一次：那一次波及八百一十七个仓库、三百二十七名开发者，泄露三千多个密钥。到二〇二六年十月九日，追踪它的安全公司表示，自十月七日起已有五百多个账号把同一份工作流提交进数万个仓库。

这一轮真正变的是“偷什么”。上一轮只盯着仓库里配置好的流水线密钥——那类密钥通常以统一的写法被引用，扫描起来很方便。这一轮保留了这一项，同时增加了一次正则扫描，把工作区里、以及完整提交历史里所有长得像云服务、人工智能服务凭据的字符串一并捞出来：以 AKIA 这类前缀开头的访问密钥、各类云服务的令牌，都在它的名单里。

这句话的含义很直接：密钥删掉不等于不存在。只要它曾被提交过一次，历史记录里就还留着；而攻击者这次专门带上了翻历史记录的工具。很多人清理密钥的习惯，是删掉配置文件里那一行，这恰好漏掉了最要紧的一层。

一串密钥是怎么离开仓库的

整个过程可以拆成四步。

第一步是拿到一个维护者账号。公开分析给出的判断是，最可能来自被信息窃取型恶意软件或凭据泄露事件流出的个人访问令牌。也就是说，攻击者不需要猜密码，只需要拿到一串别人早已签发、却还生效的令牌。

第二步是踩点。脚本先扫一遍仓库里引用密钥的写法，把具体的密钥名字抄下来，再把这些名字套进载荷模板。所以推送出去的工作流读起来很“专业”——引用的正是你仓库里真实存在的那些名字。

第三步是注入。攻击者用维护者本人的身份，直接把文件提交到默认分支，绕过了代码评审。提交记录里的作者和提交者，写的都是受害者的名字和邮箱。

第四步是外发。工作流用一个常见的命令行工具，把收集到的内容以一个简短的网络请求发到一个固定地址，全程走明文。有仓库的运行日志显示，工作流启动四秒之后，攻击者的服务器就确认收到了。

值得记一笔的是速度：第二波那三百一十八个仓库从第一个到最后一个只用了十六分钟，手工操作不可能有这个节奏，自动化脚本才是合理解释；同样的脚本随时可以再跑一遍。

还有一点必须说清楚：这个工作流每次执行都会回连一次，哪怕它什么都没找到。所以“跑过但没报警”，不能当成安全的证据。到目前为止，追踪方表示还没有观察到因此发布出去的恶意软件包版本；但已经到手的云凭据和软件包仓库令牌，足以开通这条路。

现在就能做的三步自查

如果你在维护代码仓库，下面三件事今天就能做完。

第一件，搜文件。在代码托管平台上按组织范围搜索，看有没有仓库里存在文件名类似于安全检查、安全审计的工作流，记录它是什么时候出现、是不是直接进了默认分支。这一轮使用的文件名与三个可检索的标记，本文整理在文末来源记录里，可以直接粘贴进搜索框。

第二件，翻提交。在审计日志里找两类动作：由维护者身份直接把文件提交到默认分支、绕过评审的；以及在几分钟之内跨多个仓库连续提交、并且提交没有签名的。正常开发很少出现这种节奏，这类批量提交本身就是很强的信号。

第三件，换密钥。把受影响的仓库当作已经失守来对待：所有配置在流水线里的密钥，以及历史记录里出现过的云服务和人工智能服务凭据，全部轮换一遍，并检查这些凭据对应的账号在事发时段有没有异常调用。追踪方给出的建议很直白——只要那个文件在你维护的仓库里出现过，就按已经被窃取处理。

三步里最容易被漏掉的是第二步：很多团队只看仓库里现在有什么文件，不去翻审计日志里已经发生过的动作。

一个可以直接转述给同事的判断是：如果你们的仓库最近出现过一份谁都不记得添加过的安全检查工作流，先按已经被窃取处理，再去核对日志，顺序不要反过来。

证据边界

上述事实来自三处公开材料：追踪这家活动的一线安全公司十月九日发布的分析与配套检索指引；另一家代码安全公司同日发布的独立分析；以及一份更早的二〇二五年九月报告，那是这类手法第一次被系统披露。两家公司对同一波次的仓库计数略有差异，本文按给出逐仓库明细的一方为准，并在需要时说明区间。被控制的账号归属已由两家公司分别核对，但攻击者身份没有任何一方确认，本文不作推断。所有地址、文件名与检索标记均为防守用途，具体清单整理在文末来源记录里；本文不复现任何可直接利用的攻击代码。

来源

StepSecurity：《GhostAction Returns》；发布时间：2026-10-09；时区：协调世界时（UTC）；https://www.stepsecurity.io/blog/ghostaction-returns；含两波注入的 UTC 时间戳与逐仓库计数（27 / 318）、四个检测查询、三个检索标记（AKIA\_CTX\_START、c=monami、193.32.204.199），以及外发地址路径 :3000/api/workflow/receive；其运行日志显示工作流启动 4 秒后攻击者服务器确认收到
Socket：《New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials》；发布时间：2026-10-09；时区：协调世界时（UTC）；https://socket.dev/blog/ghostaction-cloud-credentials；计 346 个仓库（318 = 39 源码库 + 279 复刻，27 来自另一账号，另加那家大公司的仓库）；并给出自 2026-10-07 起 500 多个账号、数万个仓库的更新说明。该页同时说明“截至报道时未见因此发布到 PyPI 或 crates.io 的恶意包版本”
StepSecurity：《GhostAction Campaign: Over 3,000 Secrets Stolen Through Malicious GitHub Workflows》；发布时间：2025-09；时区：协调世界时（UTC）；https://www.stepsecurity.io/blog/ghostaction-campaign-over-3-000-secrets-stolen-through-malicious-github-workflows；首轮活动的 817 个仓库、327 名开发者、超过三千个密钥的口径来源