StepSecurity 的 AI 包分析师和 Harden-Runner 在任何公开披露之前就检测到了 axios 的入侵，这是迄今为止针对单个包下载量最大的 npm 供应链攻击。随后，StepSecurity 与一个国家支持的威胁行为者展开了一场争分夺秒的较量，该行为者积极删除 GitHub 问题以压制警告；StepSecurity 决定在午夜召开社区电话会议，吸引了 200 人参加；彭博社和 Andrej Karpathy 等媒体都对此进行了报道。
距离 axios 安全漏洞事件已经过去一周了，我们想花些时间反思一下。事件发生期间，我们发布了一份 详细的技术分析报告 ，并一直在持续更新。但是，关于人性的故事，那个疯狂的夜晚，被删除的 GitHub 问题，以及社区在午夜时分团结起来的行动，这些部分我们还没有讲述。这就是这个故事。
axios 是 JavaScript 生态系统中最流行的 HTTP 客户端，每周下载量超过 1 亿次，拥有超过 1700 万个代码仓库和 24 万个依赖包。就下载量而言，这是 npm 历史上单个软件包遭受的最大规模攻击。一个受国家支持的威胁行为者劫持了 axios，当我们在 GitHub 上创建 issue 警告社区时，他们删除了该 issue。我们再次创建，他们再次删除。这种情况发生了大约 20 次。这并非随机的机会主义行为，而是一次有组织的、受国家支持的行动，其目标明确指向整个 npm 生态系统中最广泛使用的软件包之一。以下是整个事件的幕后故事。
警报
那是一个星期一的晚上，西雅图。在连续应对了一系列备受瞩目的供应链攻击事件，例如 TeamPCP/Trivy、Checkmarx KICS 和 LiteLLM 之后，我们原本希望今晚能平静一些。
但是事与愿违。
被篡改的 axios 包发布到 npm 后，StepSecurity 的 AI 包分析器 立即对其进行了实时分析，并返回了 “严重/已拒绝” 的判定结果。结论非常明确：这是一个恶意版本的合法 axios 库，明显显示出通过包劫持导致供应链遭到破坏的迹象。自动化分析标记了六个不同的可疑指标，例如：一个未记录且未使用的依赖项 (plain-crypto-js)，该依赖项从未在源代码中任何地方被导入；package.json 文件与内部版本数据不匹配；缺少 CHANGELOG 条目；以及遗漏了来源证明。
StepSecurity Harden-Runner 是我们专为 GitHub Actions 开发的端点检测与响应 (EDR) 代理，它独立验证了分析结果。Harden-Runner 检测到来 sfrclak.com 自已安装受感染软件包的 CI/CD 运行程序的异常出站网络调用，该调用指向 C2 域。Harden-Runner 的网络级检测结果，结合 AI Package Analyst 的静态分析，使我们在任何人审查代码之前就对分析结果充满信心。
作为威胁情报能力的一部分，StepSecurity 运营着一个 24x7 全天候安全运营中心 (SOC)，并集成了 PagerDuty 以进行关键检测。我们的联合创始人兼首席技术官 Ashish 当晚值班，第一个接到呼叫。几分钟之内，他交叉比对了 AI 软件包分析器的分析结果、Harden-Runner 网络警报以及快速的人工代码审查，确认了自动化系统告诉我们的信息：axios 已被入侵。
StepSecurity维护着超过250个GitHub Actions，主要使用Node.js编写，因此我们亲身体验过axios的普及程度。问题的严重性也显而易见。
Ashish 向我们的 Slack 公共频道发送了一条紧急消息，分享了他的评估，并发起了事件沟通会议。
我正准备出门去超市买东西，这时阿什什的消息出现在我们的Slack频道里。我放下手头的一切，赶紧回去参加电话会议。我们美国东海岸的客服团队即将结束一天的工作，而我们在印度的同事们则即将开始他们的工作。几分钟之内，来自不同时区的多位团队成员都加入了会议。
验证未知
在公开发出警报之前，我们希望谨慎行事。我们已经检测到了漏洞，并且对其准确性充满信心，但在向全世界宣布最常用的 npm 包之一已被攻破之前，我们需要确认我们没有重复他人的工作，也没有遗漏任何可能改变结果的背景信息。
我们查看了LinkedIn，也查看了X平台，还搜索了其他软件供应链安全公司的博客。我们查找了所有可能表明有人已经标记过此问题的帖子、讨论串或供应商警报，但一无所获。
据我们所知，当时还没有人发布关于此次安全漏洞的信息，恶意版本仍然可以从 npm 下载，任何运行 npm install 的用户都可以下载。每过一分钟，就有更多的开发者和 CI/CD 流水线拉取到一个会在他们机器上静默安装远程访问木马的软件包。由于没有人发出警报，我们必须采取行动。
拉响警报
我们同时在多个方面展开行动。我们发布了威胁中心警报，并通过 Slack、Webhook 和 S3 集成向企业客户发送通知，以便他们的安全运营中心 (SOC) 团队能够立即评估自身面临的风险。这是我们标准事件响应流程的一部分：当我们的 SOC 检测到关键供应链遭到入侵时，我们的企业客户会第一时间知晓。
我们发布了一篇 博文， 总结了我们的发现，包括被入侵的版本（1.14.1 和 0.30.4）、注入的 plain-crypto-js 依赖项以及 C2 域名。Ashish 在 LinkedIn 上发布了一份安全公告，详细分析了入侵的关键指标，以便浏览其动态的开发者能够看到此警告。
然后 Ashish 转向 axios GitHub 存储库，创建了一个问题，以便与维护者合作，提醒社区。
他还向 npm 报告了这些被入侵的软件包是恶意软件，标记了 axios@1.14.1 和 axios@0.30.4 以及恶意 plain-crypto-js 依赖项。
威胁行为者反击
然后，意想不到的事情发生了。当 Ashish 回到 GitHub 代码库查看他创建的问题时，发现问题不见了。被删除了。完全找不到任何痕迹。
攻击者不仅攻破了维护者的 npm 账户，还攻破了他们的 GitHub 账户。他们利用被攻破的账户积极监控代码仓库，悄悄删除所有试图警告社区正在发生的事情的 issue。
Ashish再次创建了该问题。其他注意到问题存在的社区成员立即开始评论，分享他们的发现，提出问题，并根据自己的分析确认了该漏洞的存在。几分钟后，该问题再次被删除。
于是他又创作了一遍。一遍又一遍。
每次 Ashish 在 GitHub 上创建 issue，社区成员都会纷纷留言。而每次，攻击者都会利用被攻破的维护者账户将其删除。每一次删除都证实了我们的怀疑：攻击者不仅掌握了 npm token，还完全控制了维护者的 GitHub 账户，并且一直在积极监控该代码库。
这种情况大约发生了 20 次。这是一场实时进行的拉锯战，一方是试图警告开发者的社区，另一方是试图掩盖入侵行为的威胁者。
在 GitHub 上这场猫鼠游戏上演的同时，Ashish 也提交了一份 GitHub 账户滥用工单，解释说维护者的账户似乎已被盗用，并被用于删除合法的安全公告。GitHub 和 npm 支持团队都迅速采取了行动。GitHub 暂停了被盗用的维护者账户，阻止了问题删除行为，并防止了该账户进行任何进一步的恶意操作。
npm 从注册表中删除了恶意软件包，并对攻击者的辅助包设置了安全限制。
被盗账户被封禁后， GitHub 问题 #10604 终于引起了广泛关注。它成为社区恢复工作的核心，最终获得了超过 1100 个点赞和 800 多条来自世界各地开发者的评论，他们分享了账户被盗用的迹象、补救措施以及他们自己的取证结果。
与社区合作
在直接威胁得到控制后，我们组建了多个小组来处理下一阶段的应对工作。一个小组专注于为 StepSecurity 企业客户提供直接支持。另一个小组深入开展技术取证工作，并记录完整的攻击链。第三个小组则将注意力转向更广泛的开源社区。
StepSecurity Harden-Runner 的社区版对开源项目免费开放，目前已有超过 12,000 个开源项目在使用。Harden-Runner 的洞察报告是面向社区版用户的公开信息，任何人都可以无需登录即可查看。利用这些公开的洞察报告，我们发现多个开源项目在攻击期间安装了被入侵的软件包。我们主动在受影响的 GitHub 代码库中创建 issue 来通知维护者，并在 issue 中提供相关的 Harden-Runner 洞察报告页面链接，以便他们自行查看证据。
我们收到了来自社区多个渠道的提问：GitHub、LinkedIn、私信和电子邮件。开发者们想知道他们是否受到影响，入侵的迹象有哪些，删除 node_modules 并重新安装是否足够（答案是否定的）。
太平洋时间午夜前后，我提议我们在周三上午 10 点（太平洋时间）举行一次社区电话会议，并设置了一个网络研讨会注册页面。说实话，我当时并不确定会有多少人参加。但令我们惊喜的是，反响非常热烈。共有 472 人注册，周三上午，有 200 位社区成员在线参加了会议。
这次电话会议意义非凡。它不仅仅是我们发布研究成果，更是社区成员实时分享、提问和互相帮助的平台。与会者提出了许多富有洞见的问题，例如，在之前的供应链事件中，凭证被窃取后是否会引发二次休眠攻击。一位社区成员将此与 Shai-Hulud 攻击活动相提并论，并提出攻击者是否会像《沙丘3》中的变形怪一样，耐心等待时机发动攻击。有人询问了冷却策略和 CVE 驱动的紧迫性之间的矛盾：如果新软件包版本修复了一个关键漏洞，如何在快速更新的需求和补丁本身可能被攻破的风险之间取得平衡？另一位与会者询问，C2 服务器是否会根据第一阶段有效载荷收集的设备指纹数据，提供不同的远程访问木马 (RAT) 变种。一位开发人员分享说，他们的 Azure Kubernetes 集群安装了恶意版本，但他们的防火墙已阻止了 C2 域，他想知道这样做是否足够。社区成员指出 Wiz 文章中提到的其他 C2 基础设施是我们之前没有看到的，因此我们更新了博客文章，添加了新的 IOC。
我们从那次对话中学到了很多东西，加深了我们对事件的理解。这次网络研讨会也提醒我们，最佳的安全研究是协作式的。您可以在 YouTube上观看完整录像。
在整个事件过程中，随着我们对事件了解的加深，我们不断更新博客文章。它逐渐成为一份动态文档，随着社区与我们分享的每一个新发现而不断完善，从新增的事件情报中心到补救措施指南，无所不包。
涟漪效应
看到广大社区如此迅速地团结起来应对这一事件，既令人欣慰，又令人感动。
在 GitHub 上，#10604 号 issue 成为了应对此次事件的实际协调中心。社区成员贡献了取证细节，共享了检测脚本，就修复方案提出并解答了问题，并互相帮助评估自身面临的风险。在被盗账户被封禁后，axios 项目的其他合作者夜以继日地工作，以恢复用户对该软件包的信任，发布了干净的版本，并与用户群体保持透明的沟通。
很高兴看到其他软件供应链安全公司也提高了对这一问题的认识，并贡献了他们自己的分析。Datadog 、 Aikido 、 Wiz 、 Endor Labs、 SafeDep、 Socket、 Huntress、 Malwarebytes、 Sophos和 SANS 都发布了详细的报告和建议，这有助于在整个生态系统中扩大警报范围。这才是安全社区应有的运作方式：每个人都尽其所能，在力所能及的范围内贡献力量。没有哪一家公司能够完全掌握所有信息，信息流通越快，整个生态系统就能越快做出响应。
媒体报道
我们非常感谢StepSecurity在此次事件中获得的媒体关注。axios攻击的规模之大，使其影响范围远远超出安全社区，并进入了主流科技媒体的视野。 彭博社报道 了此次事件，使其引起了企业领导层和董事会的关注，他们或许并不关注npm的公告，但却会关注财经新闻。Dark Reading 发表了详细的分析文章。TechCrunch 报道了朝鲜可能参与此次攻击的线索。CSO Online 称其为有史以来影响最大的npm供应链攻击。
Hacker News、 Bleeping Computer、 The Register、 Help Net Security、SC Magazine、 VentureBeat和 InfoQ 都发布了各自的报道。我们的博客文章在 Hacker News 上排名第一，并在首页置顶数小时。在威胁情报方面， 谷歌威胁情报小组、 微软安全团队、 Palo Alto Unit 42、 思科 Talos、 Elastic Security Labs和 Datadog Security Labs 都发布了深入的技术分析和检测指南。
Andrej Karpathy 在 X 上分享了我们的博客。拥有超过 400 万订阅者的热门 YouTube 频道 Fireship 在其对该事件的报道中引用了我们的技术分析。这样的时刻提醒着我们这样的小团队，我们的工作意义非凡。
社区确认
事件发生后的几天里，受害维护者本人 在 GitHub 问题 #10604 上发布了一条详细的评论， 证实了事件经过。他们遭遇了一场精心策划的社会工程攻击。攻击者冒充一家合法公司的创始人，与他们接触，并发起了一个看似正常的开源协作活动。攻击者创建了一个与这家公司品牌相符的虚假 Slack 工作区，搭建了持续集成 (CI) 基础设施以使协作看起来真实可信，并在 Microsoft Teams 上安排了一次视频通话。通话期间，攻击者使用伪造的错误信息诱骗维护者下载了一个“修复程序”，而该程序实际上是一个远程访问木马。
攻击者利用这款远程访问木马（RAT）入侵了维护者的机器，并窃取了一个长期有效的 npm 访问令牌。该令牌使他们能够直接发布被篡改的 axios 版本，绕过了项目基于 OIDC 的发布控制机制。原本，该机制要求发布操作必须来自受信任的 CI/CD 环境。此外，攻击者还获得了维护者的 GitHub 账户访问权限，并利用该账户删除了我们创建的用于警告社区的问题。
谷歌威胁情报小组随后 将此次攻击归咎于 朝鲜威胁组织 UNC1069。微软威胁情报小组则独立地将其归咎于 Sapphire Sleet，这是他们对同一朝鲜国家支持组织的称呼。这并非随机的机会主义攻击，而是一次有组织的、国家支持的行动，其目标明确指向 npm 生态系统中最广泛使用的软件包之一。
维护者愿意坦诚分享事件经过，这需要极大的勇气。如此高明的社会工程攻击手段足以蒙蔽任何人。他们通过公开攻击途径，帮助整个开源社区了解威胁并采取措施保护自身安全。我们对此深表敬意。
大局观
axios 的入侵并非孤立事件。过去一年，我们的团队检测并应对了一系列重大供应链攻击，包括tj-actions/changed-files、 Shai-Hulud （涉及 780 多个 npm 包）、 TeamPCP/Trivy、 Checkmarx KICS和 LiteLLM。攻击频率正在加快，而 axios 攻击紧随其后的是 2026 年 3 月发生的另外三起重大事件。 ********************
这些攻击都展现出日益精湛的复杂程度。以 axios 攻击为例，它预先设置了诱饵依赖项，在当前分支和旧分支上精准地定时发布代码，进行设备指纹识别并投放平台特定的远程访问木马 (RAT)，并通过删除 GitHub 问题来主动实时压制社区警告。这种高超的操作技巧足以令所有工程组织深感警惕。
这些攻击具有共同的模式。它们的目标是开源软件赖以运作的信任关系：维护者凭证、发布令牌、持续集成/持续交付 (CI/CD) 流水线，以及用户对已依赖软件包新版本安全安装的假设。而且，这些攻击越来越多地被认为是拥有雄厚资源、耐心和强大安全保障的国家支持行为体所为。
我们衷心感谢 axios 维护者的透明度和韧性。我们感谢每一位在 GitHub 问题下留言、参与社区电话会议、分享发现并帮助他人了解自身是否受到影响的社区成员。我们感谢 GitHub 和 npm 迅速采取行动，暂停受感染的账户并移除恶意软件包。我们还要感谢更广泛的安全社区、研究人员、供应商、记者和开发者，感谢他们抽出时间传播信息，使得整个生态系统能够如此迅速且协调地应对此次事件。
供应链攻击并未放缓。恰恰相反，攻击速度正在加快，攻击者的技术也越来越高超。问题不在于下一次攻击是否会发生，而在于我们是否做好了准备。
回想起过去一周，最让我印象深刻的是我们这个小团队，成员分散在不同时区，实时对抗一个由国家支持的威胁组织。我为团队取得的成就感到无比自豪。在 StepSecurity，我们将继续研发、持续检测，并在最关键的时刻挺身而出。
