2026 年 3 月底，流行的 JavaScript HTTP 库 Axios 遭遇供应链攻击，攻击者通过社交工程手段入侵维护者设备，在约三小时内发布了两个恶意版本。这一事件不仅暴露了 npm 生态系统的供应链脆弱性，也为整个开源社区提供了宝贵的事故响应与预防经验。本文聚焦 Axios 官方发布的复盘报告，深入剖析其内部响应工作流、根因分析过程以及后续工程改进措施，为开发团队提供可落地的供应链安全事件响应清单。
攻击链路与事件时间线
2026 年 3 月 31 日，协调世界时（UTC）00:21 至 03:15，约三个小时内，恶意版本的 Axios（axios@1.14.1 和 axios@0.30.4）被发布到 npm 注册表，随后在当天被移除。据 Axios 官方复盘报告，攻击源于朝鲜威胁组织 UNC1069 发起的一场精心策划的社交工程活动。攻击者首先克隆了一家真实公司创始人的身份，建立了一个品牌化的虚假 Slack 工作区，并配有伪造的团队成员资料。随后，他们安排了一场看似正常的 Microsoft Teams 会议，在会议过程中诱导维护者 Jason Saayman 安装所谓的 “缺失软件组件”。
实际上，这是一枚跨平台远程访问木马（RAT）。值得注意的是，即使该维护者的账户已启用双因素认证（2FA），攻击者在获得设备访问权限后仍能完全控制其机器，从而绑过了所有基于软件的认证措施。恶意版本中注入了一个名为 plain-crypto-js@4.2.1 的虚假依赖项，该依赖项包含一个 post-install 脚本，用于投递平台特定的 RAT 载荷。在 macOS、Windows 和 Linux 系统上，恶意软件均会连接到命令与控制（C2）服务器 sfrclak.com:8000。投放器还会自行清除 node_modules 中的痕迹，使受感染目录看起来与正常无异。
安全研究人员确认，目标 C2 服务器的 IP 地址为 142.11.206.73。微软与 Datadog Security Labs 均在事件披露后发布了详细的缓解指南，建议所有在受影响时间段内执行过 fresh npm install 的用户将系统视为已受感染。
内部响应工作流：从发现到遏制
Axios 维护团队在事件披露后启动了一套结构化的事件响应工作流，整个过程可分为四个阶段：发现与确认、遏制与影响评估、修复与恢复、以及后续改进。
在发现与确认阶段，维护者首先注意到异常活动，随后通过 GitHub Issue 与安全社区的反馈确认了恶意版本的存在。此时的关键动作是立即从 npm 注册表撤下受影响版本，同时在官方渠道发布紧急安全公告，明确列出受影响版本号与攻击时间窗口。由于 Axios 每周下载量超过三亿次，团队面临的核心挑战是如何在最短时间内将风险信息传递到下游开发者群体。
遏制阶段的工作重点是限制损害范围。维护团队建议所有用户降级至 axios@1.14.0（或 0.x 用户的 0.30.3），并手动删除 node_modules/plain-crypto-js 目录。与此同时，团队开始追溯攻击向量，识别出社交工程是初始入侵途径，这一发现直接推动了后续安全改进措施的制定。
在影响评估方面，团队需要确定受影响范围。由于恶意版本仅在约三小时内可用，且发布后立即被移除，实际受影响的面相当有限。然而，考虑到 Axios 的广泛使用，任何在攻击窗口内执行过全新安装的项目都可能暴露。团队据此给出了明确的受影响时间范围（UTC 3 月 31 日 00:21 至 03:15），帮助用户判断自身风险等级。
恢复阶段涉及多层面的凭证轮换。团队建议用户检查网络日志中是否存在与 sfrclak [.] com 或 142.11.206.73:8000 的连接记录，并在发现异常时立即轮换所有凭证。对于在攻击窗口内进行过 CI/CD 构建的项目，还需检查构建环境中的 secrets 是否可能已被泄露。
根因分析：供应链的薄弱环节
复盘报告揭示了此次事件的根本原因，核心问题集中在三个方面：发布流程中的凭证管理缺陷、社交工程防御机制的不足，以及 npm 生态系统的系统性风险。
首先，维护者的 npm 发布凭证因长期未轮换而成为攻击目标。在传统发布模式下，维护者需要在本地存储长期有效的 npm 令牌或访问密钥，这些凭证一旦被窃取，攻击者即可在无需额外验证的情况下发布恶意版本。Axios 事件中，攻击者正是通过植入设备的 RAT 获取了这些凭证，从而完成了恶意版本的上传。
其次，社交工程防御是所有开源项目面临的共同挑战。即便维护者具备安全意识，攻击者仍能通过高度逼真的伪造身份、精心设计的沟通流程以及多层次的诱骗手段突破防线。在本案中，攻击者不仅克隆了公司身份，还构建了完整的协作环境（品牌化 Slack 工作区、伪造团队成员），并通过实时视频会议增加可信度。这种程度的攻击准备往往超出普通开发者的预期防御能力。
第三，npm 的发布机制缺乏细粒度的强制访问控制。与 crates.io 等其他包管理器不同，npm 目前不支持在注册表层面强制实施基于 OIDC（OpenID Connect）的发布验证。这意味着即个项目希望实现无凭证发布，也难以在 registry 级别获得系统支持。
工程改进措施：构建免疫供应链
基于根因分析，Axios 团队制定了一系列工程改进措施，目标是从根本上降低未来类似事件的发生概率。
最核心的改进是采用基于 OIDC 的发布流程。OIDC 发布通过将发布权限与短期令牌绑定，消除了对长期凭证的依赖。维护者在完成身份验证后，系统会颁发一个短生命周期的令牌用于单次发布，该令牌在任务完成后自动失效。即使攻击者截获了该令牌，也只能在极短时间内使用，大幅压缩了攻击窗口。
其次，团队正在构建不可变的发布基础设施。具体措施包括：分离发布环境与日常开发环境，使用专用的发布机器或容器；实施代码签名确保发布物的完整性；在发布前进行多因素审批流程，防止单点故障导致的恶意发布。
第三，GitHub Actions 工作流也进行了全面审计与加固。团队移除了所有长期存在的个人访问令牌（PAT），改用 GitHub 官方的 OIDC 令牌进行身份验证。同时，工作流中的敏感操作被限制在特定条件下触发，并启用了详细的审计日志。
在组织层面，维护者本人使用的所有设备均被完全擦除并重新安装系统，所有平台上的凭证均已重置。这一极端措施虽然成本高昂，但确保了攻击者可能遗留的任何后门均被清除。
面向开发团队的可复用事件响应清单
将 Axios 案例的经验抽象为可操作的检查项，以下清单适用于任何面临供应链安全事件的开发团队：
发现与报告阶段（0-1 小时）：确认报告的可信度并评估影响范围；立即从包管理器撤下可疑版本；在项目官方渠道发布安全公告；保存攻击样本用于后续分析。
遏制与影响评估（1-24 小时）：确定受影响版本号与发布时间窗口；识别并通知直接依赖该包的下游项目；检查是否存在异常网络连接（如 C2 服务器域名或 IP）；评估是否需要通知安全监管部门。
修复与恢复（24-72 小时）：发布安全版本并验证发布流程的完整性；提供明确的降级路径与清理步骤；指导用户轮换可能泄露的凭证；审计 CI/CD 流水线中的敏感操作。
后续改进（1-4 周）：审查发布流程中的凭证管理机制；评估是否可引入 OIDC 或其他无凭证发布方案；更新开发者安全培训材料，加入社交工程防御内容；建立供应链安全监控与自动告警机制。
Axios 事件虽然已经平息，但它为整个开源生态敲响了警钟。供应链安全不仅是技术问题，更是流程与意识问题。通过将事件响应流程标准化、将发布环节中的长期凭证替换为短期动态令牌、开发团队能够在很大程度上降低社交工程与凭证窃取带来的风险。这一事件的后续改进措施也为其他依赖 npm 的项目提供了可借鉴的工程实践范本。
资料来源：Axios 官方 GitHub Issue（GitHub Issue #10636）、Techzine 报道、微软安全博客