八个月内，同样的 npm 蠕虫攻击剧本竟然三次奏效。不同的攻击者，不同的软件包，相同的攻击机制，以及发布到被发现的相同时间窗口，使得每次攻击都成为可能。如果你想知道 npm 蠕虫究竟是什么，以及为什么这种模式不断重复出现而不是被修复，这就是实话：事件、机制，以及即使是强大的防御框架仍然存在的漏洞。
什么是 npm 蠕虫？
npm蠕虫是一种发布到npm注册表中的恶意代码，一旦运行，它就会自动传播到其他软件包。通常，它会窃取维护者的发布凭据，并利用这些凭据将相同的有效载荷注入到该维护者控制的每个软件包中。它符合“蠕虫”的经典定义：它无需等待用户主动安装，而是以机器速度自行传播，从一个软件包传播到另一个软件包，从一个账户传播到另一个账户。
这种自我传播能力正是 npm 蠕虫病毒与普通恶意软件包之间的区别所在。单个恶意软件包如同大海捞针，而 npm 蠕虫病毒会将每个受感染的维护者变成新的传播点，大海捞针也会随之产生新的传播源。
迄今为止最大的 npm 蠕虫事件
过去一年，npm 蠕虫模式经历了三次实际测试，每一次都比上一次更加高效：
- Shai-Hulud（2025 年 9 月）。 这是第一个有记录的能够自我传播的 npm 蠕虫。它窃取了维护者的凭证，然后利用这些凭证发布了该维护者控制下的每个软件包的恶意版本，使开发者自身成为了蠕虫下一阶段的传播机制。
- axios（2026 年 3 月）。 隐藏在软件包中的国家级恶意软件每周被下载约 100 亿次。虽然严格意义上来说它并非蠕虫病毒，但这证明了 Shai-Hulud 利用的 npm 生态系统信任模型能够真正大规模地传播有效载荷。
- SAP npm（2026 年 4 月）。 当时被描述为小型沙伊胡鲁德虫灾：同样的蠕虫模式，在最初事件发生不到一年后大规模重现。其机制没有改变，防御措施也基本没有改变。
三起 npm 蠕虫事件 一个重复的图案：攻破受信任的发布者，利用他们的凭证自动传播，并依靠发布和社区检测之间的差距来完成剩下的工作。
重复出现的模式
抛开具体细节，所有 npm 蠕虫事件都遵循相同的四个阶段：
- 账户被盗用。 维护者的发布令牌，npm login或者 CI 凭证被盗，通常是通过网络钓鱼、泄露的密钥或自身链上层依赖项遭到破坏等方式。
- 无声注射。 攻击者会推送一个合法、受信任的软件包的新版本，其中添加了恶意代码，通常是在安装后脚本或其他生命周期脚本中，这些脚本会在用户安装软件包时自动运行。
- 自动传播。 如果被入侵的维护者控制了其他软件包，或者恶意脚本本身收集了更多凭据，那么蠕虫就会传播到下一个软件包和下一个维护者，而无需攻击者采取进一步行动。
- 检测延迟。 该软件包会一直存在于注册表中，任何人都可以安装，直到有人发现并举报，然后被移除。这段时间，有时需要几个小时，有时则需要几天，正是蠕虫病毒传播所需的全部时间。
认识到第四个检测延迟才是防御的关键所在。所有针对 npm 蠕虫病毒事件的缓解策略，其核心都是为了缩短或绕过这个检测延迟。
值得引用的框架：SIP 对冷却问题的解答
并非所有对这种模式的回应都来自供应商。其中最明显的回应之一是： SIP，穆罕默德·阿里·阿拉比的安全应急计划这是一个针对软件供应链风险的五项控制应急框架，源于 SafeDev 会议结束时提出的一个非常实际的问题：“如果我们只能做几件事，我们应该首先做什么？”
SIP 的第二个控制措施直接针对 npm 蠕虫问题：冻结未经审查的依赖项，设置五天的冷却期，并禁用生命周期脚本，以防止恶意安装后脚本在安装过程中自动执行。实际上，这…… min-release-age=5 和 ignore-scripts=true 在一个项目的 .npmrc在持续集成 (CI) 中强制执行，以防止锁定文件悄悄解析昨天发布的软件包。这是一种真正可靠且低成本的控制措施，它直接针对 npm 蠕虫病毒事件所依赖的同一检测延迟问题。深入了解：
冷却时间窗口仍然存在缺口
冷却期是一种赌注：社区会在等待期结束前发现并举报恶意软件包。大多数情况下，这种赌注都会奏效。相当一部分被入侵的软件包会在发布后的最初几天内被标记出来，这正是五天窗口期是一个合理默认值的原因。
但是 npm 蠕虫的行为与典型的恶意软件包不同，这改变了固定冷却时间能为你做什么和不能做什么。
即将cis关于速度： 快速传播的蠕虫病毒实际上并不能绕过冷却时间。如果严格限制最低发布年龄，那么在最初阶段发布的软件包仍然太新，无法进入构建版本，无论蠕虫病毒在此期间感染了多少软件包。速度固然重要，但它对下游所有未启用冷却时间的开发者而言才重要，而不是对已经强制执行的冷却时间的突破。
真正的限制在于耐心。 更安全的载荷可以在冷却期过后保持休眠状态，只有在几天过去且包裹进入“可信”区域后才会激活。cis正是因为它知道冷却时间正在运行。在这种情况下，仅仅依靠固定冷却时间是不够的，而像MEW的基于证据的检测机制就需要与它配合使用，而不是取而代之。
这两种失效模式都不是SIP设计思路的缺陷。冷却机制是一种依赖社区检测的策略，而社区检测存在一个下限：它无法检测到尚未被报告的问题。这并非SIP独有的缺陷，而是任何在收到签名、安全公告或公开报告后才采取行动的防御机制都存在的结构性局限性。
MEW如何缩小冷却时间窗口差距
这是预cis差距 Xygeni 的恶意软件预警 (MEW) MEW 的设计理念是封闭式防御。它不会等待社区报告或已发布的签名，而是持续扫描 NPM、PyPI 和 Maven，在新软件包和版本发布时进行扫描，分析其行为而非与已知威胁进行比对。一旦发现可疑内容，MEW 会将其隔离，并在公开披露之前，由安全研究人员确认其发现，而不是事后披露。
上述两种 npm 蠕虫失效模式的关键在于区分它们。对于快速传播的蠕虫，预签名检测不需要像冷却期假设的那样等待五天。而对于缓慢潜伏的有效载荷，MEW 的行为分析并非着眼于代码的“年龄”或“信誉”，而是关注代码的实际行为，因此等待冷却期结束对攻击者来说毫无益处。
MEW 的依赖防火墙将这种防护扩展到了安装阶段本身，即使恶意软件包绕过了之前的检查，也能实时阻止它，而且同样的检测层也覆盖了…… CI/CD npm蠕虫事件的一个侧面：解锁分支、注入、重新锁定的模式，这种模式允许攻击者推送恶意程序。 commit 他们会悄悄掩盖自己的行踪，如果还是发生了，也会留下完整的审计记录。
SIP 和 MEW 在不同的层面上回答同一个问题。
这并不意味着SIP的冷却控制机制有问题，而且值得明确指出的是：禁用生命周期脚本的五天冷却期仍然是团队能够采取的最快捷、最经济的防御措施之一，可以有效应对常见的npm蠕虫攻击，并且应该纳入任何严肃的供应链加固计划中。但它的设计初衷是无法捕获社区尚未发现的问题。这需要持续的、基于行为的检测机制来执行，而不是取代冷却期本身。
这两种方法结合起来，解决了同一个问题的两个方面：SIP 增强了构建的安全性。 pipelineMEW 的预签名检测涵盖了尚未公开的 npm 蠕虫事件，这些事件是冷却窗口自身逻辑无法预见的。
常见问题解答
用一句话概括什么是 npm 蠕虫？
发布到 npm 的恶意代码会自动传播到其他软件包，通常是通过窃取维护者的凭据并使用这些凭据在其他地方注入相同的有效载荷，而无需攻击者采取进一步行动。
每个恶意 npm 包都是 npm 蠕虫吗？
不。不会自行传播的恶意软件包属于供应链攻击，但不是蠕虫。npm 蠕虫事件的定义在于其自我传播的步骤：一次入侵会自动导致下一次入侵。
依赖项冷却期能否阻止 npm 蠕虫病毒？
由于大多数恶意软件包会在发布后的最初几天内被报告，因此这种方法可以显著降低风险。但冷却期是对社区检测速度的押注，而快速传播或故意休眠的 npm 蠕虫病毒可以专门针对这一检测窗口进行构建。
什么方法能在冷却期之前捕获 npm 蠕虫？
持续的、基于行为的扫描，无需依赖已存在的签名或公开报告。这正是像 Xygeni 的 MEW 这样的签名前检测工具旨在弥补的空白。
