GhostAction：把恶意工作流推进数万个仓库

攻击者不需要攻破你的 CI，他们只需要用一个可信账号往里推一个文件。这就是 GhostAction 的手法。

攻击是怎么走的

StepSecurity 的复盘给了两个具体案例：

首先是游戏引擎 pyxel 的作者 Takashi Kitao（项目在 GitHub 上有 1.84 万星标）账号被攻陷。从 13:20 UTC 开始，攻击者用它向 27 个仓库推送恶意工作流。
8 小时后，Uber 开源项目 athenadriver 的原作者 Henry Wu（账号 henrywoo）账号被攻陷。在 21:10 到 21:26 的 16 分钟窗口内，用该账号向 318 个仓库推送了同款工作流。

到 2026 年 10 月 9 日，安全厂商 Socket 的监测显示：自 10 月 7 日进入扩散期以来，已有超过 500 个 GitHub 账号向数万个仓库提交了这份恶意工作流。

这也不是新活动。GhostAction 最早在 2025 年 9 月曝光，当时波及 327 名用户名下的 817 个仓库，窃取 3325 组凭证。

工作流长什么样

两个被攻陷账号推送的文件，分别叫：

security-audit.yml，工作流名 Security Audit
github_actions_security.yml，工作流名 GitHub Actions Security

名字本身就是伪装——安全审计，听起来像是你会主动去点开的东西。

触发条件是 workflow_dispatch，以及没有任何过滤的 push（任意分支、任意标签）。一旦运行，它会以 fetch-depth: 0 拉取全量代码，然后跑一个叫 Audit 的步骤，做四件事：

追加侦察阶段发现的仓库命名密钥；
扫描工作目录，匹配 13 类凭证特征；
扫描整个 git 历史，用同样的特征找那些被删掉但还留在历史里的凭证；
自动把 AWS 访问密钥 ID 和对应的秘密密钥配对，凑成一组能直接用的凭证。

外传走的是明文 HTTP，目标 IP 是 193.32.204.199。

为什么 git 历史是关键

第 3 步是整条链里最值钱的一步。

大多数人删密钥的方式是「提交一个新版本把它去掉」。但对 git 来说，旧版本还在。攻击者只要扫历史，就能拿到你以为早就清理干净的东西。

「已经删了」和「已经不存在了」在 git 里不是一回事。

GitGuardian 在同期发布的一份报告里给出了更宽的统计：2026 年 8 月 31 日到 9 月 30 日，GhostAction 向 373 名用户与组织名下的 772 个公共仓库推送了同款工作流，瞄准 2577 组凭证，包括 SSH 私钥、Azure 凭证、容器镜像仓库凭证、数据库凭证、FTP、Google Cloud 与 Firebase、GitHub 令牌，以及 Telegram、Slack、Discord 的机器人令牌。

扩散路径：fork

Socket 提到一个容易被忽略的细节：henrywoo 账号命名空间下的 279 个 fork 都带着这份工作流。

这意味着感染面不止原始仓库。如果 fork 开了 Actions，后续任何一次 push 都会触发凭证窃取。私有 fork 和下游镜像的风险最高，因为私有仓库里往往放着真正有效的凭证。

现在该做什么

如果这段时间你的仓库被推过东西，排查顺序建议是：

在 2026 年 8 月 31 日之后的提交里，找 security-audit.yml 与 github_actions_security.yml 这两个文件名；
找到即判定失陷，立刻吊销 GitHub 凭证、轮换所有相关密钥；
从所有分支删除恶意工作流，不只是默认分支；
检查受感染仓库的所有 fork。

第 3 条容易被漏掉：只清默认分支，其他分支上的工作流还在。

我的判断

这件事的核心不是 GitHub Actions 不安全，而是**「账号」和「仓库」之间的信任关系太宽了**。

一个账号被拿下，它能推送到它有权访问的所有仓库；而工作流一旦落地，就拥有了该仓库的全部密钥与整个 git 历史。攻击者真正需要攻破的东西只有一个：一个 PAT。

所以真正有效的降低面不是「更仔细地看 YAML」，而是把发布权限拆细——工作流用最小权限的令牌、生产密钥不进仓库命名密钥、以及给默认分支加写保护。这些都不新，只是又一次证明它们值得做。