一场针对软件供应链的协同攻击于2026年9月1日瞄准了61个GitHub公开仓库。据安全公司Radware于10月29日公布的调查，攻击者发布了83个恶意条目——包括议题、拉取请求和评论——试图在持续集成与持续交付（CI/CD）环境中执行命令并窃取开发机密。
事件经过
攻击活动高度集中：83个恶意条目中有77个在约43分钟内发布，即9月1日11时26分至12时10分（UTC）。当天稍后又出现了包含6个条目的第二波攻击。目标包括Google LangExtract、Trivy、Brave Browser、MLflow、ToolJet和PX4-Autopilot等知名项目——但这并不意味着这些项目全部遭到入侵，具体影响取决于每个工作流的权限和配置。
攻击方式
攻击机制是利用GitHub Actions处理不可信内容时的Shell命令注入。攻击者在议题和拉取请求的标题中嵌入Bash命令替换表达式（写作$()）。当工作流将这些内容直接插入Shell代码时，Bash会将其解释为要执行的命令。
有效载荷使用env命令收集进程的环境变量，经Base64编码后，尝试通过HTTP发送到攻击者控制的服务器（54.205.16.142，端口8443）。即使相关议题或拉取请求从未获批、从未合并，或在提交几分钟后就被关闭，攻击仍可能得逞。
已确认的事实与未确认的事实
Radware分析了真实运行日志，发现了直接证据，证明恶意命令在两起案例的自动化环境中得到了执行：PX4-Autopilot的第28488号拉取请求和workout-cool项目的一个议题。但调查并未确认机密被盗、仓库写入权限被获取、源代码被修改或已发布的版本遭到破坏。GitHub Actions的机密不会自动对所有工作流开放，仅凭命令执行本身不足以证明凭据已被窃取。
Radware还发现，用于传播攻击的GitHub账号中有一些此前有过正常的开发活动记录，另有一名用户公开表示，自己并未创建归于其名下的恶意活动。
维护者应该怎么做
研究人员的建议是：使用GitHub Actions的项目绝不要将用户提供的内容直接插入Shell脚本，应通过环境变量传递数值。公开仓库的维护者应检查2026年9月1日发布的议题和拉取请求，并出于谨慎，轮换可能在CI/CD环境中暴露的凭据。
另请参阅 Geekiki：WordPress漏洞在更新期间遭到利用；CISA要求11月6日前修复。
图片来源：Radware 插图，发布于该公司关于此次调查的官方博客。
来源
- Radware — Inside a GitHub Supply Chain Attack Campaign
- Cyber Security News — Hackers Target 61 GitHub Repositories With Command Injection Attacks to Steal CI/CD Secrets
- GitHub — PX4/PX4-Autopilot，Pull Request #28488
透明声明：本文在人工智能的辅助下，基于互联网公开来源撰写，并对照下方引用的原始来源进行了核对。请始终查阅原始来源以确认细节。
Muse
