Axios 供应链投毒全解析与企业长效防御体系建设

事情从 OpenClaw 开始说起

昨天上午,大量正在使用 OpenClaw 的开发者和安全工程师陆续收到预警:

在北京时间今天上午 8:00–12:00 期间正常安装或更新 OpenClaw 的用户,可能已被动植入跨平台 RAT 远控木马。

图片

在北京时间今天上午 8:00–12:00 期间正常安装或更新 OpenClaw 的用户,可能已被动植入跨平台 RAT 远控木马。

这不是 OpenClaw 本身的漏洞。根本原因,指向了 JavaScript 生态里一个你几乎每天都在用的组件——Axios

Axios 是 npm 下载量排名全球第一的 HTTP 客户端库,每周下载超 1 亿次,是 React、Vue、Angular 前端项目和 Express、NestJS 后端服务的标配依赖。它如此基础,以至于你使用的很多工具——包括 OpenClaw——都在底层依赖它,你甚至不知道它的存在。

2026 年 3 月 31 日,攻击者劫持了 Axios 首席维护者的 npm 账号,向官方注册表推送了两个被植入恶意代码的版本:axios@1.14.1axios@0.30.4

任何在感染窗口期内执行 npm install 的项目,只要允许拉取这两个版本,都可能已在不知情的情况下被植入后门。

OpenClaw 中招的原因正是如此——上游依赖被污染,OpenClaw 用户成为受害者,而自己完全没有过错。

攻击手法:专业、精密、反检测

这次投毒并非普通的「上传恶意包」。攻击者展现出相当高的对抗意识,整个攻击链设计得极为精密。

攻击时间线

图片

整个攻击从预埋到投毒仅历时约 19 小时

三个关键技术特征

1.影子依赖注入(Ghost Dependency)

Axios 本身的源码没有任何改动。攻击者仅在 package.json 中额外声明了一个从未被 axios 代码引用的依赖 plain-crypto-js,npm 安装时自动拉取并执行。这使得源码审计几乎无法发现异常——你看 axios 的代码,没有任何问题

2. 诱饵预热,规避「零历史账号」检测

在发布恶意包的 18 小时前,攻击者提前发布一个干净版本,为攻击者账号建立发布历史。许多自动化安全工具会对「从未发包的新账号」重点告警,这一预热动作有效绕开了这类检测。

3. 跨平台 RAT + 反取证自删除

dropper 识别操作系统,刻意回避在代码顶层 require 敏感系统模块(如 fs、os、child_process),转而在运行时动态构建模块名称并加载,此方法可以绕过SAST分析工具。

// 典型动态加载模式(示意,非原始代码)const mod = require(['ch','ild','_pr','ocess'].join(''));const exec = mod['execS' + 'ync'];

并在之后联系 C2 服务器 http://sfrclak.com:8000/6202033(IP142.11.206.73),下载对应平台的第二阶段载荷:

图片

执行完毕后,恶意脚本将自身删除,并用干净版本替换 package.json,导致事后取证极度困难。

昨天上午11:19,我们已经检测到了

在 npm 官方于北京时间 12:00 正式下架恶意包约 41 分钟前,塞讯高级持续威胁情报智能平台的供应链情报模块已完成对本次投毒事件的情报收录与威胁标注。

检测时间:今天上午 11:19(北京时间)

图片

图片

这背后依赖的是平台内置的三层检测引擎联合工作:

  • 多源外部情报聚合

    实时对接 24+ 外部情报源(Snyk、OSV、GitHub Advisory、Socket.dev 等),全天候同步新威胁包记录,无需人工触发

  • 自研动态与静态分析

    对可疑包进行多工具组合检测 + LLM 深度语义分析,覆盖混淆代码、postinstall 钩子、动态模块加载等对抗性技术

  • 威胁情报与 IOC 关联

    从恶意包到 C2 域名、攻击 IP,攻击链完整呈现——一张详情页,看清这次投毒从包到 C2 的完整路径

这次 Axios 投毒事件,从外部情报发现到平台收录,完全由自动化流程完成,决策链路上不依赖人工感知。

威胁情报检测系统

自查手段:先把今天的损失搞清楚

如果你的团队今天在感染窗口期(北京时间 08:00–12:00)执行过 npm install 或 npm update,请立即按以下步骤自查。

4.1 检查依赖版本

npm list axiosnpm list plain-crypto-js检查全量依赖树(包含传递依赖)npm list --all | grep -E "axios|plain-crypto-js"检查 lock 文件中是否锁定了恶意版本grep -E "1\.14\.1|0\.30\.4|plain-crypto-js" package-lock.json

4.2 检查幽灵依赖目录(最关键特征)

ls node_modules/plain-crypto-js 2>/dev/null && echo "⚠️ POTENTIALLY AFFECTED"

即使恶意脚本已自删除,只要该目录存在,即可判定 dropper 曾经执行过

4.3 检查平台特定文件残留

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "🔴 COMPROMISED"Linux — 检查 Python RAT 脚本ls -la /tmp/ld.py 2>/dev/null && echo "🔴 COMPROMISED"
# Windows(PowerShell,管理员运行)Get-Item "$env:PROGRAMDATA\wt.exe" -ErrorAction SilentlyContinue# 若有输出,与正常路径 C:\Program Files\WindowsApps\ 对比确认

4.4 检查网络侧痕迹

在防火墙/流量日志中搜索到 sfrclak.com:8000 的 HTTP POST 请求。如有回连,系统已失陷,立即进入应急响应。

封禁以下 IOC:

  • 域名:sfrclak.com / callnrwise.com

  • IP:142.11.206.73 / 142.11.196.73 / 142.11.199.73

  • 端口:8000

4.5 立即修复:固定安全版本

# 1.x 分支 → 降级至安全版本npm install axios@1.14.0# 0.x 分支 → 降级至安全版本npm install axios@0.30.3# package.json 中去掉 ^ 符号,固定精确版本:# "axios": "1.14.0"  而非  "axios": "^1.14.0"# CI/CD 环境临时措施:阻止安装脚本执行npm install --ignore-scripts

为什么「自查清单」不够用

上述自查步骤能帮你止血。但每次类似事件发生后,你都需要重新拿出这份清单,重新推送给开发团队,等待他们逐一排查——然后收集零散的反馈,再判断有没有遗漏。

这个流程本身就是问题所在。

你能在多少分钟内知道自己中招了?

你能在恶意包被引入之前就阻止它吗?

这两个问题,才是软件供应链防御的核心。

今天这起事件暴露的,正是大多数企业软件供应链防御的结构性盲区:情报感知是被动的,防御是事后的,开发侧的依赖引入几乎没有管控。

Axios 首席维护者在 GitHub 公开表示,他无法从内部撤销攻击者的发布权限,只能申请人工干预。

这意味着:即使是全球最高频的开源项目之一,其安全性也依赖于一个账号的密码强度和一个维护者是否开启了 MFA。

开源生态的信任模型本质是脆弱的。未来类似的供应链投毒事件不会减少,会更频繁,手法会更精密,影响范围会更广。

企业不能把信任决策寄托在上游维护者的账号安全上。 可量化、可自动化、不依赖人工感知的信任验证体系,才是应对这类系统性风险的长效解法。

从昨天的 11:19 开始,这已经不再只是「安全团队的事」了。

图片

IOC 汇总

立即在防火墙、SIEM、DNS 过滤中封禁以下指标

图片

Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐