攻击者劫持 axios 维护者账号，在 npm 发布带恶意依赖的版本，通过 postinstall 脚本投递跨平台远程访问木马，并利用自毁与伪装机制逃避检测。

axios 供应链攻击深度技术分析

事件概述

2026 年 3 月 30 日，StepSecurity 检测到 npm 上最流行的 JavaScript HTTP 客户端库 axios（每周下载量超 1 亿次）发布了两个恶意版本：axios@1.14.1 和 axios@0.30.4。这两个版本注入了一个名为 plain-crypto-js@4.2.1 的隐藏依赖——该依赖从未在 axios 源码中被引用，其唯一目的是执行一个 postinstall 脚本，该脚本作为跨平台远程访问木马（RAT）的投递器，同时针对 macOS、Windows 和 Linux 系统。

投递器会连接一个活跃的命令与控制（C2）服务器，获取并执行针对特定平台的第二阶段载荷。执行完毕后，恶意软件会自毁并替换自身 package.json 为干净版本，以规避取证检测。

如果您已安装 axios@1.14.1 或 axios@0.30.4，请假设系统已被入侵。

攻击的隐蔽性：零恶意代码的恶意发布

axios 本身没有任何一行恶意代码——这正是此次攻击危险性的核心所在。

两个被投毒的版本都注入了伪造的依赖 plain-crypto-js@4.2.1，该包：

• 从未被 axios 源码 import
• 仅通过 postinstall 钩子运行恶意脚本
• 投递跨平台 RAT
• 执行后自毁并替换 package.json 为干净诱饵

开发者在事后检查 node_modules 文件夹时，会找不到任何异常迹象。恶意依赖看似是一个普通的加密库，与合法的 crypto-js 外观相似，但实则是一个精心伪装的攻击载体。

// 恶意版本中 axios 的 package.json 片段（示意）
{
"name": "axios",
"version": "1.14.1",
"dependencies": {
"plain-crypto-js": "4.2.1" // 这个依赖从未在源码中使用
}
}

攻击的精准预谋

这不是机会主义攻击，而是一场精密策划的供应链袭击：

• 恶意依赖提前 18 小时预置——在 npm 上建立了发布历史，避免安全扫描器标记为"新包"
• 为三个操作系统预构建三个载荷——macOS、Windows、Linux 平台分别定制
• 两个发布分支在 39 分钟内先后被投毒——覆盖 1.x（现代用户群）和 0.x（遗留用户群）
• 每个构件都设计为自毁——执行后删除自身并伪装 package.json

关键速度指标：在 npm install 后的 2 秒内，npm 甚至尚未完成依赖解析，恶意软件就已经向攻击者服务器发起回调。这是有史以来针对 npm 前十大包的最具操作复杂度的供应链攻击之一。

攻击时间线

攻击在约 18 小时内完成预置，恶意依赖先于 axios 发布被种入 npm，以避免触发"全新包"警报：

时间 (UTC)	事件
2026-03-30 05:57	plain-crypto-js@4.2.0 由 nrwise@proton.me 发布——干净诱饵，包含完整合法 crypto-js 源码副本，无 postinstall 钩子。其唯一目的是建立 npm 发布历史，使该包在后续审查中不呈现为零历史账户
2026-03-30 23:59	plain-crypto-js@4.2.1 由同一账户发布——加入恶意载荷。引入 postinstall: "node setup.js" 钩子和混淆的投递器
2026-03-31 00:21	axios@1.14.1 由被攻陷的 jasonsaayman 账户发布（邮箱改为 ifstap@proton.me）——注入 plain-crypto-js@4.2.1 作为运行时依赖，针对现代 1.x 用户群
2026-03-31 01:00	axios@0.30.4 由同一被攻陷账户发布——对遗留 0.x 分支进行相同注入，比 1.14.1 晚 39 分钟，最大化两个发布线的覆盖范围
2026-03-31 ~03:15	npm 下架 axios@1.14.1 和 axios@0.30.4。两个版本从 registry 移除，latest 标签回退至 1.14.0。axios@1.14.1 存活约 2 小时 53 分钟；axios@0.30.4 存活约 2 小时 15 分钟。时间戳根据 axios registry 文档的 modified 字段推断（03:15:30Z）——npm 公开 API 不提供按版本的精确下架时间戳
2026-03-31 03:25	npm 对 plain-crypto-js 启动安全持有（security hold），开始用 npm 安全持有者存根替换恶意包
2026-03-31 04:26	npm 在 npm@npmjs.com 账户下发布安全持有者存根 plain-crypto-js@0.0.1-security.0，正式替换 registry 上的恶意包。plain-crypto-js@4.2.1 存活约 4 小时 27 分钟。现在尝试安装任何版本的 plain-crypto-js 都会返回安全通知

攻击机制详解

第一步：维护者账户劫持

攻击者攻陷了 jasonsaayman npm 账户——axios 项目的主要维护者。该账户的注册邮箱被更改为 ifstap@proton.me（攻击者控制的 ProtonMail 地址）。

利用此访问权限，攻击者同时在 1.x 和 0.x 发布分支上发布了恶意构建，最大化暴露项目数量。axios@1.14.1 和 axios@0.30.4 在 npm registry 中均记录为 jasonsaayman 发布，因此乍看之下与合法发布毫无区别。

两个版本均使用被攻陷的 axios 主要维护者的 npm 凭据发布，完全绕过了项目正常的 GitHub Actions CI/CD 流水线。

关键取证信号：OIDC 绑定缺失

npm registry 元数据中暴露了一个关键的取证信号。每个合法的 axios 1.x 发布都通过 GitHub Actions 配合 npm 的 OIDC Trusted Publisher 机制进行发布，这意味着发布在密码学上绑定到已验证的 GitHub Actions 工作流。

而 axios@1.14.1 完全打破了这一模式——通过被盗的 npm 访问令牌手动发布，没有 OIDC 绑定，也没有 gitHead：

// axios@1.14.0 — 合法版本
"_npmUser": {
"name": "GitHub Actions",
"email": "npm-oidc-no-reply@github.com",
"trustedPublisher": {
"id": "github",
"oidcConfigId": "oidc:9061ef30-3132-49f4-b28c-9338d192a1a9"
}
}

// axios@1.14.1 — 恶意版本
"_npmUser": {
"name": "jasonsaayman",
"email": "ifstap@proton.me"
// 无 trustedPublisher，无 gitHead，无对应 GitHub commit 或 tag
}

在 axios GitHub 仓库中，没有任何 commit 或 tag 对应 1.14.1。该版本只存在于 npm。合法发布使用的 OIDC token 机制（详情见下文）正是检测此类异常的关键。

OIDC Trusted Publisher 机制简介

npm 的 OIDC（OpenID Connect）Trusted Publisher 机制允许包发布者在 GitHub Actions 工作流中通过 OIDC 协议安全地获取短期令牌，而无需存储长期有效的 npm 访问令牌。发布过程会记录 trustedPublisher 元数据，将发布行为密码学绑定到特定的 GitHub 仓库和工作流。这使得攻击者即使窃取了 npm 账户密码或访问令牌，也无法伪造出带有有效 OIDC 绑定的发布记录——除非他们能直接控制 GitHub 仓库的 Actions 工作流。

第二步：恶意依赖的伪装与投递链

plain-crypto-js@4.2.1 的内部机制如下：

1. packages.json 声明 postinstall 钩子

{
"scripts": {
"postinstall": "node setup.js"
}
}

2. setup.js 为混淆的投递器——它包含反调试、环境检测和 C2 通信逻辑

3. C2 通信：执行后立即连接 sfrclak.com:8000（已确认的活动 C2 域名），根据检测到的操作系统（macOS/Windows/Linux）请求对应的第二阶段载荷

4. 第二阶段载荷：按平台定制的 RAT 木马，具有持久化、远程命令执行和数据窃取能力

5. 自毁机制：载荷执行后，恶意脚本删除自身文件，并用干净的 package.json 替换原有声明（移除 postinstall 钩子），使得后续的文件系统检查无法发现异常

攻击检测：StepSecurity 如何发现

本次攻击由 StepSecurity 的 AI Package Analyst 和 Harden-Runner 产品检测。

Harden-Runner 的社区免费层级（对公共仓库免费，已被超过 12,000 个公共仓库使用）在多个开源项目的 CI 运行中检测到被攻陷的 axios 包向攻击者 C2 域名发起了异常出站连接。

典型案例：在 backstage 仓库（最广泛使用的开发者门户框架之一）的一次例行 CI 运行中，Harden-Runner 标记了指向 sfrclak.com:8000 的 C2 回调。Backstage 团队已确认该工作流被有意沙箱化，恶意包安装不影响项目。该连接被自动标记为异常，因为它从未出现在任何先前的工作流运行中。

Harden-Runner 社区层级的网络事件洞察默认公开，允许任何人验证检测结果：
StepSecurity 网络事件页面

检测原理

Harden-Runner 通过以下机制实现检测：

1. 网络活动监控：在 CI 运行时实时捕捉所有出站连接
2. 基线学习：记录每个仓库历史工作流的正常网络行为模式
3. 异常检测：将当前运行中的连接与历史基线比对，从未出现过的目的地即标记为异常
4. 公开透明：社区层级的检测结果公开可查，便于安全社区共同验证

这种方法的优势在于它不依赖恶意软件特征库，而是基于行为基线——即使面对零日攻击或高度混淆的恶意软件也能有效检测。

攻击影响面与紧急响应建议

影响评估

axios 每周下载量超过 1 亿次，被数百万项目直接或间接依赖。虽然恶意版本在 npm 上仅存活约 2-3 小时，但在这段时间内，任何执行 npm install axios@1.14.1 或 npm install axios@0.30.4（或通过范围/标签解析到这些版本的安装）的项目都会自动下载并执行恶意依赖。

注意：即使项目依赖的是 axios@^1.14.0 这样的宽松范围，只要发布窗口内执行了安装，npm 也可能解析到 1.14.1。但多数项目的 lockfile 会固定版本，因此实际影响面取决于窗口期内新安装或更新依赖的项目数量。

必须执行的应急步骤

如果您在受影响时间窗口内（2026-03-31 00:21 UTC 至 03:15 UTC）安装了这些版本，或不确定是否安装过：

1. 立即隔离受影响的机器——断开网络连接，停止关键服务
2. 检查 CI/CD 流水线——如果 CI 在受影响窗口内执行过 npm install，假设构建产物已被污染
3. 扫描 node_modules——检查是否存在 plain-crypto-js 目录
4. 检查 npm 锁文件——查看 package-lock.json / yarn.lock / pnpm-lock.yaml 中是否记录了这些版本
5. 全面扫描系统——运行杀毒软件和 EDR 工具，寻找 RAT 特征
6. 轮换所有凭据——包括 npm 令牌、GitHub 令牌、云服务密钥等
7. 进行完整取证分析——检查计划任务、注册表（Windows）、launchd（macOS）、systemd 服务（Linux）等持久化机制

长期防护建议

• 启用 npm OIDC Trusted Publisher——所有 npm 包维护者应使用此机制替代静态访问令牌
• 使用 lockfile 并提交到仓库——锁定依赖版本，阻止范围解析意外升级
• 在 CI 中使用 Harden-Runner 或类似安全工具——监控出站网络连接，建立行为基线
• 定期审计依赖——使用 npm audit 和第三方安全扫描工具
• 对 postinstall 脚本保持高度警惕——任何不熟悉的依赖若带 postinstall 钩子，都应视为潜在风险

总结：供应链攻击的新范式

这次攻击展示了一个令人不安的演进方向：

1. 高度针对性——攻击目标明确为 axios 这样拥有海量用户基础的核心库
2. 攻击面最大化——同时覆盖多个发布分支
3. 反取证设计——自毁、伪装、预置历史，每个环节都精心规避现有检测机制
4. 行为检测的价值——传统特征检测难以发现此类攻击，基于行为基线的异常检测成为关键防线

对于开源生态而言，这次事件再次敲响警钟：供应链安全不再是可选项，而是每一位依赖者、每一位维护者都必须严肃对待的核心议题。

---

原文链接：https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan