每周1亿次下载的axios被投毒了，但是源码里没有一行恶意代码！

有没想过，那每周下载量能突破一亿的npm明星包axios，哪天会变成攻击者的木马载体呀？在2026年4月初的时候，这看似不大可能的事儿真切发生了。有人在群里发消息讲axios出状况了，第一反应全都是质疑呢，可事实就摆在眼前：攻击者没改动一行axios的源码，然而却使得成千上万个项目在npm install的那一刻自动下载了远控木马。

攻击者是怎么绕过GitHub代码审查的

axios的GitHub仓库之中，自始至终都未曾出现过恶意代码，哪怕你对着源码看上一万回，也找寻不到任何问题。事实上，问题并非存在于源码里面，而是攻击者窃取了axios维护者的npm账号，进而绕过了GitHub全部的代码审查以及CI/CD流程，径直往npm registry推送了两个“官方版本”。npm注册中心和GitHub是两个彼此独立的系统，你于GitHub上所看见的代码，跟你通过npm install安装到的内容有可能全然不是同一事物。只要具备维护者的npm令牌，便能够直接进行发包，此漏洞相较于代码后门更为隐蔽。

18小时预埋加39分钟全覆盖的攻击时间线

攻击者在提前18小时之时，借由一次性账号发了plain - crypto - js@4.2.0，此版本是干净的，其内容乃是合法crypto - js的复制品，不存在任何恶意代码。为何要发一个干净版本呢？是由于一个零历史的新包突然被大包依赖会触发安全警报，所以先养号18小时之后再采取行动。在T - 30分钟的时候发布plain - crypto - js@4.2.1，向其中注入了恶意postinstall脚本。在T等于0的时刻，运用被盗的维护者账号去发布axios处于1.14.1版本，在T加上39分钟之后，又发布axios处于0.30.4版本，将1.x以及0.x这两条版本线一次性全部覆盖。在T加上3小时以后，npm把恶意版本下架，攻击窗口随之关闭，前后时间不到3小时。

恶意载荷在安装后2秒内就开始回传信息

就在你执行npm install的那一瞬间，plain - crypto - js的postinstall脚本会自己自动运行起来。它会去检测操作系统，接着下载远控木马，随后连接上攻击者的服务器sfrclak.com:8000，然后进行自我删除操作，再把package.json替换成干净的版本。等你事后去查看node_modules时什么都找不到，这情形就如同你去五金店买了一把锁，品牌是对的，包装也是对的，外观同样是对的，然而里面却被人换成了带有后门的那种。安全公司StepSecurity作出这样的评价，称这是“针对npm Top 10包，有记录以来最精密的供应链攻击之一”。恶意载荷情况是在npm install开始后2秒内，就开始朝着攻击者服务器回传信息，其速度比npm解析完其他依赖还要快。

如何检查你的项目是否中招

针对使用了axios的项目，需花费5分钟来跑一遍检查。要打开你的package-lock.json文件，或者pnpm-lock.yaml文件，又或者yarn.lock文件，然后在其中搜索plain-crypto-js这三个关键词。要注意此次检查的是1.14.1和0.30.4这两个恶意版本，可不是1.14.0版本。因为^1.14.0意味着会自动升级到最新兼容版本，而这次恰恰就是这个机制导致恶意版本被安装上的。恶意版本虽说已经下架了，但显式锁定版本的确是个好习惯。随手瞅一眼你别的依赖里头有无值得怀疑的install脚本，CI环境同样得做清理，GitHub Actions、GitLab CI的node_modules缓存以及npm缓存当中要是留有恶意tarball，下次构建仍会被命中。

npm cache clean --force

激进防御和凭证轮换怎么做

"axios": "1.14.0"

grep -r '"postinstall"' node_modules/*/package.json

十分激进的施行办法是于.npmrc之中添加ignore - scripts = true，以此在全局范围之内禁止postinstall脚本的执行。然而需要留意的是，像是esbuild、sharp这类包也是依靠postinstall来下载二进制文件的，若全然禁止从而极有可能对构建造成影响，你得自行去进行权衡考量。更为关键重要的一点是凭证轮换这一事项：并非是“或许要更换密码”这种情况，而是当下就需要对所有CI/CD的npm令牌、GitHub令牌以及各种各样的访问密钥展开轮换操作。倘若CI机器存在可能中招的情况，那就检查CI secrets有无泄露，查找异常进程以及网络连接，并着重关注“sfrclak.com:8000”这个地址。在RAT运行起来以后，你机器上的所有一切对于攻击者而言便都成为透明的了，其中涵盖环境变量里的全部密钥。

这次攻击给开发者的核心教训

蛮多开发者的直观感觉是，axios每周有着一亿次的下载量，总不至于会出问题吧。换个角度去思考，越是热门的包，对于攻击者而言，投入产出的比例就越高，去投毒一个每周只有一百次下载量的包，根本不会有人在意，然而投毒axios的话，仅仅只需三个小时的窗口时间，就足以覆盖成千上万的项目。此次axios的源码不存在任何问题，问题出在了发布链上。那条你默认给予信任的，从代码一直到registry的链路，才是真正应该被审计的对象。锁版本的lockfile，审计install脚本，监控依赖变更，关注registry元数据的发布者签名，这些并非有空再去做的事。

浏览完此篇文档以后，你有没有胆量此时此刻即刻开启项目的lockfile找寻一下plain-crypto-js呢？要是你身旁有的使用axios的友人尚不晓得此事，转发给其瞧一瞧，说不定就助其规避了一回安全事件。欢迎于评论区分享你的查检成果以及防御举措，点赞以使更多人目睹这个警示。

相关标签： # axios # npm # 供应链攻击 # 安全漏洞 # postinstall脚本