新一轮GhostAction供应链攻击已攻陷772个公共GitHub仓库。攻击者通过伪造GitHub Actions工作流文件，窃取CI/CD环境中的各类凭证。
本次攻击活动时间为2026年8月31日至9月30日，共针对373名GitHub用户及组织名下的2577个敏感凭证。这些凭证包括云密钥、SSH凭证、容器注册表登录信息、数据库密码和GitHub令牌。
GitGuardian调查显示，攻击者利用窃取的GitHub账号访问权限，以受害者自身身份向仓库添加恶意工作流。
这些恶意文件伪装成常规自动化更新，快速代码审查过程中很容易被忽略。大多数情况下，攻击者会添加名为github_actions_security.yml的工作流，提交信息标注为Add Github Actions Security workflow。
该工作流会等待仓库正常推送事件触发，读取指定的GitHub Actions敏感凭证，再通过curl POST请求将数据发送到攻击者控制的基础设施。
这种手法与此前伪造CI更新窃取凭证的活动类似。当时攻击者就是利用看似常规的工作流变更，获取访问令牌和云服务凭证。
Cynative研究人员率先发现可疑提交并同步给GitGuardian，后者的分析师随后识别出这轮最新的GhostAction活动。
GitGuardian在2025年9月首次披露GhostAction攻击。当时该活动攻陷817个公共仓库，窃取至少3325个敏感凭证。
最新调查结果显示，这并非一次性短期活动。此前攻击波次植入的恶意工作流仍残留在部分仓库中，后续还被攻击者更新，替换为新的数据窃取端点。
Part01
恶意工作流精准匹配凭证
GhostAction不会收集工作流运行器可访问的所有变量。相反，恶意工作流会先检查仓库现有工作流和配置历史，寻找格式为${{ secrets.NAME }}的凭证引用，再将这些精准匹配到的凭证名称写入植入的恶意工作流中。这种方式让恶意文件的窃取目标更明确，专门收集可用于部署、发布、云管理或源代码访问的高价值凭证。
最新的攻击payload通过明文HTTP向193.32.204.199发送数据，替换了GhostAction此前使用的基础设施。研究人员还在7个仓库中发现一个小型攻击变种，该变种使用名为security-check.yml的工作流，对外显示名称为“Security Check”，提交信息标注为Add security check workflow。该变种会将数据发送到带有唯一注入标识符的API端点，说明攻击者可能按仓库或工作流实例，对窃取的凭证进行分类追踪。
这种通过隐藏工作流实现持久化的手法，与Shai-Hulud npm供应链攻击一致。后者同样通过注入GitHub Actions文件，在初始入侵后持续收集敏感凭证。
GitGuardian记录到这轮攻击共有三次集中爆发：8月31日攻陷143个仓库；9月2日至5日攻陷约400个仓库，仅9月5日当天就有294个仓库中招；9月15日攻陷103个仓库。研究人员共核查了605个仓库中的3669次工作流运行记录，发现GitHub拦截了大部分运行请求，要求等待人工审批。即便如此，仍有32个仓库中的499次工作流实际运行，其中336次成功执行，攻击者窃取了13个仓库中的26个敏感凭证。
攻击者最常针对SSH私钥和部署服务器凭证，相关凭证引用共446条；针对Azure凭证的攻击共218次，针对Docker Hub和GitHub容器注册表凭证的攻击有142次。恶意工作流还会窃取数据库密码、AWS访问密钥、FTP凭证、Google Cloud与Firebase凭证、GitHub令牌，以及Cloudflare、npm、PyPI、Slack、Telegram、Discord和各类AI平台的API令牌。
这一趋势反映出开发者可信工具被滥用的风险不断上升，攻击者正将开发者系统和构建流水线作为入侵云服务、访问源代码的核心入口。
Part02
GhostAction攻击从未完全停止
最能证明该攻击具备长期持久性的证据是，在92起案例中，攻击者并未创建新的工作流，而是直接更新此前已植入的恶意文件，提交信息标注为Update Github Actions Security workflow。这些恶意文件是此前攻击波次的残留，攻击者修改了文件配置，将数据发送到新的收集服务器。研究人员发现，相同的工作流模式曾关联多个旧端点，包括bold-dhawan.45-139-104-115.plesk.page、carte-avantage.com、170.39.218.2，以及*.oast.fun格式的Interactsh域名。
截至10月5日，772个受影响仓库中仅124个（占比16%）在公共提交历史中彻底清除了恶意文件。这意味着只要开发者推送一次合法提交，残留的恶意工作流就可能再次运行。
因此企业不能仅将删除恶意工作流作为全部响应措施，需要先查明攻击者获取仓库写入权限的路径，吊销受影响的GitHub凭证。同时还要核查工作流运行记录和审计日志，轮换工作流运行器可访问的所有敏感凭证。
GitHub建议团队为每个工作流和GITHUB_TOKEN配置最小必要权限，审计工作流源代码和第三方Actions，将Actions固定到完整的提交SHA值以获得不可篡改的版本引用。企业还应对敏感部署凭证启用环境审批控制，仔细核查.github/workflows/目录下所有新增或修改的文件。GitHub的安全使用指南明确指出，只要凭证发生泄露，即使日志中对其做了掩码处理，也必须完成轮换。
GitGuardian还在kuafuai/DevOpsGPT仓库中发现了挖矿程序，该仓库后续也遭到GhostAction攻击，不过研究人员并未将这两起事件归因于同一攻击者。该挖矿程序使用伪造的作者邮箱、定制化payload，将XMRig二进制文件伪装为/usr/local/bin/pyworker，运营风格与GhostAction完全不同，后者依赖大规模自动化的GitHub API工作流注入。
Part03
泄露凭证可被多团伙复用
但两类攻击的目标重叠仍暴露了一个核心问题：窃取到的GitHub凭证可能被多个互不关联的威胁团伙重复利用。一旦维护者账号被攻陷，攻击者可能用它收集CI/CD凭证、注入恶意代码，或是发布篡改后的软件包、运行挖矿工作负载。近期多起软件供应链威胁活动表明，单个开发者身份就可能成为攻击者的突破口，进而入侵构建系统、云账号、软件包注册表，甚至进入下游客户环境。
对防御方而言，核心应对原则是做好身份全流程管控。团队不仅要删除可疑工作流文件、轮换云密钥，还要吊销已泄露的GitHub个人访问令牌，启用可抵御钓鱼的多因素认证。同时应要求所有工作流变更必须经过审核，落实最小权限原则，监控CI运行器的出站网络流量。在GhostAction相关事件中，如果不吊销最初被窃取的GitHub凭证，原攻击者或是其他获取到该凭证的威胁方，都可能再次发起入侵。
攻击指标（IoCs）
注： 文中IP地址和域名均已做无害化处理（例如使用[.]替换点号），防止意外解析或自动跳转。请仅在MISP、VirusTotal或企业自身SIEM等受控威胁情报平台中恢复原始地址。
参考来源：
GhostAction Supply Chain Campaign Uses Malicious GitHub Actions to Steal CI/CD Credentials
https://cybersecuritynews.com/ghostaction-supply-chain-campaign/
