Axios 供应链攻击事件分析

2026-03-30 Axios 供应链攻击事件分析

2026 年 3 月 30 日，安全机构 StepSecurity 披露了一起 npm 供应链攻击：主流 HTTP 客户端库 Axios 的两个版本被植入了远程控制代码。开源依赖的安全问题，又一次被摆到了台面上。

事件概述

受影响版本

• axios@1.14.1
• axios@0.30.4

攻击时间线

攻击手法分析

1. 账号劫持

攻击者通过某种方式（疑似凭证泄露、钓鱼或社会工程）劫持了 Axios 核心维护者的 npm 账号，从而绕过正常的 CI/CD 流程，直接发布恶意版本。

2. 依赖投毒

恶意代码并非直接写在 axios 主包中，而是通过伪造依赖 plain-crypto-js@4.2.1 实现：

axios@1.14.1
  └── plain-crypto-js@4.2.1 (恶意包)

这种间接投毒更隐蔽：

• 主包代码看起来完全正常
• 恶意行为在安装依赖阶段就执行了
• 开发者很少会去审查传递依赖

3. 执行时机

恶意代码在 npm install 时通过 postinstall 脚本自动执行：

// plain-crypto-js/package.json
{
  "scripts": {
    "postinstall": "node setup.js"
  }
}

4. 跨平台木马

setup.js 会下载并执行针对操作系统的恶意载荷：

恶意行为详解

信息窃取

木马会收集以下敏感信息：

// 伪代码示例
const targets = [
  process.env.NPM_TOKEN,
  process.env.AWS_SECRET_ACCESS_KEY,
  process.env.GITHUB_TOKEN,
  // ... 其他环境变量
];

// 读取常见配置文件
const configFiles = [
  '~/.npmrc',
  '~/.aws/credentials',
  '~/.ssh/id_rsa',
  // ...
];

远程控制

木马会连接攻击者的 C2（Command & Control）服务器，接受远程指令：

• 执行任意命令
• 上传、下载文件
• 建立持久化后门
• 横向移动到内网其他机器

痕迹清除

执行完成后，恶意脚本会自动清除日志和临时文件，增加检测难度：

// 伪代码示例
function cleanup() {
  fs.unlinkSync('/tmp/setup.js');
  // 清除 bash history
  // 删除相关日志条目
}

检测与修复

1. 检查受影响版本

# 查看项目中 axios 版本
npm list axios

# 或使用更详细的检查
npm ls axios --depth=0

2. 立即降级到安全版本

# 卸载受影响版本
npm uninstall axios

# 安装安全版本（1.14.0 或更低）
npm install axios@1.14.0

# 或长期使用 0.30.3 及以下版本
npm install axios@0.30.3

3. 检查 package-lock.json

确保锁定文件中没有恶意版本：

# 搜索锁定文件中的恶意版本
grep -n "1.14.1\|0.30.4" package-lock.json

# 或使用 npm 的审计功能
npm audit

4. 重置敏感凭证

如果怀疑已被感染，必须立即重置：

• [ ] npm token
• [ ] GitHub/GitLab token
• [ ] AWS/云服务商密钥
• [ ] 数据库密码
• [ ] API keys
• [ ] SSH 密钥对

5. 系统安全检查

# Linux/macOS: 检查可疑进程
ps aux | grep -E "(cache|ld\.py)"

# Windows: 检查可疑进程
tasklist | findstr "wt.exe"

# 检查网络连接
netstat -ano | grep ESTABLISHED

防御策略

1. 锁定依赖版本

在 package.json 中使用精确版本号，避免自动升级：

{
  "dependencies": {
    "axios": "1.14.0"  // ✅ 精确版本
    // 而不是 "axios": "^1.14.0" ❌
  }
}

2. 启用 npm 审计

# 安装时自动审计
npm config set audit true

# CI/CD 中集成审计
npm audit --audit-level=high

3. 使用依赖锁定工具

# 使用 npm-ci 确保一致性
npm ci

# 或使用更严格的 pnpm
pnpm install --frozen-lockfile

4. 监控依赖变更

# 使用 npm-why 查看依赖来源
npm why axios

# 使用 depcheck 检查未使用依赖
npx depcheck

# 使用 npm-audit-fix 自动修复
npx npm-audit-fix

5. 最小化依赖

定期审查和清理不必要的依赖：

# 查看依赖树
npm ls --depth=0

# 移除未使用的依赖
npm uninstall unused-package

安全工具推荐

事件影响与反思

影响范围

Axios 是最流行的 HTTP 客户端库之一：

• npm 周下载量：4000 万以上
• GitHub Stars：10 万以上
• 依赖它的项目：数十万计

波及面可想而知。

供应链安全的脆弱性

这起事件暴露了 npm 生态系统的几个关键问题：

1. 维护者账号安全

   • 单点故障风险
   • 缺乏多因素认证强制要求

2. CI/CD 流程可绕过

   • 手动发布缺乏监督
   • 自动化测试可被跳过

3. 依赖链不透明

   • 传递依赖难以审查
   • postinstall 脚本自动执行

4. 响应机制滞后

   • 从发布到披露有时间差
   • 缺乏快速回滚机制

行业建议

安全社区建议采取以下措施：

1. ✅ 强制维护者启用 2FA
2. ✅ 实施发布签名和验证
3. ✅ 建立依赖行为监控系统
4. ✅ 推动包管理器沙箱化
5. ✅ 建立快速应急响应机制

总结

这起事件提醒的其实是一件老生常谈的事：

开源依赖安全不是可选项，是必选项。

落到日常开发上：

1. 保持警惕：定期检查依赖的安全状况
2. 最小依赖：只装真正需要的包
3. 锁定版本：别让依赖自动升到未知版本
4. 关注变更：留心里程碑版本的更新日志
5. 快速响应：出了漏洞第一时间修

安全是持续动作，不是一次性任务。用开源的便利，就得担起对应的责任。

参考资料

• StepSecurity Security Advisory
• npm Security Advisories
• Snyk Vulnerability DB
• Socket Security Blog