2026 年 4 月 2 日，Axios 官方在 GitHub 发布事故复盘（Issue #10636），确认 2026 年 3 月 31 日 曾有两个被植入恶意依赖的版本发布到 npm：

• axios@1.14.1
• axios@0.30.4

这两个版本引入了 plain-crypto-js@4.2.1。官方描述显示，该依赖会在 macOS / Windows / Linux 上投放远控木马（RAT）。据官方时间线，恶意版本在 npm 上约 3 小时后被下架。

一、事件经过（按时间）

• 2026-03-30 05:57 UTC：plain-crypto-js@4.2.0 发布
• 2026-03-31 00:21 UTC：axios@1.14.1 发布并注入恶意依赖
• 2026-03-31 约 01:00 UTC：axios@0.30.4 发布，同样带恶意依赖
• 2026-03-31 01:38 UTC：社区开始推动下架与弃用流程
• 2026-03-31 03:15 UTC：恶意 Axios 版本从 npm 移除
• 2026-03-31 03:29 UTC：plain-crypto-js 被移除

官方结论是：这是维护者账号或设备被攻陷后导致的发布链路失守，不是正常代码审查中的合法变更。

二、为什么这件事值得所有开发者重视

这起事件的警示不在于“某个库出问题”，而在于攻击路径已经非常现实：

1. 2FA 不是终点
   攻击者如果控制了开发者终端，可以直接利用已登录会话、令牌和本地凭据。

2. 个人设备就是供应链入口
   很多开源项目的发布权限最终落在个人机器和个人账号上。

3. 短窗口也足够造成扩散
   自动升级、CI 临时安装、npx 非固定版本解析，都可能在几小时内中招。

三、个人开发者今后要注意什么（重点）

1) 设备与账号隔离（最高优先级）

• 发布账号、代码签名账号、云平台账号分离
• 发布动作尽量不在日常办公机执行
• 关键账号启用硬件密钥（FIDO2），减少可导出凭据
• 定期清理浏览器会话与长期 token

2) 发布流程改造

• 从“个人本地发布”迁移到“CI 受控发布”
• 使用 OIDC 或短期凭证，避免长期 npm token 常驻
• 对发布分支启用双人审批与保护策略

3) 依赖与安装策略

• 强制使用 lockfile，并在 CI 中禁止漂移
• 避免在生产和 CI 中直接执行 npx xxx@latest
• 对新增依赖与 postinstall 脚本做额外审计
• 对高风险窗口建立“延迟升级”机制（观望数小时到一天）

4) 社工防护（这次事件的关键触发点）

• 面试、合作、会议邀请里凡是要求安装“插件/修复工具”，一律按高危处理
• 不在临时会议中执行下载脚本、终端命令或未知安装包
• 对看起来真实的 Slack/Teams/LinkedIn 身份做独立渠道核验

5) 个人应急预案（提前写好）

• 明确“中招后 30 分钟内”的动作清单：断网、切换干净设备、吊销 token、强制登出、旋转密钥
• 准备一键扫描命令，检查 lockfile 中已知恶意版本
• 保留最小可用日志（CI、网络、发布审计）以便追踪影响范围

四、给个人开发者的一份最小行动清单

今天就可以做的 8 件事：

1. 检查项目 lockfile 是否出现 axios@1.14.1、axios@0.30.4 或 plain-crypto-js
2. 轮换 npm、GitHub、云平台、CI 的高权限 token
3. 停止在本地机器直接发布 npm 包
4. 将发布迁移为 CI + OIDC 短期凭证
5. 关键账号改用硬件密钥 MFA
6. CI 禁用 @latest 漂移安装策略
7. 建立版本发布即通知的异常告警
8. 写一页纸应急 SOP，并演练一次

五、结语

Axios 事件不是“某个团队不小心”，而是开源生态的现实变化：
攻击者越来越专业，个人开发者就是供应链前线。

真正有效的升级，不是事后补洞，而是把安全能力做成默认流程：默认隔离、默认最小权限、默认可追溯、默认可回滚。

---

参考：

• Axios 官方事故复盘（GitHub Issue #10636）：https://github.com/axios/axios/issues/10636