StepSecurity AI 包分析器和 Harden-Runner 在 axios 事件曝光前就检测到了该包的被篡改情况，这是 npm 历史上按下载量计算的最大规模单包供应链攻击。随后发生的是一场与某个国家级威胁行为者之间的竞速赛——该行为者积极删除 GitHub Issues 以压制警告——我们决定在午夜主持一次社区电话会议，吸引了 200 名参会者，并获得了 Bloomberg 到 Andrej Karpathy 的关注和报道。
axios 供应链事件已过去一周，我们想花点时间回顾一下。我们在事件期间发布了一份详细的 技术分析 博客，并持续对其进行更新。但人的故事——那个疯狂的夜晚、被删除的 GitHub Issues、午夜时分社区团结在一起——这部分还没有被讲述过。这就是那个故事。
axios 是 JavaScript 生态系统中使用最广泛的 HTTP 客户端，每周下载量超过 1 亿次，超过 1700 万个代码仓库和 24 万个包作为依赖。按下载量计算，这是 npm 历史上对单个包的最大规模篡改。一个国家级威胁行为者劫持了它，当我们创建一个 GitHub Issue 来警告社区时，他们删除了它。我们再次创建。他们再次删除。这种情况大约重复了 20 次。这不是一个随机的机会主义者。这是一次有协调的、国家支持的操作，专门针对整个 npm 生态系统中使用最广泛的包之一。这就是这一切如何展开的幕后故事。
警报响起
那是一个西雅图的周一夜晚。在持续响应了 TeamPCP/Trivy、Checkmarx KICS 和 LiteLLM 等备受关注的供应链攻击之后，我们希望能过一个安静的夜晚。
但事与愿违。
一旦被篡改的 axios 包发布到 npm，StepSecurity 的 AI 包分析器 就实时对其进行了分析，并返回了 严重 / 已拒绝 的判定。结论是明确的：这是合法 axios 库的恶意版本，显示出明显的供应链篡改迹象（通过包劫持）。自动化分析标记了六个不同的可疑指标，例如一个未文档化且未使用的依赖项（plain-crypto-js），该依赖项从未在源代码中的任何地方被导入；package.json 与内部版本数据之间的版本不匹配；缺少 CHANGELOG 条目；以及被丢弃的 provenance 证明。
StepSecurity Harden-Runner——我们专为 GitHub Actions 构建的端点检测和响应（EDR）代理——独立确认了分析结果。Harden-Runner 检测到来自已安装被篡改包的 CI/CD 运行器的异常出站网络调用，目标是 C2 域名 sfrclak.com。Harden-Runner 的网络级检测与 AI 包分析器的静态分析相结合，使我们在任何人审查代码之前就对该判定充满信心。
作为威胁情报能力的一部分，StepSecurity 运营着一个 7x24 小时的安全运营中心（SOC），并为关键检测集成了 PagerDuty。Ashish 是我们的联合创始人兼 CTO，那天晚上他轮值，是第一个收到警报的人。几分钟后，他交叉参考了 AI 包分析器的发现、Harden-Runner 的网络警报，并快速进行了人工代码审查，确认了自动化系统告诉我们的内容：axios 被篡改了。
StepSecurity 维护着 250 多个 GitHub Actions，主要使用 Node.js 编写，因此我们亲身体会到 axios 是多么无处不在。这件事的严重性立刻变得清晰。
Ashish 向我们的综合 Slack 频道发送了一条紧急消息，分享他的评估，并启动了事件桥接电话会议。
我正准备出门去超市购物时，Ashish 的消息出现在我们的 Slack 频道。我放下一切，急忙赶回来加入桥接电话会议。我们美国东海岸的客户支持团队正准备结束一天的工作。我们印度的同事则即将开始新的一天。几分钟后，来自不同时区的多名团队成员加入了通话。
验证未知
在公开发出警报之前，我们希望保持负责任的态度。我们有检测结果，对准确性充满信心，但在告诉全世界最广泛使用的 npm 包之一已被篡改之前，我们需要验证我们没有重复别人的工作，也没有遗漏可能改变局面的背景信息。
我们检查了 LinkedIn。检查了 X。搜索了其他软件供应链安全公司的博客。我们寻找任何可能表明已有人标记过此事的帖子、话题或供应商警报。我们什么也没找到。
据我们所知，还没有人发布关于这次篡改的信息，被恶意篡改的版本仍然可以在 npm 上供任何运行 npm install 的人下载。每过一分钟，就有更多开发者和 CI/CD 流水线拉取一个包，该包会在他们的机器上静默安装远程访问木马。由于没有其他人举起旗帜，我们需要采取行动。
发出警报
我们同时在多个方面推进。我们发布了威胁中心警报，并通过 Slack、Webhook 和 S3 集成向我们的企业客户发送通知，通知他们的安全运营中心团队，以便他们能够立即评估自己的暴露情况。这是我们标准事件响应工作流程的一部分：当我们 SOC 检测到关键供应链篡改时，我们的企业客户是第一时间知情者。
我们发布了一篇博客文章，其中包含我们发现的摘要，包括被篡改的版本（1.14.1 和 0.30.4）、注入的 plain-crypto-js 依赖项和 C2 域名。Ashish 在 LinkedIn 上发布了一份咨询，分解了关键的攻击指标，以便在开发者浏览他们的信息流时能看到警告。
然后 Ashish 转向 axios 的 GitHub 仓库，创建了一个 Issue 来与维护者合作，警告社区。
他还向 npm 报告被篡改的包为恶意软件，标记了 axios@1.14.1 和 axios@0.30.4，以及恶意的 plain-crypto-js 依赖项。
威胁行为者的反击
然后发生了我们意想不到的事情。当 Ashish 回到 GitHub 仓库查看他创建的 Issue 时，它已经消失了。被删除了。毫无痕迹。
威胁行为者不仅篡改了维护者的 npm 账户，还篡改了他们的 GitHub 账户。他们正在积极监控仓库，使用被篡改的账户静默删除每一个试图警告社区发生了什么事的 Issue。
Ashish 再次创建了 Issue。已经注意到不对劲的社区成员立即开始评论，分享他们自己的发现，提出问题，并从他们自己的分析中确认了篡改事件。几分钟后，Issue 又被删除了。
于是他再次创建。又被删除。又创建。又被删除。
每次 Ashish 创建 GitHub Issue，社区成员都会跳进来评论。每次，攻击者都会使用被篡改的维护者账户将其抹掉。每一次删除都证实了我们的怀疑：攻击者不仅有 npm token，还完全控制着维护者的 GitHub 账户，并正在积极监控仓库。
这种情况大约重复了 20 次。这是一场真正的实时拔河比赛——社区试图警告开发者，而威胁行为者试图隐藏篡改事件。
当这场猫鼠游戏在 GitHub 上演时，Ashish 还提出了一个 GitHub 账户滥用工单，解释说维护者的账户似乎已被篡改，并正被用于删除合法的安全咨询。GitHub 和 npm 支持都迅速采取了行动。GitHub 暂停了被篡改的维护者账户，停止了 Issue 删除操作，并阻止了该账户的任何进一步恶意操作。
npm 从 registry 中移除了恶意包，并对攻击者的辅助包施加了安全保留。
一旦被篡改的账户被暂停，GitHub Issue #10604 终于留住了。它成为社区恢复工作的中心线索，最终获得了超过 1100 个反应和来自世界各地开发者的 800 多条评论，分享攻击指标、补救步骤和他们自己的取证发现。
与社区合作
随着直接威胁得到控制，我们组织成子团队来处理下一阶段的响应。一个团队专注于为 StepSecurity 企业客户提供直接支持。另一个团队深入技术取证，记录完整的攻击链。第三个团队将注意力转向更广泛的开源社区。
StepSecurity Harden-Runner 的社区层对开源项目免费，目前被超过 12,000 个开源项目使用。Harden-Runner 洞察按设计对社区层用户公开，任何人都可以查看而无需登录。利用这些公开洞察，我们发现有多个开源项目在攻击窗口期间安装了被篡改的包。我们主动在被影响的仓库中创建了 GitHub Issues，通知他们的维护者，并链接到相关的 Harden-Runner 洞察页面，以便他们可以自己查看证据。
我们通过多个渠道收到了来自社区的问题：GitHub、LinkedIn、私信和电子邮件。开发者想知道他们是否受到影响，什么是攻击指标，删除 node_modules 并重新安装是否足够（事实是不够的）。
大约在太平洋时间午夜时分，我建议我们在周三上午 10 点（太平洋时间）主持一次社区电话会议，并设置了网络研讨会注册页面。老实说，我不确定会有多少人在这种通知下出席。令我们真正惊讶的是，反响非常热烈。472 人注册了，周三上午，200 名社区成员参加了现场通话。
这次通话很特别。这不仅仅是我们在展示发现。这是社区在实时分享、提问和互相帮助。参会者提出了有见地的问题，询问是否会有来自早期供应链事件中泄露凭证的二次潜伏攻击。一位社区成员将 Shai-Hulud 活动进行了类比，询问攻击者是否会像《沙丘 3》中的变形者一样，坐拥被盗凭证耐心等待后才发动攻击。有人询问冷却期政策与 CVE 驱动紧迫性之间的紧张关系：如果一个新包版本修补了关键漏洞，你如何在快速更新的需求和补丁本身可能被篡改的风险之间取得平衡？另一位参会者询问 C2 服务器是否可能根据第一阶段有效载荷收集的设备指纹数据提供不同的 RAT 变体。一位开发者分享说，他们的 Azure Kubernetes 集群安装了恶意版本，但他们的防火墙阻止了 C2 域名，并想知道这是否足够。社区成员指出了 Wiz 文章中的额外 C2 基础设施，而这是我们还没有看到的，我们因此用新的 IOCs 更新了博客文章。
我们自己在这次对话中学到了很多东西，加深了对事件的理解。网络研讨会提醒我们，最好的安全研究是协作的。你可以在 YouTube 上观看完整录像。
在整个事件过程中，我们随着理解的加深不断更新博客文章。它成为了一份活文档，随着社区分享给我们的每一个新发现而演进，从额外的 IOCs 到补救指导。
涟漪效应
看到更广泛的社区如此迅速地围绕这一事件团结在一起，既令人欣慰，也令人谦卑。
在 GitHub 上，Issue #10604 成为响应的实际协调中心。社区成员贡献了取证细节，分享了检测脚本，提出了关于补救的问题并回答了这些问题，帮助彼此评估他们的暴露情况。axios 项目的其他协作者夜以继日地工作，在被篡改的账户被暂停后恢复对该包的信任，发布干净版本并与用户群透明沟通。
很高兴看到其他软件供应链安全公司提高对这一问题的认识并贡献他们自己的分析。Datadog、Aikido、Wiz、Endor Labs、SafeDep、Socket、Huntress、Malwarebytes、Sophos 和 SANS 都发布了详细的报告和咨询，帮助在整个生态系统中放大警报。这就是安全社区应该运作的方式：每个人在他们能的时候贡献他们能贡献的。没有一家公司拥有完整的可见性，信息流动得越快，生态系统就能越快地响应。
媒体报道
我们非常感谢在这次事件期间 StepSecurity 获得的新闻报道。axios 攻击的规模意味着它远远超出了安全社区的范围，进入了主流技术报道领域。Bloomberg 报道了这一事件，将其带到企业领导层和董事会成员的关注中，他们可能不关注 npm 咨询，但会关注财经新闻。Dark Reading 发布了详细分析。TechCrunch 报道了朝鲜归因角度。CSO Online 称其为有记录以来影响最大的 npm 供应链攻击。
Hacker News、Bleeping Computer、The Register、Help Net Security、SC Magazine、VentureBeat 和 InfoQ 都发布了他们自己的报道。我们的博客文章在 Hacker News 上排名第一，在首页顶部停留了数小时。在威胁情报方面，Google 的威胁情报团队、Microsoft Security、Palo Alto Unit 42、Cisco Talos、Elastic Security Labs 和 Datadog Security Labs 都发布了深入的 技术分析 和检测指南。
Andrej Karpathy 在 X 上分享了我们的博客。拥有超过 400 万订阅者的热门 YouTube 频道 Fireship 在他们对事件的报道中重点介绍了我们的技术分析。像这样的时刻提醒我们这样的小团队，工作是重要的。
社区确认
在事件发生后的几天里，被篡改的维护者本人在 GitHub Issue #10604 上发布了一条详细的评论，确认了发生的事情。他们受到了一场高度复杂的 社会工程攻击 的 targeting。一个伪装成合法公司创始人的人接近他们，发起了一个看似正常的开源协作机会。攻击者创建了一个假 Slack 工作区，打造成所谓公司的品牌，设置了 CI 基础设施使协作显得真实，并在 Microsoft Teams 上安排了视频通话。在通话中，他们使用假错误信息欺骗维护者下载一个"修复程序"，而实际上是一个远程访问木马。
通过这个 RAT，攻击者获得了维护者机器的访问权限，并窃取了一个长期有效的 npm 访问 token。这个 token 允许他们直接发布被篡改的 axios 版本，绕过了项目原本需要发布来自可信 CI/CD 环境的 OIDC 发布控制。攻击者还获得了维护者的 GitHub 账户访问权限，他们用这个账户删除了我们创建来警告社区的 Issues。
Google 的威胁情报团队随后将这次攻击归因于朝鲜威胁行为者 UNC1069。Microsoft 威胁情报独立将其归因于 Sapphire Sleet，这是他们对同一个朝鲜国家级组织的命名。这不是一个随机的机会主义者。这是一次有协调的、国家支持的操作，专门针对整个 npm 生态系统中使用最广泛的包之一。
维护者愿意分享发生的事情需要真正的勇气。如此复杂的社交工程攻击可以愚弄任何人。通过对攻击载体保持透明，他们帮助整个开源社区了解威胁，并采取措施保护自己。我们对此深表敬意。
更广阔的图景
axios 篡改事件并非孤例。在过去的一年里，我们的团队已经检测并响应了一系列重大供应链攻击，包括 tj-actions/changed-files、Shai-Hulud（780+ 个 npm 包）、TeamPCP/Trivy、Checkmarx KICS 和 LiteLLM。频率正在加速，axios 攻击紧随 2026 年 3 月另外三起重大事件之后。
每一起攻击都显示出越来越高的复杂性。axios 攻击——带有预先设置的诱饵依赖项，跨当前和遗留分支精确计时的发布，其设备指纹识别和平台特定 RAT 传递，以及通过删除 GitHub Issues 积极实时压制社区警告——代表了一种运营手法的水平，应该让每个工程组织都停下来思考。
这些攻击有一个共同模式。它们针对的是使开源工作得以进行的信任关系：维护者凭证、发布 token、CI/CD 流水线，以及对新版本的包——你已经依赖的——可以安全安装的假设。而且它们越来越被归因于具有大量资源、耐心和运营安全的国家级行为者。
我们感谢 axios 维护者的透明和韧性。感谢每一个在 GitHub Issue 上发表评论、加入我们的社区电话会议、分享他们的发现并帮助他人了解他们是否受到影响的社区成员。感谢 GitHub 和 npm 迅速采取行动暂停被篡改的账户并移除恶意包。感谢更广泛的安全社区、研究人员、供应商、记者、抽出时间传播信息的开发者，使生态系统对这次事件的响应尽可能快速和协调。
供应链攻击不会放缓。如果有的话，步伐正在加速，对手也在变得越来越好。问题不是下一个攻击是否会发生，而是当它发生时，我们是否准备好了。
当我回顾过去一周时，留在我心中的是我们这个小团队，分布在不同时区，在实时对抗一个国家级威胁行为者。我为我们团队取得的成就感到非常自豪。在 StepSecurity，我们将继续构建、继续检测、在最重要的时刻继续出现。