3小时埋雷数百万开发者：Axios 被劫持，再次敲响开源供应链警钟

一个几乎所有前端工程师都认识的名字，突然成了攻击入口

如果你写过 JavaScript，大概率见过 Axios。它不算那种“站在舞台中央”的明星项目，却像自来水、电线和路由器一样，安静地待在无数应用和服务的底层：负责把程序连上互联网，发请求、收数据、处理接口。平时开发者对它的感情，大概就是“熟得懒得多看一眼”。

偏偏这类“大家都默认可信”的工具，最适合被黑客盯上。根据 TechCrunch 报道，本周一，一名被怀疑与朝鲜有关的黑客劫持了 Axios 在 npm 上的发布流程，推送了带恶意代码的新版本。Axios 每周下载量高达上亿次，哪怕恶意版本只在线了约 3 小时，风险窗口也足够吓人。安全公司 StepSecurity 发现并协助阻断了这次攻击，但在那之前，到底有多少系统已经中招，仍然没有明确答案。

这件事最让人后背发凉的地方，不是 Axios 本身有多重要，而是它太“普通”了。它并不是某个只有少数安全研究员才知道的冷门组件，而是开发世界里的公共设施。很多团队的 CI/CD 流水线会自动拉取依赖，开发者本地环境也可能习惯性升级版本。换句话说，黑客不是在攻击一个库，而是在攻击现代软件生产方式本身。

攻击者没有砸门，而是拿到了钥匙

从目前披露的信息看，这次入侵并不是传统意义上的“技术奇袭”，而更像一次极其老练的权限接管。黑客攻破了 Axios 一位核心维护者的账号，随后把账号绑定邮箱替换成自己的地址，让原维护者更难夺回控制权。接着，攻击者以看起来正常的更新形式，向 Windows、macOS 和 Linux 用户分发了恶意版本。

恶意载荷的核心是一个 RAT，也就是远程控制木马。简单说，它像是在受害者机器里偷偷装了一把“万能遥控器”，攻击者可以借此远程操作系统、窃取数据、继续横向移动。更狡猾的是，研究人员提到，这些恶意代码及其投递逻辑还具备一定“自删除”能力，安装后会主动清理痕迹，以降低被反病毒工具和调查人员发现的概率。一个会作案、会擦指纹、还会悄悄离场的木马，显然不是临时起意的小打小闹。

谷歌威胁情报团队把这次事件归因于其追踪的朝鲜相关威胁组织 UNC1069。谷歌首席分析师 John Hultquist 的判断很直白：朝鲜黑客在供应链攻击方面经验丰富，过去就常利用这类手法窃取加密货币。这个背景很关键，因为它意味着这不是“又一个 npm 事故”，而是更像一个成熟攻击产业链在持续复制成功经验。

为什么每隔一阵子，开源世界就要经历一次“信任崩塌”

这不是第一起，也绝不会是最后一起。过去几年，软件供应链攻击已经从“高端黑客战术”变成了现实世界里越来越常见的安全事件。从 SolarWinds、Kaseya、3CX，到 Log4j 漏洞和 Polyfill.io 风波，攻击者早就意识到：与其一个个突破终端用户，不如直接控制大家共同依赖的上游。

这种打法的残酷之处在于规模效应。黑客只要成功侵入一个足够流行的组件，就像在城市供水系统里投下一滴毒药，影响范围会顺着依赖关系自动扩散。开发者对上游库的信任，原本是为了提高效率；可一旦这种信任被劫持，效率本身就会反噬安全。今天的软件开发，越来越像搭乐高，大家从 npm、PyPI、GitHub 拉来一块块现成积木，几小时就能拼出产品雏形。这很美好，也很脆弱。

更麻烦的是，开源世界长期建立在一种近乎理想主义的运行逻辑上：全球开发者共享代码，少数维护者在业余时间撑起关键基础设施，社区默认善意、默认透明、默认协作。可现实世界里的攻击者并不讲理想主义。他们会研究维护者的作息、账号习惯、社交关系、权限边界，甚至利用疲惫、疏忽和孤立无援。说得直白一点，很多重要开源项目之所以“免费”，不是因为它们不值钱，而是因为一直有人在义务补位。问题是，攻击者可不会因为你是志愿维护者就手下留情。

这件事真正刺痛行业的，不只是 Axios，而是自动化依赖的盲区

很多公司会说，我们有终端防护、有代码审计、有云安全平台。可供应链攻击最爱钻的，往往是组织流程里的“默认信任”。例如，依赖升级是否经过人工验证？构建系统是否锁定了精确版本？生产环境是否会自动接收最新包？维护者账号是否开启了强制多因素认证？这些问题平时看起来像“流程细节”，出事时就会瞬间升级为灾难开关。

安全公司 Aikido 给出的建议相当严厉：凡是在那段时间下载了受污染 Axios 版本的用户，都应该默认系统已被攻破。这个判断听起来刺耳，但其实很专业。因为面对 RAT 这类后门，最危险的不是它现在做了什么，而是你根本不知道它还留了什么。一次中招，可能意味着凭据泄露、会话被劫持、CI 密钥外流、代码仓库被渗透，甚至后续被用来继续感染客户环境。很多时候，最难修复的不是某个恶意包，而是那条已经被悄悄打开的信任链。

我更担心的是，行业在舆论层面很容易把这类事件理解成“维护者账号被盗”，仿佛只是个人疏忽。但真正的问题是，今天太多关键开源项目仍然依赖个人账号、松散治理和脆弱的发布权限。只要生态系统继续让“单点维护者”掌握高价值发布通道，这类事故就会反复出现。我们不能一边把开源项目当数字时代的公路和桥梁，一边又让它们靠志愿者拿着手电筒在深夜修路。

接下来，开发者和平台都该补什么课

从短期看，最实际的动作当然是排查。检查是否安装了问题版本，回溯构建日志，轮换令牌、密钥和凭据，审查可疑出站连接，必要时把受影响主机按已失陷系统处理。对企业团队来说，这类事件最忌讳“先观望一下”，因为一旦真有后门常驻，时间只会站在攻击者那边。

从中长期看，npm、GitHub 和更广泛的开源生态需要把“发布安全”提高到接近金融级别的重视程度。强制 MFA 只是底线，发布签名、硬件密钥、细粒度权限、异常发布检测、可信构建、可验证来源（provenance）这些机制，都不该再停留在安全大会 PPT 里。过去几年，软件物料清单 SBOM、SLSA 框架、Sigstore 等概念被谈了很多，但落到实际项目中的比例仍不够高。每次供应链攻击之后，行业都会集体反思一阵子，然后继续把便利性摆在安全前面。直到下一次事故再来。

还有一个更大的问题值得追问：像 Axios 这样的基础开源项目，究竟该由谁来承担安全成本？开发者社区？平台公司？云厂商？还是那些每年靠开源组件赚取数十亿美元收入的大企业？如果答案始终模糊，那么风险就会继续向最薄弱的那一环转移——也就是维护者个人。

Axios 事件之所以重要，不只是因为“朝鲜黑客又来了”，而是它再次提醒我们：现代软件世界的边界，早已不在公司防火墙上，而在依赖树的最深处。那里看起来像一串平平无奇的包名，实际上却是整条产业链最柔软、也最昂贵的地方。