近期，全球最流行的JavaScript HTTP客户端库Axios遭遇了严重的供应链攻击，攻击者通过入侵官方维护者账号发布了两个携带恶意代码的版本（axios@1.14.1和axios@0.30.4），这一事件在开发者社区引发了广泛关注。本文将全面剖析此次攻击的技术细节、影响范围、风险等级以及应对措施，帮助开发者和企业有效规避潜在威胁。

事件概述：一场精心策划的供应链攻击

2026年3月30日至31日，攻击者通过盗取的Axios维护者npm账号（jasonsaayman），绕过了GitHub Actions CI/CD保护机制，手动发布了两个恶意版本axios@1.14.1与axios@0.30.4。这两个版本并未直接修改Axios的核心代码，而是通过注入隐藏依赖plain-crypto-js@4.2.1的方式植入后门。

攻击时间线显示：

• 3月30日23:59:12：攻击者预先注册恶意域名sfrclak.com并发布恶意依赖包plain-crypto-js@4.2.1
• 3月31日00:00左右：利用被盗账号发布axios恶意版本
• 3月31日00:05:41：安全平台Socket.dev自动化检测发现异常包
• 3月31日04:00:00：npm官方下架恶意包

值得注意的是，作为全球周下载量达1.5亿次的基础库，Axios被广泛应用于从React前端到CI/CD工具，再到服务器端API的各类场景中，这使得此次攻击的潜在影响面极为广泛。

攻击技术细节：高度隐蔽的多平台木马

攻击者采用了供应链投毒的经典手法，但在技术实现上展现了高度的专业性和隐蔽性：

1. 依赖注入：恶意axios版本在package.json中引入了伪装的加密库plain-crypto-js@4.2.1，该包名仿冒了热门加密库crypto-js

2. 后门机制：plain-crypto-js通过postinstall钩子脚本执行恶意代码，其setup.js文件经过高度混淆，能够：

   • 检测运行主机平台（Windows、Linux或macOS）
   • 从攻击者控制的C2服务器（http://sfrclak.com:8000/6202033）下载对应平台的恶意载荷
   • 将载荷写入系统临时目录并通过Shell/PowerShell执行
   • 自动销毁痕迹，增加事后审计难度

3. 多平台攻击：恶意载荷针对不同操作系统设计了不同的持久化方式：

   • Windows：在%PROGRAMDATA%目录下植入wt.exe
   • macOS：在/Library/Caches/下创建com.apple.act.mond
   • Linux：在/tmp/目录下生成ld.py脚本

4. 隐蔽性设计：攻击者刻意避开了直接修改Axios核心代码的方式，而是通过依赖链引入恶意包，这种"间接攻击"模式大大降低了被常规安全检查发现的概率。

影响范围与风险等级

受影响版本

• 恶意版本：axios@1.14.1、axios@0.30.4
• 恶意依赖：plain-crypto-js@4.2.1（已被npm官方下架）

安全版本

• axios ≤0.30.3
• axios ≤1.14.0
• axios >0.30.4
• axios >1.14.1

风险等级：高风险

此次攻击的特殊性在于：

1. 自动化传播：通过npm的依赖解析机制自动扩散，开发者只需执行常规的npm install或update命令就可能中招
2. 权限提升：AI编程工具（如Claude Code、Codex CLI等）通常具有较高的系统权限，若通过这些工具安装axios恶意版本，木马将获得更多操作权限
3. 隐蔽性强：恶意代码执行后会自我删除，常规审计难以发现

特别值得关注的是，OpenClaw生态在特定场景下可能受到影响：

• 源码构建场景：不受影响（锁文件固定为axios@1.13.5/1.13.6）
• 全局安装场景：npm install -g openclaw@2026.3.28在攻击窗口期内可能解析到axios@1.14.1

自查与修复方案

自查方法

1. 版本检测：

# 检测本地axios恶意版本
npm list axios | grep -E "1\.14\.1|0\.30\.4"
npm list -g axios | grep -E "1\.14\.1|0\.30\.4"

# 检测恶意依赖
ls node_modules/plain-crypto-js

2. 系统痕迹检测：

# macOS
ls -la /Library/Caches/com.apple.act.mond

# Linux
ls -la /tmp/ld.py

# Windows
dir "%PROGRAMDATA%\wt.exe"

3. 网络连接检查：
   排查是否有对sfrclak.com域名的连接记录

修复建议

1. 立即降级axios：

# 卸载恶意版本
npm uninstall axios
npm uninstall -g axios

# 安装安全版本
npm install axios@1.14.0
npm install -g axios@1.14.0

2. 清理恶意组件：

# 删除恶意依赖
rm -rf node_modules/plain-crypto-js

# 清理npm缓存
npm cache clean --force

# 安全重装（阻止postinstall脚本执行）
npm ci --ignore-scripts

3. 系统级清理：

• Linux/macOS：

  # 删除恶意文件
  rm -f /tmp/ld.py /Library/Caches/com.apple.act.mond
  
  # 检查持久化项
  crontab -l | grep -i "sfrclak"
  grep -r "sfrclak.com" ~/.bashrc ~/.zshrc /etc/cron*

• Windows（管理员权限）：

  # 删除恶意文件
  Remove-Item "$env:PROGRAMDATA\wt.exe" -Force
  
  # 检查计划任务
  Get-ScheduledTask | Where-Object {$_.TaskName -like "*wt*"} | Unregister-ScheduledTask -Confirm:$false

4. 凭证轮换：
   立即更换所有可能泄露的敏感凭证，包括：

• npm发布Token
• SSH私钥
• 云服务凭据（AWS/GCP/Azure）
• CI/CD Secrets（GitHub/GitLab/Jenkins）
• 环境变量中的各类API密钥

深层思考：供应链安全的新挑战

Axios投毒事件揭示了现代软件开发中几个关键的安全问题：

1. 信任边界模糊化：开发者对主流开源项目的盲目信任成为攻击突破口
2. 工具链风险传导：AI编程工具自动引入依赖的行为扩大了攻击面
3. 响应时效困境：从攻击发生到官方下架存在数小时的时间窗口，这段时间内的安装行为无法挽回

防御性开发建议

1. 依赖管理最佳实践：

   • 锁死版本号（避免使用^和~）
   • 定期执行npm audit
   • 设置npm config set ignore-scripts true阻止postinstall脚本执行

2. CI/CD安全加固：

   • 对npm install使用--ignore-scripts参数
   • 在构建管道中集成依赖扫描工具（如Socket.dev）

3. 企业级防护措施：

   • 搭建私有npm镜像，所有公共包需经审核后同步
   • 开发环境网络隔离，限制对外连接

结语

Axios供应链投毒事件再次敲响了软件供应链安全的警钟。在开源生态日益复杂的今天，任何一环的失守都可能导致灾难性的连锁反应。开发者需要从被动响应转向主动防御，通过最小权限原则、深度验证机制和零信任架构构建多层次防护体系。

正如安全专家所言："没有绝对安全的软件，只有不断提高的安全意识与防御能力"。此次事件不应仅被视为一次孤立的安全事件，而应作为整个行业反思和改进的契机，推动建立更加健壮、透明的供应链安全生态。