Axios 对 NPM 的攻击注入了 RAT 并危害了数千名开发人员

流行的 Axios 库在许多 JavaScript 项目中用于执行 HTTP 请求，它记录了一次供应链攻击，该攻击破坏了 NPM 注册表中发布的两个特定版本。 StepSecurity 调查人员将 1.14.1 和 0.30.4 版本确定为恶意版本，发布于 2026 年 3 月 31 日凌晨。这些软件包注入了一个虚假的依赖项，该依赖项运行一个能够在开发人员计算机上安装远程访问木马的安装脚本。

该事件暴露了依赖该库的庞大开发生态系统，该库是该平台上下载量最大的库之一，每周下载量超过 1 亿次。攻击者没有更改 Axios 核心代码，而是添加了一个名为 plain-crypto-js@4.2.1 的隐藏依赖项。运行 npm install 时，此依赖项会自动激活，为 Windows、macOS 和 Linux 安装特定的有效负载。

维护账户是如何被泄露的

负责这次攻击的人获得了该项目主要维护者（jasonsaayman）的 NPM 帐户的访问权限。他们将关联的电子邮件地址更改为ifstap@proton.me并手动发布受损版本，绕过 GitHub 上存储库的自动持续集成流程。第一个恶意版本 axios@1.14.1 于世界标准时间 00:21 左右发布，大约 39 分钟后发布了 axios@0.30.4。

这种方法允许在不触发签名检查或通常的 CI/CD 流程的情况下提供包。 Axios 维护者发现后迅速做出反应，NPM 在数小时内删除了这两个版本，将暴露时间限制在大约两到三个小时。

⚡ 警告 – Axios npm（每周 8300 万次下载）遭到破坏，将安装变成恶意软件传播路径。

1.14.1 和 0.30.4 版本提取了一个虚假依赖项，该依赖项丢弃了跨平台 RAT，然后删除了证据。使用被盗的维护者凭据发布。

🔗 什么…pic.twitter.com/rBTiPGZmbr

— 黑客新闻 (@TheHackersNews)2026 年 3 月 31 日

注入恶意软件的技术细节

原始 Axios 代码中的任何时候都没有导入伪造的依赖项 plain-crypto-js@4.2.1，它专门用于执行安装后脚本。该脚本充当远程访问木马植入程序，与命令和控制服务器建立联系，以下载针对每个操作系统定制的其他有效负载。

混淆技术用于使立即分析变得困难，命令在运行时解码。成功安装后，恶意软件删除了自己的痕迹，用干净的版本替换 package.json 文件，以避免在以后检查 node_modules 文件夹时检测到。

• 使用 npm list axios 命令过滤 1.14.1 或 0.30.4 检查受影响的版本
• 检查 node_modules/plain-crypto-js 文件夹是否存在作为妥协的指标
• 搜索工件，例如 /tmp/ld.py 中的临时文件或其他系统上的等效文件

建议开发商采取的缓解措施

安装版本 1.14.1 或 0.30.4 的开发人员应考虑环境受到损害并立即采取行动。主要建议是恢复到以前的安全版本：最新分支中的 axios@1.14.0 或旧版本中的 axios@0.30.3 。

必须删除虚假依赖项，使用 –ignore-scripts 标志执行全新安装，并轮换所有敏感凭据，包括 NPM 令牌、SSH 密钥、云服务访问和环境变量。在持续集成管道中，永久采用忽略安装后脚本的参数有助于防止不必要的自动执行。

Leia Tambem

新的电池测试使 Galaxy S26 Ultra 在全球排名中领先于 iPhone 17 Pro Max

三星为 Galaxy Watch 4 用户发布新系统更新和新功能

数字零售通过银行奖金和设备交换降低了 Galaxy S25 5G 智能手机的价值

对 JavaScript 开发生态系统的影响

Axios 是 Node.js 生态系统和前端应用程序中最常用的库之一，是众多企业和开源项目的直接或间接依赖项。该攻击凸显了高度流行的软件包中个人维护者帐户的固有漏洞，即使核心代码保持完整也是如此。

安全专家指出，所使用的方法展示了操作的复杂性，在注入恶意有效负载之前，在干净版本中预先准备了错误依赖项。这种策略使初始自动检测变得复杂，并在版本可用的短时间内增加了风险。

检查和清洁受影响环境的指南

开发团队需要审核安装日志和软件包历史记录，以确定是否下载了恶意版本。 node_modules 中的 plain-crypto-js 文件夹的存在是一个强有力的指标，表明释放器已被执行，无论稍后文件是否被删除。

清理后，建议使用威胁检测工具全面扫描系统，并监控与控制服务器关联的地址的网络连接。立即更新私有存储库中的安全策略也有助于减少其他软件包中的类似风险。

防止未来对数据包日志的攻击

该事件凸显了对发布帐户进行严格的多因素身份验证、持续监控包元数据更改以及采用更强大的完整性检查等措施的重要性。采用率高的开源项目可能会在新版本发布之前考虑额外的审核流程。

个人开发人员和公司应优先考虑在项目配置文件中固定已知的安全版本，避免在未经事先验证的情况下自动安装更新。这些做法有助于限制软件供应链中的攻击面。

安全社区将继续监控此案，以绘制可能的受害者地图并完善检测工具。迄今为止，还没有大规模利用的公开报告，但一致建议是将受影响版本的任何安装视为对所涉及系统的完全妥协。