Axios npm 投毒事件:依赖安装为什么已经是一种远程代码执行

2026 年 3 月末,安全团队发现 npm 上出现了两个被投毒的 Axios 版本:1.14.10.30.4。攻击者没有把恶意逻辑直接写进 Axios 源码,而是通过被劫持的维护者账号发布版本,加入一个伪装依赖,再利用 postinstall 脚本投放面向 macOS、Windows 和 Linux 的远程访问木马。

Axios 是 JavaScript 生态最常见的 HTTP 客户端之一。事件被迅速处置,相关版本只存活了数小时,却仍在 Hacker News 获得接近两千分讨论。它暴露了一个长期被低估的事实:执行一次依赖安装,本质上是在允许互联网上的一组发布者运行代码。

恶意代码为什么不在 Axios 里

据 StepSecurity 的事件分析,攻击者向两个 Axios 版本加入了 plain-crypto-js@4.2.1 依赖。这个包复制了合法 crypto-js 的大量文件,真正危险的部分藏在 package.jsonpostinstall 和一个经过混淆的 setup.js 中。

npm 安装依赖时会自动执行生命周期脚本,因此 Axios 业务代码甚至不需要 import 这个包。只要依赖解析并安装完成,脚本就已经能够访问当前用户权限下的文件、网络和凭证。

这种间接注入还有一个优势:审查者如果只比较 Axios 的 JavaScript 源码,很可能找不到恶意逻辑。危险发生在依赖图和安装阶段,而不是日常关注的请求函数里。

攻击者还试图抹掉安装后的证据

恶意包会联系命令控制服务器,按操作系统下载第二阶段载荷。执行后,它还会删除自身脚本,并用事先准备的干净 package.json 覆盖原文件,把本地显示的版本伪装成无害版本。

这意味着事故发生后再运行 npm list,未必能还原安装当时的真实状态。一个会主动修改证据的安装脚本,让“看看 node_modules 里现在有什么”失去可靠性。

更可信的证据应该来自不可变的 lockfile、包管理器缓存、代理仓库日志、CI 网络事件和构建制品哈希。供应链取证不能只依赖已经运行过不可信代码的机器。

发布身份出现了哪些异常

正常的 Axios 版本使用 npm Trusted Publisher,由 GitHub Actions 通过短期 OIDC 身份发布。恶意版本却由维护者账号和长期令牌手工发布,没有对应的 Git 提交、标签和 gitHead,发布者元数据也偏离了项目以往模式。

这些信号单独看都不一定证明攻击,组合起来却非常异常:

  • 仓库中没有对应 tag,npm 却出现了新版本;
  • 一贯由 CI 发布的包突然变成人工账号发布;
  • 新增依赖没有被源码实际导入,却带有安装脚本;
  • 安装过程访问历史上从未出现的外部域名。

安全检测如果只扫描代码中的已知恶意字符串,很容易错过这种攻击。发布路径和运行行为同样需要建立基线。

如果装过恶意版本,不能只降级

一旦安装脚本已经运行,把 Axios 改回安全版本只会阻止下一次执行,不能撤回已经下载的载荷。更稳妥的处理是把设备或 CI runner 视为已失陷:断开网络、保存独立日志、从可信镜像重建环境,并轮换机器能够访问的 npm、GitHub、云平台和部署凭证。

开发机的风险尤其容易被低估。它通常同时保存源码、SSH Key、浏览器会话、云凭证和生产访问入口,对攻击者可能比一台隔离服务器更有价值。

团队可以补上的五道防线

第一,提交并严格使用 lockfile,依赖更新通过单独 PR 完成,避免构建时静默漂移到最新版本。

第二,优先使用 Trusted Publisher 和短期 OIDC,逐步删除可长期复用的发布令牌,并对发布身份变化告警。

第三,对安装脚本建立策略。能禁用时使用 --ignore-scripts;确实需要脚本的包进入白名单,并审查版本变化。

第四,限制开发与 CI 环境的出站网络。正常构建访问哪些域名应该可见,新出现的命令控制地址才有机会在载荷执行后的几秒内被发现。

第五,把注册表制品与源码仓库交叉验证。tag、commit、provenance、哈希和发布者身份应当互相支持,任何“只有 npm 上存在”的版本都值得暂停。

我的理解:包管理器也是执行引擎

我们习惯把 npm install 当作下载文件,却忽略了包管理器同时拥有脚本执行、依赖递归和网络访问能力。依赖越方便,信任传递得越深;顶层只增加一个包,实际授权的维护者可能有数百个。

Axios 事件与 xz 后门采用了不同路线,却指向同一问题:现代软件的攻击面不仅是自己写的代码,还包括谁能够发布依赖、构建过程执行了什么,以及异常发生时有没有独立证据。

真正成熟的供应链安全,不是要求开发者逐行审计整个互联网,而是把安装和发布当成高权限操作,用可复现、最小权限、短期身份与行为监控把信任限制在可检查的范围内。

参考资料

本文是 2026 年 8 月整理断更期时写下的回顾,发布日期按事件所处阶段归档。

文章目录
  1. 1. 恶意代码为什么不在 Axios 里
  2. 2. 攻击者还试图抹掉安装后的证据
  3. 3. 发布身份出现了哪些异常
  4. 4. 如果装过恶意版本,不能只降级
  5. 5. 团队可以补上的五道防线
  6. 6. 我的理解:包管理器也是执行引擎
  7. 7. 参考资料
|