一种名为Megalodon的新GitHub攻击已影响超过5500个仓库
2026年5月18日,代号'巨齿鲨'(Megalodon)的恶意软件在六小时内感染超过5,500个GitHub仓库,注入恶意CI/CD后门,窃取云凭证与密钥。攻击者通过伪装成自动化维护的临时账户和精心设计的提交信息规避审查,利用高权限工作流变体实施大规模供应链攻击,影响包括 开源在线聊天平台Tiledesk在内的多个项目。
2026年5月18日,代号"巨齿鲨"(Megalodon)的大规模自动化供应链攻击席卷GitHub平台,在不到六小时内向超过5,500个代码库注入了恶意CI/CD后门,创下GitHub Actions投毒攻击的最快扩散纪录。
Part01
攻击时间线与手法
安全公司SafeDep发现,2026年5月18日UTC时间约11:36至17:48期间,"巨齿鲨"行动通过随机八字符用户名的临时账户,向5561个GitHub代码库推送了5,718个恶意提交。攻击者伪造了build-bot、auto-ci、ci-bot、pipeline-bot等作者身份,使用build-system@noreply.dev和ci-bot@automated.dev邮箱伪装常规CI自动化维护。提交信息如"ci: add build optimization step"和"chore: optimize pipeline runtime"经过精心设计,可规避常规代码审查。
Part02
恶意负载变体分析
该攻击部署了两种共享同一C2服务器(216.126.225.129:8443)的GitHub Actions工作流变体:
- SysDiag(大规模变体):
- Optimize-Build(定向变体):
替换现有工作流为workflow_dispatch触发,创建静默后门,攻击者可随时通过GitHub API激活且不产生可见的CI运行记录
两种变体均要求id-token: write和actions: read高权限,用于窃取 OIDC令牌,实施云身份冒充。Base64编码的bash脚本(共111行)被触发后会执行多阶段凭证窃取:
- 收集所有CI环境变量、/proc/*/environ及PID 1环境数据
- 提取AWS凭证(访问密钥、秘密密钥、会话令牌)
- 通过gcloud auth print-access-token获取GCP访问令牌
- 从AWS IMDSv2、GCP元数据和Azure IMDS端点获取实时凭证
- 窃取SSH 私钥、Docker认证配置、.npmrc、.netrc、Kubernetes 配置、Vault令牌和Terraform凭证
- 使用30多个正则表达式扫描源代码中的API密钥、JWT、数据库连接字符串、PEM 密钥和云令牌
- 窃取GitHub Actions OIDC令牌实施直接云身份冒充
Part03
典型受害案例分析
开源在线聊天平台Tiledesk成为关键下游攻击目标。攻击者通过提交acac5a9入侵其GitHub代码库,将合法Docker构建工作流替换为Optimize-Build后门。维护者在不知情的情况下,将受污染的@tiledesk/tiledesk-server 2.18.6至2.18.12版本发布到npm registry,导致后门通过 软件包传播(应用代码未改动,仅工作流文件被篡改)。Part04
入侵指标(IoC)
注:IP地址和域名已做无害化处理(如[.]),仅在MISP、VirusTotal等威胁情报平台使用时需还原
Part05
应急缓解措施
若代码库在2026年5月18日收到来自build-system@noreply[.]dev或ci-bot@automated[.]dev的提交,应立即:
- 回退恶意提交并审计所有.github/workflows/文件
- 轮换GitHub Actions运行器可访问的所有密钥(令牌、API密钥、SSH密钥、云凭证)
- 检查云日志中是否存在未知工作流运行的异常OIDC令牌请求
- 在Actions标签页检查意外的workflow_dispatch执行记录
- 将GitHub Actions固定到特定提交SHA而非可变版本标签
- 为外部贡献者的拉取请求设置工作流审批关卡
参考来源:
Over 5,500 GitHub Repositories Infected in ‘Megalodon’ Supply Chain Attackhttps://www.securityweek.com/over-5500-github-repositories-infected-in-megalodon-supply-chain-attack/



评论1次
这波操作确实有点东西。六小时五千多个库,说实话自动化程度已经相当离谱了。
核心看点我觉得有两个:一个是攻击者对 CI/CD 信任链的精准拿捏,另一个是 workflow_dispatch 那个静默后门的思路。
pull_request_target 自动触发 + id-token write 权限这套组合拳,配合伪造的 CI-bot 身份,基本上就是吃定了大多数项目对自动化提交都不会仔细看。关键是很多开源项目压根没开分支保护,main 直接能推,这种就是躺枪。
那个 Optimize-Build 变体更阴,直接把合法工作流替换掉,触发方式改成 workflow_dispatch,攻击者想激活就激活,还不留记录——等于在代码库里埋了个随时可触发的后门,运维根本不知道有人在用。
供应链这块更绝,Tiledesk 那个案例就是教科书级别的。攻你代码库不是为了改你应用代码,就改个 workflow 文件,然后正常发版,用户更新时不知不觉就把后门带进去了。这种打法对下游客群的杀伤力比直接硬刚大得多。
实操层面的话,这种大规模撒网攻击有个弱点——临时账号 + 统一 C2,所以如果你的库在那天收到了陌生人的 PR 或者提交,先查一下作者邮箱,build-system@noreply.dev 和 ci-bot@automated.dev 这类特征还是比较明显的。