2026-10-24 11:54:08 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

警惕！1900个开发者账号被黑，开源投毒这次瞄准了你的 AI Key 和云密钥

原创

Kit Chung
Kit Chung

安全圈动向

2026年10月19日 07:59
广东

去阅读

平时写代码，大家最怕什么？不是改不完的 Bug，而是你以为安稳躺在后台的自动化流水线，悄悄成了黑客的“提款机”。

最近安全圈出了个大事件，GitHub 上一个名为 GhostAction（幽灵行动） 的供应链攻击突然发起猛烈反扑。短短48小时内，黑客黑掉了近 1,900 个开发者账号，把毒手伸向了超过 3,000 个组织与用户 下的 30,000 多个代码仓库，试图搜刮走 3,174 个 CI/CD 核心敏感凭证。

更离谱的是，黑客专门盯上了大家最近配进环境里的 AI 服务 API Key、各大云厂商 AccessKey，以及 npm/PyPI 的发布 Token。

今天我们聊的，就以一个一线开发兼安全爱好者的视角，带大家像做代码审查一样，把黑客这套攻击链路、恶意 Workflow 注入逻辑以及 Payload 的迭代版本彻底扒开看看。

一、怎么中招的？“合法账号”投毒比漏洞更难防

很多朋友可能会问：“我开了两步验证，仓库也没给外人权限，怎么就被黑了？”

GhostAction 最阴险的地方在于：它不走常规的代码漏洞利用，而是直接走身份凭证盗用。

攻击链路非常清晰且致命：

账号凭证收割

黑客先从暗网的 Infostealer 盗号木马日志、历史泄露数据库中提取开发者的 GitHub 账密，或者直接利用开发者本地泄漏的 个人访问令牌。
2. 伪装合法提交

拿到拥有写权限的账号后，黑客没有立刻删库改代码搞破坏，而是悄悄在仓库的 .github/workflows/ 目录下新增一个自动化工作流文件。
3. “钓鱼”命名伪装

文件名字起得极其具有讽刺意味，比如叫 security-audit.yml（安全审计）或者 github_actions_security.yml（GitHub Actions安全加固）。很多维护者扫一眼 PR 或提交记录，还以为是哪个队友给项目配的安全基线检查。

只要这个工作流被合并或直接推送到默认分支，GitHub Actions 引擎就会在微软云端的 Runner 上自动启动——潘多拉魔盒就此打开。

二、核心技术拆解：黑客的恶意 Workflow 怎么偷家？

普通黑客偷 Secrets，顶多在 CI 运行时打个 echo $SECRET | base64 往自己的外网服务器发请求。但这次 GhostAction 的武器库明显经过了针对性迭代，甚至演进出了三个不同的 Payload 版本。

1. 初代演进：引入全量 Git 历史正则扫描

以往大部分人认为：“只要我不在当前代码里明文写 Key 就没事，Git 历史记录里老提交即便忘了删，只要没人特意去翻也安全。”

黑客这次给 Payload 加了 Git History Secret-Scanning（历史敏感信息提取） 模块。当恶意 Workflow 启动时，Runner 首先拉取包含全量 Commit 历史的代码库，随后调用一组极其严密的正则匹配引擎：

云厂商凭证

AWS Key ID、GCP、阿里云等云凭据。
* 代码平台 Token

GitHub PAT、GitLab Access Token。
* 高价值发布权限

npm、PyPI、DockerHub 仓库推送令牌。
* AI API Key

OpenAI、Anthropic 等大模型接口密钥。

2. 二代迭代：解决“有 ID 无 Secret”的技术难点

搞过 AWS 的同学都知道，光抓到一个 AKIA... 开头的 Access Key ID 是没法调 API 的，必须配对对应的 Secret Access Key。

黑客在第二版 Payload 里引入了上下文抓取逻辑：

当正则在某次历史提交或配置文件中命中 AWS Access Key ID 时，脚本不会只存下那串字符，而是会向上、向下自动抓取两行上下文内容。

利用简单的文本跨行解析，把成对出现的 Key ID 和 Secret 一并打包。

3. 终极形态：全局上下文深挖与批量回传

到了第三个变体，攻击者已经将整套“正则匹配 + 多行上下文抓取”的逻辑完全自动化集成。Workflow 在几秒钟内完成敏感词提取、上下文拼装、内存编码压缩，并通过 HTTPS POST 请求加密打包回传至黑客的 C2 服务器。

更夸张的是黑客的自动化脚本推进节奏：

8号先拿以往标记过的 160 个存量受害账号进行“灰度测试”；
验证回传链路通畅后，仅隔了 20分钟，瞬间把恶意工作流并发推向 28,000 多个新仓库。

三、为什么旧账号会反复被“轮流收割”？

报告里有个细节特别值得所有人警惕：在10月份这波大规模爆发中，相当一部分受害仓库其实早在2025年9月或2026年8月就已经中过招。

为什么会反复掉进同一条河流？

这就是很多团队的通病——治标不治本。上次被黑之后，大家可能只是顺手把那份恶意的 .yml 删掉了事，甚至连 GitHub 账号的密码都没改，更别提去重新轮换那些可能早就泄露的 PAT、AWS 密钥和发版 Token。黑客甚至不用换手段，拿着一年前拿到的过期凭证池重新撞一遍，依然能轻松撞开大门。

技术痛点在于

自动化 CI/CD 环境赋予了代码极高的执行特权，但绝大多数开发团队的安全策略依然停留在“代码没有 SQL 注入就行”，对运行环境凭据的生命周期管理完全处于裸奔状态。

四、作为开发者，我们该如何加固自己的防线？

虽然 GitHub 官方在10月9日紧急出手，在平台层拦截了这批恶意 Workflow 的调度执行，直接废掉了后续几波攻击，但这种攻防对抗是永无止境的。明天黑客换个混淆壳，这套攻击依然能跑起来。

建议大家今天下班前，花 20 分钟做这几件事：

排查并收紧 Actions 默认权限

进入仓库设置：Settings -> Actions -> General -> Workflow permissions。默认权限千万别给 Read and write permissions，务必改成 Read repository contents permission（只读）。需要写权限的 Job，单独在 YAML 里用 permissions 字段显式声明最小权限。
2. 立即清理与轮换过期的 PAT

检查自己的 GitHub Personal Access Tokens，能用 Fine-grained PATs（细粒度令牌） 就坚决不用 Classic PAT。设置硬性的过期时间（比如 30 天或 90 天），并坚决清理掉历史未使用的废弃 Token。
3. 引入防外泄与历史清理工具

在本地使用 git-secrets 或 trufflehog 作为 pre-commit hook，防止误将私钥提交入库。如果代码历史里曾不小心提交过密钥，不要仅仅做一个新的 Commit 覆盖掉，必须使用 git-filter-repo 或 BFG Repo-Cleaner 从历史树中彻底抹除，并在云端控制台立即废弃原密钥。
4. CI/CD 环境隔离与密钥使用范围限制

在 GitHub Actions 中，非必要不要将生产环境的 Secrets 挂载到 Public 仓库的 PR 触发环境里（善用 GitHub Environments 的保护规则）。

供应链安全的本质，是把安全防御从“信任账号”转变为“零信任环境”。别让流水线里的自动化工具，成了黑客手里最顺手的开锁器。