axios遭恶意攻击：两个版本被植入后门，开发者需立即检查
axios这次是真的出事了。
就在3月31号凌晨，这个全世界开发者都在用的网络请求库，被人动了手脚。攻击者拿到了axios维护者的npm账号，直接往里面塞了两个恶意版本，分别是1.14.1和0.30.4。
攻击是怎么一步步发生的
整个过程是这样的。
攻击者在3月30号就开始准备了。他们先用一个叫nrwise的账号，往npm上发布了一个看起来人畜无害的包，叫plain-crypto-js@4.2.0。这是个空壳子，没有任何恶意代码，就是为了让这个包在npm上有个发布记录，后面再发恶意版本的时候不会显得太突然。
过了18个小时，到了3月30号半夜，攻击者又发了plain-crypto-js@4.2.1。这个版本就有问题了，里面藏了一个会在安装时自动执行的恶意脚本。
然后就是关键的一步。
3月31号凌晨0点21分，攻击者用盗来的维护者账号，直接通过npm命令行发布了axios@1.14.1。39分钟后又发了axios@0.30.4。
这两个版本表面上看跟正常的axios没区别，代码也没被改过。唯一的变化，就是在package.json里多加了一行依赖，指向那个plain-crypto-js@4.2.1。
就是这么一个小小的改动，出了问题。
开发者只要在自己的项目里执行npm install，或者项目里用的是^1.14.0这种写法，就会自动把1.14.1这个恶意版本拉下来。一安装，plain-crypto-js那个包里的后安装脚本就会自动执行。
恶意脚本干了什么
这个脚本会干几件事。
它会先看看你的电脑是什么系统。Windows、macOS还是Linux，它都认得。然后它会连到一个叫sfrclak.com的服务器上，从那里下载一个远程控制木马。
Windows上的木马会把PowerShell改名藏到ProgramData目录下，伪装成Windows Terminal的样子，然后写一个注册表项，保证每次开机都会自动连回黑客的服务器
macOS上的木马会藏到/Library/Caches/com.apple.act.mond这个路径，名字起得跟苹果系统文件似的，一般人根本看不出来
Linux上的木马比较简单，直接放在/tmp/ld.py那里
这个木马一旦跑起来，每60秒就会给黑客发一次消息。电脑的主机名、用户名、装了啥系统、开了哪些进程、连了哪些盘，这些信息都会被发走。黑客还能远程下命令，在这台电脑上执行任意的代码，或者往里面再塞别的恶意程序。
更隐蔽的是，这个恶意脚本跑完之后会把自己删了，还会把package.json换成一个干净的版本。等你事后去查，node_modules里什么都看不出来，只有安装日志里还能找到点痕迹。
npm的反应和影响范围
好在npm反应还算快。这两个恶意版本在npm上只挂了大概3个小时，就被下架了。但就是这3个小时，已经有大约3%的axios用户把这些恶意版本装上了。考虑到axios每周下载量有一亿次左右，这个数字不小。
谁干的
安全公司那边查下来，说是朝鲜的黑客组织干的，代号叫UNC1069。这个组织以前就专门搞供应链攻击，主要是为了偷加密货币。但这次他们把目标对准了开发者，可能是想顺着开发者的电脑再往更深的地方渗透。
这次攻击之所以能成，是因为那个被黑的维护者账号里还留着一个长期有效的npm token。虽然项目本身已经配了GitHub的OIDC可信发布流程，但只要token还在，npm就会优先用token来认证，直接绕过了那些安全设置。
攻击者把维护者的邮箱改成了ifstap@proton.me，然后直接通过npm命令行把包发了出去。整个过程跟项目的GitHub仓库没有任何关系，所以GitHub那边根本不会有任何记录。
现在该怎么办
如果你或者你的团队用的是axios，现在需要做几件事。
1. 检查版本
看看项目里有没有axios@1.14.1或者axios@0.30.4这两个版本。
用这个命令就能看到：
npm list axios或者查看package.json里的版本号。
2. 如果装到了恶意版本怎么办
如果你发现项目里有这两个版本，需要做这几步：
立即断网，防止木马继续和黑客服务器通信
用杀毒软件全盘扫描，重点检查上面说的那几个路径
轮换所有重要的密码和密钥（特别是npm、GitHub、云服务的token）
把axios降级到安全版本：1.13.2或更早的版本
3. 长期防护建议
不要在项目里使用^或~这种模糊版本号，直接写死具体版本
考虑用npm的package-lock.json锁定所有依赖的精确版本
有条件的话，在公司内部搭一个私有npm镜像，自己审核所有包的上线
定期检查npm token的有效期，及时清理不用的token
总结
这次axios被攻击的事件，再次提醒了供应链安全的重要性。一个维护者的账号被黑，就能影响到全世界几百万个项目。
对于开发者来说，能做的就是提高警惕，尽量锁定依赖版本，定期检查安全公告。npm官方也需要重新审视token认证的优先级问题，避免类似的绕过高等级安全设置的情况再次发生。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！
