你的AI助手可能正在被远控:Axios供应链投毒事件全解析

核心摘要：2026年3月31日，全球最受欢迎的 JavaScript HTTP 客户端库 Axios 遭遇精密供应链攻击。攻击者劫持维护者账户，发布两个恶意版本（1.14.1 和 0.30.4），通过隐蔽依赖注入跨平台远控木马（RAT）。该事件影响范围覆盖每周超过 1 亿次下载的 npm 生态，Claude Code 等知名 AI 编程工具也受到影响。

一、Axios 是什么？

Axios 是一个基于 Promise 的 HTTP 客户端库，支持浏览器和 Node.js 环境。它提供了简洁易用的 API，支持请求/响应拦截、自动转换 JSON 数据、取消请求、CSRF 防护等特性。

关键数据：

• GitHub 星标数超过 10.9万
• npm 每周下载量超过 1亿次
• 是 JavaScript 生态中使用最广泛的 HTTP 客户端库
• 被大量知名项目依赖，包括各类前端框架、后端服务、CLI 工具和 AI 编程助手

由于其极高的普及率和作为底层依赖的广泛性，Axios 一旦遭到供应链攻击，影响面将极为惊人。

二、事件来龙去脉

2.1 攻击时间线

恶意版本在 npm 上存活仅约 2-3 小时，但足以造成广泛影响。

2.2 攻击手法解析

这次攻击被安全研究人员称为 “近年来针对 npm 前十大包最精密的供应链攻击之一”，其手法之精巧令人警惕：

第一步：劫持维护者账户

攻击者成功入侵了 axios 主要维护者 jasonsaayman 的 npm 账户，并将注册邮箱更改为攻击者控制的 ProtonMail 地址（ifstap@proton.me）。利用此权限，攻击者绕过了项目正常的 GitHub Actions CI/CD 发布流程，直接使用窃取的 npm 访问令牌发布恶意版本。

一个关键的取证信号是：所有合法的 axios 1.x 版本都通过 GitHub Actions 使用 npm 的 OIDC 可信发布机制发布，而 axios@1.14.1 完全打破了这一模式——没有 OIDC 绑定，没有对应的 GitHub 提交或标签，仅存在于 npm 仓库中。

第二步：预置恶意依赖包

攻击者并非临时起意，而是进行了精密的预置：

• 提前 18 小时发布 plain-crypto-js@4.2.0（干净版本），伪装成合法的 crypto-js 库
• 该包包含了完整的 crypto-js 源代码（56个加密源文件与原版逐字节相同），唯一的区别是在 package.json 中添加了 "postinstall": "node setup.js"
• 预置干净的 package.md 文件，用于执行后擦除证据

第三步：注入”幽灵依赖”

在 axios@1.14.1 和 axios@0.30.4 的 package.json 中，攻击者仅做了一处实质性修改：添加了 "plain-crypto-js": "^4.2.1" 作为运行时依赖。

令人震惊的是：axios 源码中没有任何一行代码引用或导入这个包。它被添加到 package.json 的唯一目的就是触发 postinstall 钩子。一个在清单文件中出现但在代码库中零使用的依赖，是发布被劫持的高置信度指标。

第四步：RAT 投放器执行

当开发者运行 npm install 时，npm 会自动安装 plain-crypto-js@4.2.1 并执行其 postinstall 脚本 setup.js。这个经过两层混淆的 Node.js 脚本是一个跨平台远控木马投放器，针对 macOS、Windows 和 Linux 三个平台分别投放不同的第二阶段载荷：

• macOS：通过 AppleScript 下载 RAT 到 /Library/Caches/com.apple.act.mond（伪装成 Apple 系统缓存），赋予执行权限后通过 zsh 启动
• Windows：将 PowerShell 复制到 %PROGRAMDATA%\wt.exe（伪装成 Windows Terminal），通过 VBScript 隐藏执行第二阶段载荷
• Linux：通过 curl 下载 Python RAT 脚本到 /tmp/ld.py 并在后台执行

第五步：自我清理，销毁证据

执行完毕后，setup.js 会执行三步反取证操作：

1. 删除自身（setup.js）
2. 删除包含 postinstall 脚本的 package.json
3. 将预置的干净 package.md 重命名为 package.json（版本号伪造成 4.2.0）

这意味着事后检查 node_modules/plain-crypto-js/package.json 时，看到的是一个完全干净的清单文件。运行 npm audit 也不会发现任何异常。唯一的持久证据就是 node_modules/plain-crypto-js/ 目录本身的存在——因为这个包从未出现在任何合法的 axios 版本中。

2.3 攻击的精密之处

1. 零行恶意代码在 axios 本身：完整的二进制对比显示，axios@1.14.0 和 axios@1.14.1 之间仅有 package.json 一个文件不同，其余 85 个文件逐字节相同
2. 静默失败设计：整个投放器被包裹在 try/catch 中，任何错误都被静默吞掉，npm install 始终返回退出码 0
3. 反取证版本伪装：清理后的 package.json 报告版本 4.2.0 而非 4.2.1，导致事后运行 npm list 时显示的是”安全”版本号
4. C2 流量伪装：网络请求的 POST body 使用 packages.npm.org/productX 前缀，试图在网络日志中伪装成正常的 npm 通信
5. 预置时间差：恶意依赖提前 18 小时发布，避免”全新包”触发安全扫描器告警

三、影响版本

恶意版本（必须立即移除）

安全版本

C2 指标（IOC）

四、影响应用

4.1 影响范围

Axios 每周下载量超过 1 亿次，是 npm 生态中使用最广泛的 HTTP 客户端库。任何直接或间接依赖 axios 的项目都可能受到影响，包括但不限于：

• 前端框架项目：Vue、React、Angular 等生态中的大量工具库
• 后端服务：基于 Node.js 的 API 服务、微服务
• CLI 工具：各类开发者命令行工具
• CI/CD 流水线：自动化构建和部署流程
• AI 编程助手：多个知名 AI 编程工具依赖 axios 进行网络通信

4.2 Claude Code 受影响情况

Anthropic 的 AI 编程工具 Claude Code 被确认依赖 axios。在 GitHub 上已有用户提交 Issue（anthropics/claude-code #41547）询问受影响情况。由于 Claude Code 在开发者的终端环境中运行并拥有对代码库和文件系统的广泛访问权限，如果被投毒版本在 CI/CD 或本地环境中执行，攻击者获取的远控权限将极为危险。

4.3 OpenClaw 事件关联

慢雾创始人余弦在X平台发文称，如果用户使用的是最新版本3.28的OpenClaw，可能会引入带毒版本的axios，建议用户立即排查。此外，不仅OpenClaw直接引入，相关Skills也可能因依赖axios而间接被投毒。

4.4 其他受影响项目

安全公司 StepSecurity 在其 Harden-Runner 产品中检测到，知名开发者门户框架 Backstage 的 CI 流水线中也出现了连接 C2 域名 sfrclak.com:8000 的异常网络请求。Backstage 团队确认该工作流是沙箱化的，恶意包安装未对项目造成实际影响。

五、排查方法

5.1 检查项目依赖

方法一：使用 npm 命令

# 检查当前项目是否安装了受影响版本npm list axios# 检查 package-lock.jsongrep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"# 检查是否存在 plain-crypto-js（关键指标）ls node_modules/plain-crypto-js 2>/dev/null && echo"可能存在风险"

方法二：GitHub 代码搜索

在 GitHub 组织级别搜索（将 <YOUR_ORG> 替换为你的组织名）：

• 搜索 org:<YOUR_ORG> "axios" "1.14.1" path:package-lock.json
• 搜索 org:<YOUR_ORG> "axios" "0.30.4" path:package-lock.json
• 搜索 org:<YOUR_ORG> "plain-crypto-js" path:package-lock.json（存在即为确凿的入侵指标）

方法三：全局扫描

# 递归搜索用户目录下所有 node_modules 中的 plain-crypto-jsfind ~ -type d -name "plain-crypto-js" -path "*/node_modules/*" 2>/dev/null# 搜索所有 package-lock.json 中的受影响 axios 版本find ~ -name "package-lock.json" -exec grep -l "axios.*1\.14\.1\|axios.*0\.30\.4" {} \; 2>/dev/null# 检查全局安装的 npm 包npm list -g axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

5.2 检查 RAT 残留文件

macOS：

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo"已遭入侵"

Windows：

dir "%PROGRAMDATA%\wt.exe" 2>nul && echo "已遭入侵"

Linux：

ls -la /tmp/ld.py 2>/dev/null && echo"已遭入侵"

5.3 检查网络日志

如果你有企业代理、防火墙、DNS 过滤解决方案或 EDR 系统，搜索以下指标：

• 域名：sfrclak.com
• IP：142.11.206.73
• 端口：8000

任何从开发者机器或 CI 运行器到这些指标的出站连接都确认 RAT 投放器已成功执行。

5.4 检查 CI/CD 流水线

审查 CI/CD 流水线日志，查找在恶意版本存活期间（约 2026-03-31 00:21 UTC 至 03:15 UTC）执行 npm install 或 npm ci 的记录，搜索输出中是否包含 axios@1.14.1、axios@0.30.4 或 plain-crypto-js。

六、修复建议

6.1 立即修复

1. 降级到安全版本

# 1.x 用户npm install axios@1.14.0# 0.x 用户npm install axios@0.30.3

2. 在 package.json 中添加覆盖规则

防止传递依赖解析回恶意版本：

{"dependencies":{"axios":"1.14.0"},"overrides":{"axios":"1.14.0"},"resolutions":{"axios":"1.14.0"}}

3. 清理并重新安装

# 删除恶意依赖目录rm -rf node_modules/plain-crypto-js# 使用 --ignore-scripts 重新安装（防止再次触发 postinstall）npm install --ignore-scripts# 或直接删除整个 node_modules 后重新安装rm -rf node_modules package-lock.jsonnpm install

6.2 安全加固

1. 更换所有凭据

如果确认安装了恶意版本，假设该系统已被入侵，立即更换所有在安装时可访问的凭据：

• 环境变量和 .env 文件中的密钥
• CI/CD 流水线中的 secrets
• 云服务令牌（AWS、GCP、Azure 等）
• SSH 密钥和 API 密钥
• 数据库凭据

2. 封禁 C2 通信

# 在 /etc/hosts 中添加echo'0.0.0.0 sfrclak.com' | sudotee -a /etc/hosts# macOS 防火墙规则echo'block drop out quick to 142.11.206.73' | sudo pfctl -ef -# Linux iptables 规则sudo iptables -A OUTPUT -d 142.11.206.73 -j DROP

3. 审计日志

检查安装时间点前后是否有对 sfrclak.com:8000 的出站调用。

6.3 长期防护

1. 启用 npm 安全最佳实践

• 在 CI 中启用 npm audit（npm audit --audit-level=high）
• 在生产构建中使用 npm ci 保证锁文件完整性
• 为所有 npm 发布账户启用 2FA
• 优先使用 OIDC 可信发布机制（Trusted Publishing），避免使用长期有效的 npm 访问令牌

2. 锁定依赖版本

避免使用 ^ 或 ~ 等范围版本符，精确锁定版本号：

{"dependencies":{"axios":"1.14.0"}}

3. 使用安全扫描工具

考虑引入自动化安全扫描工具，如：

• StepSecurity Harden-Runner（GitHub Actions 安全增强）
• Socket.dev（npm 包安全分析）
• Snyk / Dependabot（依赖漏洞扫描）

4. 隔离持久化 CI 运行器

如果使用自托管 CI 运行器，将其视为开发者机器进行安全管理。一旦检测到受影响，隔离机器、清点凭据、重新格式化并从已知良好状态重建。

七、总结

Axios 供应链投毒事件是 2026 年迄今为止最精密的 npm 生态攻击之一。攻击者展现出的高度专业性——从账户劫持、依赖预置、跨平台 RAT 投放到完善的反取证清理——表明这并非随机偶发攻击，而是经过精心策划的定向行动。

对于开发者和安全团队而言，这次事件再次敲响了警钟：

1. 开源供应链安全不容忽视：一个被劫持的维护者账户就可以影响数百万开发者
2. postinstall 脚本是高危攻击面：任何 npm 包都可以在安装时执行任意代码
3. OIDC 可信发布是重要防线：此次攻击之所以能成功，正是因为攻击者窃取了传统的长期 npm 令牌而非 OIDC 令牌
4. 纵深防御是关键：版本锁定、锁文件完整性检查、CI 安全扫描、网络监控缺一不可

参考资料：

• StepSecurity: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan