1.14亿周下载量库被投毒：攻击者39分钟完成全球部署

3月30日，JavaScript生态的"水电煤"出了事。Axios——这个每周被下载超过1亿次的HTTP请求库——被攻击者劫持，39分钟内连发两个恶意版本，Windows、macOS、Linux开发者无一幸免。

一个邮箱的失守

攻击起点是项目负责人Jason Saayman的npm账户。入侵者没费多大劲，把账户绑定的邮箱换成ProtonMail地址，就拿到了管理员权限。

npm的账户安全机制在这里露出了尴尬的一面：邮箱变更没有触发足够强度的二次验证，一个被盗的访问令牌（access token）就让攻击者绕过了所有防线。这个令牌被用来手动发布axios@1.14.1和axios@0.30.4，前后相隔39分钟，分别覆盖了当前主版本和遗留分支。

两个版本在官方GitHub仓库里找不到任何对应的提交记录、标签或发布说明。这是供应链攻击的经典信号——代码从未经过正常的CI流程，直接出现在了注册表上。

Trend Micro的研究员Peter Girnus和Jacob Santos在事后分析中发现，攻击者甚至没把GitHub Actions的OIDC可信发布机制放在眼里。这套机制本该把npm发布绑定到验证过的CI工作流，但手动发布配合被盗令牌，让加密绑定和gitHead引用统统失效。

幽灵依赖的魔术

恶意代码的藏身之处叫plain-crypto-js@4.2.1。这是个"幽灵依赖"——Axios的86个源文件里没有任何地方导入或引用它，但它被写进了package.json的依赖清单。

npm的包管理器有个特性：postinstall钩子会在安装完成后自动执行。攻击者利用这一点，让plain-crypto-js在安装时悄悄释放一个跨平台远程访问木马（RAT）。

整个过程像一场精心排练的魔术。setup.js作为投递器（dropper），先用两层混淆系统骗过自动化扫描器：外层反转编码字符串、修复base64填充，内层用"OrDeR_7077"作为密钥的自定义XOR加密，配合二次方索引模式打乱字符访问顺序。

木马执行后，投递器脚本自我删除，原地换上一个干净的替身文件。node_modules文件夹看起来毫无异常，开发者很难察觉自己刚刚装了个后门。

攻击时间线被压缩到18小时左右：先发布一个干净的plain-crypto-js版本建立注册表历史，避免触发"新包异常"警报；几小时后注册命令控制服务器；最后推送恶意载荷。每一步都踩着npm生态的信任机制走。

谁中了招

Trend Micro的遥测数据显示，攻击窗口期内已有活跃利用确认。受影响组织横跨政府、金融、医疗、制造、零售和科技六个行业——基本上覆盖了所有用JavaScript写后端的地方。

Axios的地位让这次攻击的潜在杀伤面极其夸张。它不是某个小众框架，而是Node.js项目里调用API的事实标准。从初创公司的内部工具到财富500强的核心系统，依赖链上 somewhere 都可能挂着axios。

供应链攻击的恶心之处就在这里：你信任的是A，中枪的是B，而B可能在你代码的第三层依赖里。开发者运行npm install时，很少有人会逐行检查node_modules里多了什么。

这次事件暴露了两个结构性问题。一是npm账户的安全模型——邮箱变更+访问令牌就能劫持千万级下载量的项目，这个门槛是否太低？二是幽灵依赖的检测盲区——一个从未被代码引用的包，凭什么能随着主包一起安装并执行任意脚本？

善后与未解

npm方面在发现后下架了恶意版本，但下载量已经产生。企业安全团队现在面临一个头疼的问题：如何确定自己的依赖树里是否曾出现过这两个版本？

lock文件能锁定版本号，但无法阻止已经发生的安装。如果开发者在3月30日之后、下架之前执行过npm install或ci，恶意代码可能已经躺在某台构建服务器的磁盘里，甚至被打包进了部署镜像。

Jason Saayman的账户现已收回，但攻击者如何拿到初始访问权限——是钓鱼、凭证泄露还是其他渠道——尚未公开。npm的令牌审计日志能提供多少线索，也是个未知数。

这次攻击的完整技术细节已由Trend Micro发布，包括IoC（入侵指标）和检测规则。但对于大多数开发者来说，更现实的教训可能是：下次运行npm install之前，你的供应链安全检查清单上该加几项了？