TL博士
恶意 npm 包并非偶发事件，而是一个持续不断的发布过程，已确认的案例列表每周都会更新。 在我们连续七期恶意代码摘要（现已超过第 87 期）中，Xygeni 都证实了这一点。 635 个恶意软件包平静一周的病例数为 13 例，繁忙一周的病例数则高达 206 例。重点在于每周的病例数波动范围：这是一种规律，而非个别事件。
- 节奏是问题所在。 一个软件包在一周内从零个版本跃升至超过 55 个版本。另一个集群在不到三个小时内发布了近 30 个软件包名称。每周审核一次显然是不合适的时间单位。
- 它们并非以 CVE 的形式出现。 恶意软件包并非合法代码中的缺陷，因此不会发布任何安全警告、评分，通常也没有任何标识符。漏洞驱动型程序在结构上对此视而不见。
- 制服对手并非保护。 软件包通常只能存活几分钟到几小时。您的安装要么在这个时间段内完成，要么没有完成。
- 检测必须在发布时进行，强制执行必须在安装时进行。 任何需要签名、CVE 或每周扫描才能更新的内容，都会在提取它的版本之后发布。
名单确实存在。但这与被监视是两回事。
恶意 npm 包并不神秘。每周都会有已确认的案例被发布、命名和记录，包括在…… Xygeni 的恶意代码摘要现已出版至第八十七版。
问题不在于信息，而在于关注度和节奏。一份每周更新、每月阅读、每季度采取行动的清单，记录的是某人已经经历过的事情。
以下是根据我们自己确认的调查结果（而非供应商调查）得出的七周情况。
重要的不是总数，而是每周的节奏。
速度就是进攻的全部意义
那几周我们发现了三件事，每件事都是一种逃避审查的不同方法。
- 版本泛滥。 单个 npm 包，
zevairouter一周内，该软件包的已确认版本超过 55 个，此外，配套软件包还新增了 10 个版本。在 PyPI 上，bingo-ai大约30分钟内生成了近80个版本。任何人工审核流程都达不到这个速度，夜间例行工作也做不到。 - 同步集群。 短短几分钟内，就有17个冒充PayPal内部服务名称的软件包发布，版本号均为28.0.0。这并非数量上的差异，而是一场竞赛：虚高的版本号旨在超越你们团队自己编写的内部软件包。几周后，同样的伎俩再次出现。
@umschool/platform发布于 999.0.0。 - 坚持不懈，直至最终胜利。 针对 Baileys 的冒充活动已经持续数周。名称不断变化，版本层出不穷，即使被发现也依然继续发布。如果运营商将下架视为经营成本而非停止运营的理由，那么你每季度一次的审查永远也无法彻底清除其漏洞。
而且，数据包的停留时间是经过精心设计的。在最近的一次集群测试中，这些数据包在被移除前存活了17分钟到13个小时不等。
将其理解为注册表的暴露窗口，而非性能指标。如果在此期间运行了构建，则下架操作不会产生任何影响。
为什么您的漏洞利用程序看不到这一点
这是结构性问题，也是大多数安全团队尚未真正理解的问题。
漏洞是指某人出于善意编写的代码中存在的缺陷。恶意软件包则是攻击者故意发布的恶意程序，通常没有标识符、没有安全公告，其生命周期以小时计。所有围绕 CVE 漏洞收集、严重性评分和补丁窗口构建的流程最初都是针对漏洞而设计的，但默认情况下也适用于恶意软件包。
CVE系统中缺少标识符并非疏忽，而是该分类的预期运作方式：没有人会针对一个完全出于恶意目的的软件包提交安全公告，而等到有人提交时，该软件包早已被删除。这意味着问题“这个漏洞有CVE编号吗？对于干净的软件包和一小时前发布的凭证窃取程序，返回相同的答案。
有效载荷现在实际执行的操作
人们通常认为恶意 npm 包就是加密货币挖矿程序。但实际上，它们主要针对开发者窃取凭证，而且越来越多地针对开发者机器上的 AI 凭证。
此 PhantomSync 集群，八个发布在同一账户下的 npm 包，完全按照宣传的那样运行，同时隐藏了一个自调用投放器，该投放器在导入后大约 37 秒触发，解码了一个伪装成虚假测试装置的 payload，安装了跨平台持久化程序，并启动了一个钱包和密钥窃取器。延迟、伪装、持久化、窃取。
从更大尺度来看，CHAINDROP 波 夏胡鲁德蠕虫 截至2026年8月初，该软件包已超过400个，版本超过1,700个，月下载量总计达1.3亿次。其收集器扫描了300多种凭证模式，包括OpenAI、Anthropic和Cursor密钥。开发者机器在早期阶段变得极具价值。cis主要是因为他们拥有优秀的模特资质。
命名规则随着资金流向而改变。最近出现的一些集群模仿加密货币和 DeFi SDK、支付模块、WhatsApp API 库、AWS 工具，甚至在某个案例中，一个软件包的名称直接取自一款暗黑 LLM 攻击工具。
究竟是什么阻止了恶意 npm 包？
四个控制点，按其发挥作用的顺序排列。
1. 在发表时发现，而不是在披露时发现。 Xygeni 的恶意软件早期预警 它会在软件包发布的第一时间，即通过行为分析和异常分析，而非等待签名或报告，对 npm、PyPI、Maven 和其他注册表中新发布的软件包进行分析。这是时间线上唯一一个先于您的构建的时间点。
2. 在安装地点进行执法。 检测结果会提示某个软件包是恶意的。阻止安装的策略会阻止安装后脚本运行。现在代理程序会在未经人工选择的情况下安装依赖项，这一点显得尤为重要。
3. 锁定文件和哈希固定。 绝大部分储备使用 npm ci 在 CI 中而不是 npm install因此，最终构建的正是 lockfile 中指定的依赖关系树。这堵住了 typosquat 和膨胀版本所依赖的替换路径。
4. 将调查结果汇总在一起。 恶意软件检测结果应与您的检测结果处于同一优先级队列中。 SCA 并且要提供代码发现结果，而不是放在单独的信息流中供人浏览。已确认的恶意依赖项的优先级应该高于中等严重程度的 CVE 编号，而只有共享的风险模型才能实现这种比较。
常见问题解答
什么是恶意 npm 包？
发布到 npm 注册表的软件包是故意构建来造成危害的：凭证和钱包窃取程序、后门程序、投放程序以及模仿内部或流行软件包名称的依赖项混淆程序。
恶意 npm 包有多常见？
持续不断。在最近七期恶意代码摘要中，Xygeni 确认了 635 个恶意软件包，数量从平静时期每周约十几个到活跃攻击期间的 200 多个不等。其中绝大多数是 npm 包。
恶意 npm 包可以保留多久？
通常只需几分钟到几小时。这个时间窗口至关重要，因为无论之后移除软件包的速度有多快，在此期间运行的构建都会受到影响。
恶意 npm 包会被分配 CVE 编号吗？
通常不会。它们是攻击者发布的漏洞利用程序，而不是合法代码中的缺陷，而且追踪到的 2026 个攻击活动在实际利用期间都没有获得 CVE 编号。
如何在安装前检查软件包是否恶意？
使用在发布时分析软件包的工具，而不是检查已知不良列表的工具；验证发布者和版本历史记录；对异常高的版本号和新帐户保持警惕；并在安装时强制执行策略，而不是依赖审查。
什么是依赖关系混乱？
发布一个与内部软件包同名的公共软件包，通常还会使用经过篡改的版本，以便解析器优先使用攻击者的副本。PayPal 名称集群的 28.0.0 版本就是一个典型的例子。
