Axios 惊现恶意版本：一场针对前端生态的精准供应链攻击
2026年3月30日，一场针对前端生态的“地震”发生了。作为每周下载量超亿次、最为主流的HTTP客户端库，Axios被曝出在npm官方仓库中植入了两个恶意版本：axios@1.14.1 和 axios@0.30.4。这可不是普通的安全漏洞，而是一场精心策划、极高危的软件供应链攻击。
攻击事件示意图
核心攻击方式：一场教科书式的“隐秘行动”
先来看攻击是如何实施的。整个过程可谓环环相扣，极具迷惑性，堪称供应链攻击的“教科书案例”。
第一步：维护者账号被盗。 攻击者直接盗取了Axios核心维护者的npm账号。这意味着，恶意版本是由合法账号发布，完全绕过了最新的CI/CD安全检查流程。这些版本没有对应的合法Git提交记录，也没有经过OIDC校验，仅凭肉眼查看npm页面，极难区分真伪。
第二步：植入“幽灵依赖”。 这两个恶意包本身对Axios源码的修改微乎其微，仅在package.json中偷偷加入了一个名为plain-crypto-js@4.2.1的依赖项。蹊跷之处在于，这个包在Axios的源码中完全没有被引用。它的唯一使命，就是触发postinstall这个安装后钩子脚本——木马执行的起点。
第三步：部署跨平台远控木马。 plain-crypto-js包内携带了一个经过混淆的恶意脚本setup.js，在安装时会自动执行。这个脚本的能力相当全面：
- 自动识别macOS、Windows或Linux系统；
- 连接攻击者的C2（命令与控制）服务器
sfrclak.com:8000； - 下载对应的攻击载荷（Payload）；
- 窃取本地密钥、SSH凭证、云服务凭据、环境变量等一切敏感信息。
第四步：极强的反侦察“擦除”能力。 这才是整个攻击链最令人警觉的地方。木马执行后，会立刻进行“自我销毁”：不仅删除自身，还会将package.json替换回一个干净的版本。事后再用npm list检查，显示的将是完全正常的版本号，几乎不留痕迹。唯一的物理证据，就是node_modules目录下是否残留着plain-crypto-js这个文件夹。它的存在，就等于系统中招的铁证。
受影响版本：立即核对你的依赖树
以下是明确的版本清单，请务必仔细核对：
- 有毒版本（立即处理）：
axios@1.14.1、axios@0.30.4、plain-crypto-js@4.2.1 - 安全版本（可回退至）：
axios@1.14.0、axios@0.30.3
前端自查命令：一分钟快速诊断
打开你的项目终端，执行以下命令，快速排查风险：
# 检查是否安装了恶意版本的Axios
npm list axios | grep -E “1\.14\.1|0\.30\.4”
# 检查项目中是否存在恶意的依赖目录
ls node_modules/plain-crypto-js紧急修复步骤：按顺序操作，杜绝后患
如果发现中招，请立即按以下步骤处理：
- 立即降级至安全版本。
# 主流版本用户 npm install axios@1.14.0 # 仍在使用旧版的用户 npm install axios@0.30.3 - 在
package.json中精确锁定版本，避免后续依赖升级时再次引入风险。 - 物理删除恶意依赖目录。
rm -rf node_modules/plain-crypto-js - 加固CI/CD流程。 建议在构建命令中增加
—ignore-scripts参数，全局禁用安装钩子脚本，从根本上阻断此类攻击途径。 - 进行安全评估。 如果机器已经执行过恶意包，必须假设所有密钥和凭证均已泄露。需要立即轮换所有相关的密钥、令牌，在极端情况下，甚至应考虑重置或重装开发环境。
高危提醒：这不是演习
必须警惕的是，此次攻击的精准度和隐蔽性都达到了极高水准。从依赖安装到外联控制，整个过程可能仅在数秒内完成。无论是前端项目、开发者本地机器，还是集成了npm安装的CI/CD流水线，都面临着严重的敏感信息泄露风险。时间紧迫，尽快排查，刻不容缓。
