2026年5月18日，一场代号为"巨齿鲨"（Megalodon）的自动化供应链攻击席卷GitHub平台。从UTC时间11:36到17:48，短短不到六小时的窗口期内，超过五千五百个代码仓库被植入恶意CI/CD后门。这起事件以其惊人的传播速度和隐蔽的渗透手法，成为GitHub Actions投毒史上最具破坏力的案例之一，也为全球开源生态敲响了新的安全警钟。
攻击规模与伪造身份
SafeDep安全团队的事后追踪显示，攻击者在当日集中动用了大量一次性账户。这些账户采用随机生成的八字符用户名，向5,561个仓库累计推送了5,718个恶意提交。为了降低被人工审查发现的概率，攻击者精心伪造了提交者身份，诸如build-bot、auto-ci、ci-bot、pipeline-bot等名称，配合build-system@noreply.dev与ci-bot@automated.dev这类邮箱地址，从外观上模仿日常自动化构建系统的例行维护行为。
提交信息的设计同样充满迷惑性。"ci：添加构建优化步骤"、"chore：优化管道运行时"这类措辞看似平淡无奇，实则刻意贴合正常开发团队的协作习惯。许多维护者在快速浏览提交列表时，极易将其误判为常规的CI配置更新，从而跳过深入审查。
双轨制载荷：批量渗透与精准潜伏
此次行动并非单一模式的无差别轰炸，而是采用了两种互补的GitHub Actions工作流变体，背后共享同一台位于216.126.225.129:8443的C2服务器。
SysDiag属于批量扩散版本。它的核心动作是在目标仓库中植入.github/workflows/ci.yml文件，触发器设置为pull_request_target与push。这意味着只要仓库的任何分支发生提交，恶意代码就会自动执行，覆盖范围极广。
Optimize-Build则走精准潜伏路线。攻击者不会新增文件，而是直接篡改仓库中已有的工作流配置，将原有触发器替换为workflow_dispatch。这种改动的隐蔽性更高，因为表面上不会产生任何异常的CI运行记录，也不会引发构建失败。攻击者可以通过GitHub API在需要时远程静默激活后门，实现按需唤醒。
两种变体在权限申请上高度一致，均要求id-token: write与actions: read。这类权限足以窃取OIDC令牌，进而冒充合法身份访问云资源，为后续横向移动铺平道路。
多阶段凭证窃取机制
被触发的载荷是一段经过base64编码的bash脚本，展开后达111行。其执行逻辑呈现出典型的多阶段窃取特征，几乎覆盖了CI/CD环境中所有可能存放敏感凭证的位置。
脚本启动后会立即读取全部CI环境变量，同时遍历/proc/*/environ以及PID 1的环境数据。随后，它会在各主流云平台的配置文件中翻找AWS访问密钥、会话令牌，调用gcloud auth print-access-token获取GCP临时凭证，并向AWS IMDSv2、GCP元数据端点以及Azure IMDS发起请求，抓取实例级别的实时认证信息。
本地凭证也未能幸免。SSH私钥、Docker认证配置、.npmrc、.netrc、Kubernetes集群配置、Vault令牌以及Terraform状态文件均被纳入扫描范围。更激进的是，脚本还会用grep命令在源代码中匹配超过30种正则表达式模式，涵盖API密钥、JWT令牌、数据库连接字符串、PEM私钥及各类云访问令牌。这种"环境+文件+源码"的三层收割策略，大幅提升了敏感信息外泄的概率。
Tiledesk事件：从代码库到npm的连锁污染
在这场大规模扫描中，开源在线聊天平台Tiledesk遭受了最为严重的下游冲击。攻击者成功渗透了Tiledesk的GitHub仓库，通过提交acac5a9将原本合法的Docker构建工作流替换为Optimize-Build后门。由于应用层源代码本身未被改动，仅工作流文件发生了变更，这种细微差异在版本发布前的审查中极易被忽视。
维护者在不知情的状态下，将受污染的@tiledesk/tiledesk-server 2.18.6至2.18.12版本陆续发布至npm注册表。后门由此从代码托管平台延伸至包管理生态，任何安装或升级至这些版本的开发者，其CI环境都可能面临凭证泄露风险。这一链条清晰地展示了现代软件供应链中"代码库---CI系统---包注册表"的脆弱传导关系。
入侵指标梳理
对于安全运营团队而言，以下IoC可用于内部威胁情报平台（如MISP、VirusTotal或SIEM）的关联检测：
表格
| 指标类型 | 具体数值 |
|---|---|
| C2服务器 | hxxp://216[.]126[.]225[.]129:8443 |
| 活动标识 | megalodon |
| 伪造邮箱 | build-system@noreply[.]dev、ci-bot@automated[.]dev |
| 伪造作者 | build-bot、auto-ci、ci-bot、pipeline-bot |
| 批量工作流 | .github/workflows/ci.yml（SysDiag变体） |
| 目标工作流 | Optimize-Build（workflow_dispatch触发） |
| 受影响npm版本 | @tiledesk/tiledesk-server 2.18.6--2.18.12 |
| 恶意提交 | acac5a9854650c4ae2883c4740bf87d34120c038 |
需要说明的是，上述IP地址与域名中的分隔符已做脱敏处理，目的是防止在文档阅读或复制过程中意外触发解析。实际投入检测规则时，需还原为真实地址格式。
企业级缓解与长期加固
面对此类针对CI/CD管道的自动化攻击，组织需要建立覆盖代码、凭证与云资源的多维响应机制。若仓库在2026年5月18日前后收到过来自build-system@noreply.dev或ci-bot@automated.dev的提交，应立即启动溯源排查。
首要动作是回滚所有可疑提交，并对.github/workflows/目录下的全部文件进行逐行审计，确认是否存在未经授权的触发器变更或base64编码的异常脚本。所有可能被GitHub Actions运行器接触到的凭证------包括个人访问令牌、API密钥、SSH密钥及云服务商IAM凭据------都应执行紧急轮换，避免历史泄露数据被长期利用。
云侧同样需要加强监控。安全团队应审查近期日志，重点关注来自未知工作流或异常IP的OIDC令牌请求。GitHub仓库的Actions选项卡也值得仔细核对，排查是否有未预期的workflow_dispatch手动执行记录。
从架构层面看，将GitHub Actions引用的第三方动作固定到具体的提交SHA值，而非使用可变的版本标签，能够显著降低供应链被污染后的影响面。对于外部贡献者发起的拉取请求，启用工作流审批机制也是必要的隔离手段，防止未经审核的CI配置直接生效。
SafeDep的Malysis引擎正是在分析@tiledesk/tiledesk-server@2.18.12的捆绑工作流文件时，通过识别其中的base64编码载荷率先标记了这起攻击。这也从侧面印证，在代码审查之外部署自动化的供应链扫描能力，已成为捕获高隐蔽性威胁的关键补充。