2026 npm大规模供应链蠕虫攻击 原理、风险与应急排查方案
大家今天执行npm install了吗?
如果装到了受污染版本,你机器里的 npm Token、GitHub 凭证、AWS 密钥、Kubernetes 配置,可能已经被打包送走。
2026 年 8 月 4 日,npm 生态爆发大规模供应链蠕虫攻击。

截至 Aikido 在 8 月 5 日更新时:
至少 444 个包被感染。横跨 1381 个恶意版本。相关软件包合计月安装量超过 20 亿次。
注意:20 亿是这些包的正常月安装覆盖量,不代表已经有 20 亿次真实感染。
但风险依然足够恐怖。
一个不起眼的包,卡住了整个前端生态
攻击起点之一是 keyv。

你可能从未主动安装过它,但它藏在大量项目的传递依赖里。
例如:
eslint └── file-entry-cache └── flat-cache └── keyv
攻击者攻陷维护者的 GitHub 账号,将恶意代码直接推入 main 分支,再通过官方 GitHub Actions 发布。
结果是:
恶意包不仅来自官方账号,还带着有效的 provenance 签名。
绿色认证没有失效。
它只是诚实地证明:这份恶意代码,确实由官方流水线构建并发布。
安装依赖,恶意程序直接启动
受污染的 package.json 中,被加入了一行:
"preinstall": "node setup.mjs"
这意味着你甚至不需要主动运行任何可疑文件。
只要执行:
npm install
安装尚未完成,恶意脚本已经开始运行。
第一阶段的 setup.mjs 会偷偷下载 Bun 运行时。
随后,它使用 Bun 执行一个约 728KB 的重度混淆文件:
Math_Symbol.js
这个文件本质上是一台凭证吸尘器。
它会搜索:
- npm Token
- GitHub PAT、OAuth Token、GitHub App Token
- GitHub Actions OIDC 凭证
- AWS AK/SK、Session Token 和实例元数据
- Kubernetes ServiceAccount Token 与 kubeconfig
- HashiCorp Vault Token
- Stripe、Slack 密钥
- .env 文件
- SSH 私钥
- Terraform 状态文件
- Docker、VPN 和数据库配置
在 GitHub Actions Runner 中,它甚至会尝试读取进程内存,提取工作流中的秘密和 OIDC 发布凭证。
偷完密钥,还要把你的包变成病毒
这不是普通的信息窃取木马。
它是一条真正的供应链蠕虫。
拿到 npm Token 后,载荷会自动:
- 查询该 Token 有权发布的所有 npm 包;
- 下载最新版本;
- 注入 setup.mjs 和恶意载荷;
- 添加 preinstall 钩子;
- 提升 patch 版本号;
- 重新发布到 npm。
你的开发机一旦中招,你维护的包就可能成为下一座发射井。
你的用户继续安装。
他们的 Token 继续被盗。
他们维护的包继续被污染。
感染链由此自动扩散。
不运行 npm install,也可能被触发
攻击者还会利用盗取的 GitHub App Token 修改代码仓库,植入:
.claude/settings.json .vscode/tasks.json
开发者下次使用 Claude Code 进入仓库,或者在 VS Code 中打开项目时,恶意任务可能再次执行。
也就是说,攻击面已经从依赖安装扩展到了:
代码仓库、IDE 和 AI 编程代理。
数据被送到了哪里?
窃取的数据会先使用 RSA 公钥加密,然后上传到公开 GitHub 仓库。
这些仓库的描述中通常包含:
Shai-Hulud: Here We Go Again
如果 GitHub 外传失败,载荷还会尝试连接:
npm-cache[.]com:443/router
攻击者甚至把备用地址写进以太坊智能合约,使外传基础设施可以动态切换。
哪些版本需要重点排查?
首批确认的高风险版本包括:
keyv 6.0.0 flat-cache 6.1.24 file-entry-cache 11.1.6 cacheable-request 13.0.20 cacheable 2.5.1 @cacheable/memory 2.2.1 cache-manager 7.2.10 @cacheable/node-cache 3.1.2 @cacheable/utils 2.5.1 @cacheable/net 2.1.1 ecto 5.0.1
但这不是完整名单。
蠕虫已经扩散到数百个不同包和企业命名空间。
立刻做这几件事
先检查依赖树:
npm ls keyv flat-cache file-entry-cache cacheable-request cacheable cache-manager --all
再检查项目和主机中是否出现:
setup.mjs Math_Symbol.js math_init.js
如果确认安装过恶意版本,并且没有使用--ignore-scripts:
不要只删node_modules。
应当直接按主机失陷处理:
- 隔离开发机或 CI Runner;
- 保存日志和现场证据;
- 清除恶意文件及持久化配置;
- 撤销 npm、GitHub、AWS、Vault 和 Kubernetes 凭证;
- 审计异常发包、提交、仓库和云端访问;
- 从可信环境重新构建。
不要只“修改密码”。
攻击者拿走的可能是可发布、可横向移动、可访问生产环境的完整机器身份。
最危险的不是 444 个包
最危险的是,现代软件开发仍然默认相信:
- 维护者账号不会被盗。
- 官方流水线不会作恶。
- 签名包就一定安全。
- 安装依赖只是下载文件。
但在 npm 生态里:
下载,本身就可能等于执行。
这次是 444 个包。
下一次,可能是你每天都在使用、却从未真正检查过的那个深层依赖。
下一次执行npm install前,先问一句:
你信任的究竟是代码,还是某个陌生维护者尚未失窃的账号?
以上关于2026 npm大规模供应链蠕虫攻击 原理、风险与应急排查方案的文章就介绍到这了,更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章,希望大家以后多多支持码云笔记。
如若内容造成侵权/违法违规/事实不符,请将相关资料发送至 admin@mybj123.com 进行投诉反馈,一经查实,立即处理!
重要:如软件存在付费、会员、充值等,均属软件开发者或所属公司行为,与本站无关,网友需自行判断
码云笔记 » 2026 npm大规模供应链蠕虫攻击 原理、风险与应急排查方案
微信
支付宝