文章总结： npm供应链攻击事件中373个包被投毒，攻击者劫持TanStack发布管道窃取云凭证。关键发现包括利用GitHubActions缓存污染和OIDCtoken窃取，恶意包携带有效签名。建议立即排查安装历史、轮换凭证，并禁用pull_request_target、实施缓存隔离等长期防御措施。 综合评分： 92 文章分类： 供应链安全,漏洞分析,安全运营,威胁情报,应用安全

npm刚刚爆雷：373个包被投毒，你的AWS密钥正在被偷

原创

AI观察 AI观察

AI员工上线

2026年5月13日 06:07 广东

在小说阅读器读本章

去阅读

昨天凌晨，npm炸了。

5月11日19:20到19:26，短短6分钟，攻击者通过TanStack官方管道向npm推送了84个恶意版本。这些包不是仿冒的，是正儿八经从官方仓库发出来的，连SLSA签名证明都是真的。你照往常 npm install，装的就是毒。

一、事件速览：6分钟窗口，CVSS 9.6

攻击编号 CVE-2026-45321，CVSS评分9.6（严重）。攻击者是 TeamPCP，此前已攻破Trivy、Bitwarden CLI等安全工具。

6分钟推送84个恶意版本，覆盖42个@tanstack/*包。StepSecurity研究员20分钟内发现异常，但已有开发者中招。随后蔓延到Mistral AI、UiPath、OpenSearch等，总计 170+包名、373个恶意版本。

⚠️ 所有恶意版本已于5月12日被npm清理下架。本文用于事后排查，攻击窗口已过，但装过毒包的机器仍视为已沦陷。

二、攻击手法：三步连环套

这次攻击根本没偷npm token，而是劫持了发布管道本身。

攻击者fork了TanStack/router仓库，植入恶意commit后发起一个看似无害的PR。这个PR触发了pull_request_target工作流，让fork的代码在基础仓库权限下运行。恶意代码趁机向GitHub Actions共享缓存中注入毒素，第二天当合法维护者合并自己的PR时，发布工作流恢复了被污染的缓存，恶意代码得以在runner运行时直接从进程内存中扒出OIDC token——这是npm信任发布者的凭据。拿到token后攻击者通过TanStack自己的发布管道，6分钟内推送了84个恶意版本，连构建签名都是真的。

更可怕的是，这些包携带了有效的SLSA provenance证明。自动化工具检查签名会显示”合法”，但签名只能证明”哪个管道构建的”，不能证明”管道有没有被劫持”。载荷文件 router_init.js（2.3MB混淆代码）通过 preinstall 脚本自动执行，扫描100多个路径窃取AWS/GCP/K8s凭证、GitHub PAT、SSH私钥、加密钱包，外泄走Session/Oxen加密网络，拦截难度极高。更阴的是它还有个死亡开关：发现GitHub token被撤销就立即执行 rm -rf ~/，所以先杀进程再换密码，顺序不能反。

三、精准4步自查

如果你在5月11日装过npm包，立刻执行：

Step 1：查安装历史

npm ls | grep -E "@tanstack|@uipath|@mistralai|opensearch|guardrails"

Step 2：查可疑脚本

grep -r "preinstall\|postinstall" package.json node_modules/*/package.json

看到陌生的 setup.mjs、execution.js、router_init.js，立即隔离。

Step 3：搜恶意文件

find node_modules -name "router_init.js" -o -name "setup.mjs" -o -name "execution.js"

Step 4：轮换凭证（按顺序！）

1. 先终止可疑进程（gh-token-monitor 守护进程）
2. 轮换：GitHub PAT → npm token → 云凭证 → K8s账号 → SSH私钥 → Vault token
3. 检查仓库异常commit（搜索 “A Mini Shai-Hulud has Appeared”）

这个攻击利用的是GitHub Actions配置漏洞，不是GitHub本身不安全，2FA依然重要。问题出在pull_request_target滥用和缓存隔离缺失。

四、波及清单

| 项目 | 平台 | 影响 | | — | — | — | | TanStack (42包/84版本) | npm | 官方管道被劫持 | | Mistral AI | npm+PyPI | AI SDK被植入后门 | | UiPath | npm | RPA工具链 | | OpenSearch | npm | 搜索客户端 | | Guardrails AI | PyPI | AI安全框架 | | SAP CAP | npm | 企业开发工具链 |

五、长期防御

1. 禁用pull_request_target：除非你100%确定需要它，否则一律改用pull_request。这是本次攻击的入口点，也是最容易修复的防线。
2. 缓存隔离：fork和基础仓库的Actions缓存绝对不能共享，否则攻击者只需要一个fork就能污染你的整个构建流程。
3. 签名≠安全：SLSA provenance只能证明构建来源，不能证明过程没被劫持，别以为有签名就高枕无忧。
4. 最小权限OIDC：给发布token设 narrowly-scoped 权限，不要给全局管理权限，就算token被偷，破坏面也有限。
5. 依赖锁定：坚决用package-lock.json或pnpm-lock.yaml，禁止自动升级到latest，不要让攻击者通过新版本来投递载荷。
6. 私钥隔离：CI里不要放长期有效的SSH私钥，改用短期OIDC token，定期轮换，缩短攻击者的可用窗口。

供应链攻击只会进化。6分钟推送84个毒包的速度说明防御不能靠人盯，得靠机制。你的 npm install 看似 innocuous，但执行的每一行代码都可能是陷阱。

现在就按Step 1-4查一遍，10分钟的事。查了没事，心安。查到有异常，立刻按顺序轮换凭证。

别等了。

免责声明：

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

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

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

本文转载自：AI员工上线 AI观察 AI观察《npm刚刚爆雷：373个包被投毒，你的AWS密钥正在被偷》