文章总结： 2026年6月，npm注册表遭遇名为miasma的蠕虫攻击，该蠕虫通过phantomgyp技术绕过–ignore-scripts防护，利用窃取的GitHubActionsOIDC令牌生成可通过sigstore验证的虚假SLSA来源证明，在5天内通过三波攻击感染57个包并发布286个恶意版本。攻击窃取npm令牌、云凭证等敏感数据，并利用236个GitHub仓库外传。防御建议包括使用锁文件与npmci、审计binding.gyp文件、过滤CI出口流量、限制OIDC令牌权限及使用范围限定的npm令牌。 综合评分： 94 文章分类： 供应链安全,应用安全,安全运营,漏洞分析,web安全

npm”Phantom Gyp”蠕虫：签名证明也挡不住的供应链攻击

小天 小天

数观天下

2026年6月9日 15:07 浙江

在小说阅读器读本章

去阅读

2026年6月第一周，npm注册表被一条蠕虫搅得天翻地覆。

它叫Miasma。三波攻击，五天之内，感染57个包，推送超过286个恶意版本。最绝的是——这些恶意版本能通过Sigstore签名验证。

对。你跑npm audit signatures，通过。跑cosign verify，也通过。然后你的CI流水线就安安静静地把恶意代码装进了生产环境。

这事闹到微软不得不禁用73个Azure GitHub仓库来止损。

五天三波，每波都比上一波狠

第一波，6月1日。一个Red Hat员工的GitHub账号被攻陷。攻击者往里推了一个commit，触发GitHub Actions OIDC令牌，72秒之内感染了32个 @redhat-cloud-services包。

72秒。不是小时，不是天。

第二波，6月3日深夜。这是最狠的一波。攻击者盯上了@vapi-ai/server-sdk——一个月下载量408,000次的包。从23:30UTC开始，不到两个小时57个包沦陷，286个恶意版本被推送到注册表。

这波攻击用了一种全新的技术，研究者给它起了个名字：Phantom Gyp。

第三波，6月5日。出现了新变种。IronWorm，Rust写的，带着eBPF rootkit。37个包中招。同时新的Miasma变种直接往微软Azure的GitHub组织推恶意commit，逼得微软紧急禁用73个仓库。

Miasma不是凭空冒出来的。它是Shai-Hulud蠕虫家族的后代，这个家族从2025年底就开始活跃了。也就是说，供应链攻击者在持续迭代。

–ignore-scripts 也拦不住

很多开发者的安全习惯是：安装npm包的时候加–ignore-scripts，这样preinstall、postinstall这些生命周期脚本就不会跑。

这个习惯救了很多人的命。但Phantom Gyp绕过了它。

原理不复杂。npm发现包里有个binding.gyp文件时，会自动调用node-gyp rebuild——它认为这意味着这个包有原生C++插件需要编译。

关键点是：这个行为完全发生在–ignore-scripts拦截的系统之外。

攻击者投了一个157字节的恶意binding.gyp。就这么大。利用gyp自己的命令替换语法嵌入shell命令，执行攻击者控制的代码，同时返回一个假的源文件名让构建不报错。

整个载荷执行分四步走：

混淆 → ROT密码加密 → AES-128-GCM解密 → 下载Bun运行时。

最终阶段的代码在Bun下执行，不是Node.js。专门规避那些监控Node.js进程活动的安全工具。Bun二进制文件下载到/tmp/b-*，整个过程不到一秒。

想一想：你的CI环境里突然多了一个Bun进程，不是你的构建脚本起的，但也没人报警——因为监控只盯着Node.js。

签名也过了，证明也过了，全是假的

蠕虫是怎么传播的？

它窃取npm令牌，枚举被攻陷维护者拥有的所有包，重新发布注入了Phantom Gyp载荷的后门版本。然后——用之前偷来的GitHub Actions OIDC令牌，通过Sigstore生成SLSA来源证明。

结果就是：

SLSA来源证明验证的是什么？验证的是”这个包是不是由某个命名仓库里的GitHub Actions工作流构建的”。它不验证触发那个工作流的人是不是被授权的，也不验证那个仓库本身是不是已经被人控制了。

这句话值一个加粗：签名只能证明谁构建的，不能证明谁让它构建的。

它偷什么

Miasma的胃口不小。目标清单包括：

npm令牌

GitHub个人访问令牌（PAT）

AWS凭证

GCP服务账号文件

Azure令牌

HashiCorp Vault令牌

Kubernetes服务账号配置

SSH密钥

IronWorm变种还额外加了AI API密钥：OpenAI、Anthropic、Google Gemini、Cursor。

偷来的数据怎么运出去？加密成JSON，上传到攻击者控制的236个GitHub仓库。

236个。这是一个有规模的行动，不是某个独狼在搞。

现在能做什么

1.锁文件。

Snyk分析指出，如果你提交了package-lock.json到版本控制，并且用npm ci而不是npm install，当Miasma在现有版本号下重新发布注入了载荷的包时，SHA-512完整性哈希会不匹配——npm ci在执行任何代码之前就会直接失败。

**2.审计binding.gyp。

检查你的依赖树里所有包含binding.gyp的包。一个纯JavaScript包没有合理理由带着这玩意儿。**

**3.CI出口流量过滤。

拦截对Bun运行时的下载请求。Miasma依赖从外网拉Bun二进制，断了这条路，攻击链就断了。**

**4.限制OIDC令牌权限。

从不需要的工作流里把id-token: write拿掉。这是SLSA伪造的攻击向量。**

**5.范围限定的npm令牌。

给自动化令牌最小的发布权限。一个维护者的账号被攻陷是迟早的事，但爆炸半径可以控制。**

供应链安全这几年一直在加层。签名、证明、SBOM、零信任构建。每加一层，就觉得多安全了一点。

Miasma告诉我们一件事：这些层叠起来确实有用，但它们验证的是流程，不是意图。

签名可以证明包是从某个仓库构建的，但证明不了那个仓库没被人控制。证明可以验证构建步骤，但验证不了是谁触发了构建。

整个链条最薄弱的那一环，还是最老套的那个——人的账号被搞了。

Red Hat员工GitHub账号沦陷，就是入口。之后所有炫酷的技术绕过都是在这个基础上展开的。

参考来源：

Chainguard / The Hacker News / Snyk Blog / StepSecurity Blog / byteiota.com

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：数观天下 小天 小天《npm”Phantom Gyp”蠕虫：签名证明也挡不住的供应链攻击》