Phantom Gyp：npm 关掉安装脚本之后，攻击者把执行点搬到了 node-gyp 从来没被检查过的文件里

2026 年 7 月 8 日，npm v12 默认关闭了安装脚本，GitHub 称这是关闭了生态系统中最大的代码执行面。三天后，jscrambler 的供应链攻击落地，恶意版本在 import 和 CLI 调用时执行，而不是在安装时，明确绕过了 --ignore-scripts。这还不是全部。

2026 年 6 月 3 日，攻击者在不到两个小时内发布了 57 个 npm 包、286 个恶意版本，部署了一个自我复制的 CI/CD 蠕虫。它使用了一种被研究人员称为 Phantom Gyp 的技术：把恶意载荷藏在一个大多数安全工具从不检查的文件里——binding.gyp。这个文件是 node-gyp 在安装时用来触发本地编译的构建配置，攻击者利用它在 npm install 期间执行代码，绕过了当时几乎所有的 npm 安全防御。

受影响包包括 @vapi-ai/server-sdk（月下载约 40.8 万次）和 ai-sdk-ollama（约 12 万次），合计周下载超过 50 万次。恶意软件从 npm、GitHub、AWS、GCP、Azure、HashiCorp Vault、Kubernetes 和 RubyGems 窃取凭据，然后用这些凭据发布受害者维护的每一个包的投毒版本，并向它能触及的每一个 CI 工作流注入恶意步骤；它还会把后门配置写入 AI 编程助手的目录，意味着清除包之后后门仍然存在。蠕虫包含一个 tripwire：如果触碰了植入的诱饵 token，它会执行 rm -rf ~/。

最危险的细节是：即使 npm 的 latest dist-tag 已经被重定向到干净版本，恶意版本仍然以精确 tarball 的形式存在于 registry 上。任何锁文件、精确 pin 或传递依赖如果引用了恶意版本，仍然会拉取恶意软件。一个干净的 latest 标签不是安全的证据。

这个攻击链对防御的启示不是“不要用 npm”，而是：安装脚本防护只是供应链防御的一层，攻击者会不断找到新的安装时执行面。binding.gyp 是一个构建配置文件，大多数安全工具不把它当作可执行代码来审查；node-gyp rebuild 在 npm install 期间触发，这是一个合法的构建步骤，只是被武器化了。防御需要覆盖的不只是 package.json 里的 scripts，还包括构建配置文件、原生模块的编译路径、以及任何在安装期间被调用的工具链。

一个可操作的响应清单是：如果任何机器或 CI runner 在 2026 年 6 月 3 日之后对受影响版本执行过 npm install，不要在那个环境上运行任何东西；从干净机器轮换所有凭据，再处理被污染的环境。检查锁文件里的精确版本和传递依赖，而不是只看 latest。把 binding.gyp 和原生构建配置纳入依赖审查的范围。供应链安全的下一步不是更严格地审查安装脚本，是假设安装时执行面会不断转移，把监控和权限边界下沉到进程和网络层。