事件概述
应用安全公司 Socket 披露，两个曾在今年 5 月 Mini Shai-Hulud 供应链攻击中被投毒的第三方 GitHub Actions，在 9 月 16 日被其维护者重新启用，但仓库内的恶意代码并未清理。这两个 Action 分别是 actions-cool/issues-helper 与 actions-cool/maintain-one-comment，此前已由 GitHub 安全团队移除，以阻止下游工作流继续拉取恶意代码。
重新启用后，两者的发行标签依旧指向 5 月 18 日引入恶意内容的提交。因此任何以版本标签（而非固定提交哈希）引用它们的流水线，会在下一次运行时重新下载并执行同一份载荷。该状态持续到 9 月 25 日，GitHub 才再次将两个仓库禁用。
技术细节
投毒入口
5 月的 Mini Shai-Hulud 活动共污染 npm 索引中的 323 个包、639 个版本，载荷目标为开发者令牌、账号凭据与 CI/CD 密钥。本次两个 Action 的 index.js 中保留了同一份混淆载荷，构成对构建环境的持续窃密通道。
为什么“禁用”没有终结风险
问题不在新增投毒，而在标签可变更（mutable tag）这一设计。仓库重新可访问后，标签解析结果自动回到含恶意代码的提交，攻击者无需任何后续动作，下游工作流即恢复执行载荷。Socket 记录的暴露窗口起自 9 月 16 日 11:09 至 18:16（GMT+2）。
影响范围
GitHub 依赖图显示约有 15000 个仓库依赖 issues-helper，但不代表全部使用受影响标签。这两个 Action 用于议题与评论的自动清理，通常在每日定时任务或新建议题、拉取请求时触发，因此大部分受影响仓库在重新启用后一天内就会跑到载荷。
影响评估
CI/CD 环境集中持有云平台密钥、制品仓库凭据、签名证书与部署权限，是供应链攻击中回报率最高的目标。本次事件的风险特征不是复杂度，而是沉默：仓库看起来只是恢复正常，流水线显示成功，窃密行为发生在构建过程中，不会在应用侧留下明显异常。若相关密钥未轮换，攻击者可在事后长期使用。
该事件也暴露了事件响应的常见断层——把组件下架当成处置完成，却没有在恢复可访问前完成代码清理与哈希核对。
修复建议
- 全量搜索工作流中对 actions-cool/issues-helper 与 actions-cool/maintain-one-comment 的引用，删除引用或改为固定到经验证的干净提交哈希。
- 审计 9 月 16 日以来的工作流运行记录，对照构建日志排查异常下载与网络外连。
- 轮换这些工作流可访问的全部密钥与令牌，包括仓库 Secret、云平台访问密钥、制品库凭据。
- 组织层面强制要求第三方 Action 使用 SHA 固定，禁止以分支或标签形式引用。
- 对第三方 Action 建立准入清单，关闭长期不用的 Action 并定期核对依赖图变更。