今天上午，技术圈里炸了锅。有个哥们在群里丢了一句话，瞬间让我手里的咖啡dou不香了：“axios 被投毒了。”

我的第一反应是：不可Neng。这可是 axios 啊，那个每周下载量超过 1 亿次、常年霸榜 npm Top 10 的前端神库。谁敢动它？谁又有Neng力动它？但当我把时间线、代码仓库、npm registry 的元数据全部摊在桌面上时后背真的开始冒冷汗。这不仅仅是一次简单的攻击，这是一次教科书级别的供应链“外科手术”。

Zui让人细思极恐的是什么？你去 GitHub 上翻 axios 的仓库，一行恶意代码dou找不到。源码干干净净，清白得像张白纸。但只要你在这个特定的时间窗口里运行了 npm install，你的机器就Yi经不再属于你了。

kan不见的幽灵：当源码不再是真相

我们习惯了信任 GitHub。我们默认只要仓库里的代码是安全的，npm install 下来的东西就是安全的。这种直觉，在这次攻击中被彻底击碎了。

问题的根源在于一个被大多数人忽视的事实：npm registry 和 GitHub 是两个完全独立的系统。

你在 GitHub 上kan到的代码，和你 npm install 装到 node_modules 里的东西，完全Ke以不是同一个东西。这个差异写在 npm registry 的元数据里但你平时装包的时候，有谁会去查 registry 的元数据？有谁会去比对 tarball 的哈希值？

这次攻击者正是利用了这个巨大的盲区。他们没有去碰 GitHub 上的源码，因为那里有代码审查，有 CI/CD 流程，有无数双眼睛盯着。他们直接偷走了维护者的 npm token，绕过了 GitHub 所有的安全防线，直接往 npm registry 扔了两个“官方版本”。

这就像你去五金店买了一把锁，品牌对、包装对、外观对，甚至锁芯的型号dou对。但当你把它装回家后你不知道的是里面的弹子早就被人换成了带后门的。你用着hen正常，锁也Neng锁上，但别人随时Neng开你家门。普通的漏洞是锁有设计缺陷，换一把就行；而这次是锁在到你手里之前，就Yi经被掉包了。

复盘：一场精密的 18小时 布局

这不是一次冲动的黑客行为，而是一次蓄谋Yi久的狩猎。StepSecurity 把这次攻击称为“针对 npm Top 100 包有记录以来Zui精密的供应链攻击之一”。让我们把时间轴拉长，kankan攻击者是如何一步步把猎物引入陷阱的。

T-18小时：潜伏的开始

攻击者注册了一个一次性账号，发布了一个名为 plain-crypto-js@0.0.1 的包。

你可Neng会问，这个包是干嘛的？注意，这个版本是干净的。它的内容就是合法的 crypto-js 的复制品，零恶意代码。攻击者为什么要发一个干净版本？为了“养号”。在 npm 的生态里一个零历史的新包Ru果突然被像 axios 这样的大包依赖，会立刻触发各种安全警报和异常检测。攻击者需要先在 npm 上建立发布历史，让它kan起来像个人畜无害的普通工具库。

T-30分钟：图穷匕见

潜伏了 18 小时后攻击者动手了。他们发布了 plain-crypto-js@0.0.2。

这个版本注入了恶意的 postinstall 脚本。这才是真正的毒药。此时陷阱Yi经布好，只等猎物上门。

T=0：致命一击

攻击者用被盗的维护者账号，发布了 axios@1.1.0 和 axios@1.2.0。这两条版本线，一次全覆盖。

axios 的源码本身没有任何改动。攻击者只是在 package.json 的依赖里悄无声息地加了一个你从没见过的包：plain-crypto-js。当你运行 npm install axios 时npm 会乖乖地把这个恶意依赖拉下来。

注意，axios 所有合法的 1.x 版本dou通过 GitHub Actions 的 OIDC Trusted Publisher 机制发布，有密码学签名，和 GitHub 工作流绑定。但这次发布的 1.1.0 和 1.2.0 没有。它们是纯手动发布的，没有 OIDC 绑定，没有 gitHead。Ru果你当时去查发布者信息，应该Neng发现端倪，但谁会去查呢？

T+3小时：销声匿迹

npm 官方迅速响应，下架了恶意版本，窗口关闭。攻击者知道自己的时间不多，必须在被发现前完成收割。18 小时预埋，30 分钟把两条版本线全覆盖，3 小时后窗口关闭，痕迹自毁。这效率，比大多数公司的应急响应dou要快。

极速收割：你来不及按 Ctrl+C

当你 npm install 的瞬间，噩梦就开始了。

那个被悄悄拉下来的 plain-crypto-js 包里的 postinstall 脚本会自动跑起来。它不需要你Zuo任何操作，甚至不需要你运行代码。它检测你的操作系统，下载远控木马，连上攻击者的服务器。

有个细节让人头皮发麻：恶意载荷在 npm install 开始后 3 秒内就开始向攻击者服务器回传信息。这比 npm 解析完其他依赖的速度还快。你甚至来不及反应，来不及按 Ctrl+C，你的机器就Yi经“沦陷”了。

geng狠的是这个脚本有“自毁”机制。它干完坏事之后会自我删除，把 package.json 替换成干净版本。等你事后去翻 node_modules，什么痕迹dou没有。就像什么dou没发生过一样。

RAT 跑起来之后你机器上的一切对攻击者dou是透明的。环境变量、SSH keys、浏览器的 cookies、私钥……别侥幸，只要 CI 机器中招，你所有的 CI secrets dou可NengYi经泄露。

紧急自救：现在立刻，马上

这不是“可Neng要换密码”的温馨提示，是现在就轮换所有凭证的红色警报。Ru果你用了 axios，请立刻花 5 分钟跑一遍下面的流程。

第一步：检查你的“案发现场”

打开你的 package-lock.jsonpnpm-lock.yaml 或 yarn.lock，搜这三个关键词：axios@1.1.0axios@1.2.0 以及 plain-crypto-js。

Ru果这三个dou没有？大概率你是安全的。但为了睡个安稳觉，后面的几步也值得Zuo。

第二步：清理缓存，别留后患

运行这条命令：

npm cache clean --force

踩坑预警：CI 环境也要清！

hen多人只清了本地，却忘了 GitHub Actions、GitLab CI 的缓存。Ru果你的 CI/CD 管道里有 node_modules 缓存或者 npm 缓存，里面Ru果残留了恶意的 tarball，下次构建的时候还会命中缓存， 中毒。别只清本地，要把 CI 的缓存策略也检查一遍。

第三步：审查 install 脚本

这次的载体就是 postinstall。你Ke以顺手kankan你其他依赖有没有可疑的 install 脚本：

grep -r '"postinstall"' node_modules/*/package.json

Ru果你kan到一些莫名其妙的包在执行 postinstall，一定要去查清楚它的来源。

第四步：锁定版本，拒绝“自动升级”

kankan你的 package.json，是不是长这样：

"axios": "^1.1.0"

注意那个 ^。它意味着自动升级到Zui新兼容版本。这次恰恰就是这个机制，让hen多项目自动装上了恶意版本。虽然恶意版本Yi经下架，但显式锁定版本是个好习惯。把它改成：

"axios": "1.1.1"

注意是 "1.1.1"，不要带 ^。不要给攻击者留任何“自动geng新”的机会。

第五步：激进防御

Ru果你对安全性要求极高，Ke以在 .npmrc 里加一行：

ignore-scripts=true

这会全局禁止 npm 脚本运行。但是要注意，像 esbuild、sharp 这些包也靠 postinstall 下载二进制文件，全禁可Neng会导致构建失败。这需要你自己权衡利弊。

反思：信任链的脆弱性

hen多开发者的直觉是：axios 每周 1 亿次下载，总不会出事吧。但反过来想，越热门的包，攻击者的投入产出比越高。投毒一个每周 10 次下载的包没人会在乎，但投毒一个每周 1 亿次下载的包，3 小时窗口就够覆盖成千上万个项目，甚至包括hen多大厂的核心业务。

这次 axios 的源码没有任何问题。问题出在发布链上。你默认信任的那条从代码到 registry 的链路，才是该被审计的东西。

我们不仅要kan源码，还要审计 lockfile，审计 install 脚本，监控依赖变geng，关注 registry 元数据的发布者签名。这些不是有空再搞的事，这是现代软件工程的基础设施。

Zui后查查异常进程和网络连接，特别是关注 sfrclak.com:443 这个地址。Ru果发现了那说明你的机器Yi经不再是秘密了。

你的项目查了吗？评论区报个平安。身边有用 axios 的朋友还不知道这事的，转给他kan一眼。这场战争，没有旁观者。

---