npm 软件供应链威胁全景：从 Shai-Hulud 蠕虫到 Miasma 持久化 RAT（Unit 42 持续追踪）

发布于 2026-07-28

Unit 42 梳理 2025 年 9 月以来 npm 供应链攻击的演进：自传播蠕虫 Shai-Hulud、Mini Shai-Hulud 多波次活动，到 2026 年 6–7 月 Red Hat 与 AsyncAPI 的 Miasma RAT 投毒，呈现可蠕虫化、基础设施级持久化与多阶段负载三大趋势。

📖 原文翻译与解读。原文：The npm Threat Landscape: Attack Surface and Mitigations（Unit 42 (Palo Alto Networks)，2026 年 7 月 15 日（更新））

一、执行摘要

2025 年 9 月，自复制恶意包 Shai-Hulud 的出现标志着 npm 攻击进入「高后果」时代，取代了以往零星的 typosquatting（错别字抢注）。此后 Unit 42 观察到供应链攻击在频率与技术深度上急剧加速，从孤立事件演变为有组织的系统性战役，目标是武器化现代软件开发所依赖的信任关系。

后 Shai-Hulud 时代，攻击者战术（TTP）出现三大核心转变：

可蠕虫化传播：恶意负载优先窃取 npm token 与 GitHub PAT，自动感染并重新发布合法包（如 2026 年 3 月 Axios 失陷）。
基础设施级持久化：攻击方不再仅窃取数据，而是嵌入 CI/CD 流水线，获取对企业环境的长期、隐蔽访问。
多阶段负载：当前攻击常部署休眠「sleeper」依赖，仅在特定环境条件下激活以规避自动扫描。

二、关键战役时间线

2026 年 4 月（Mini Shai-Hulud 新波次）：通过四个失陷的 npm 包攻击 SAP 开发者生态（@cap-js/*，合计约 57 万周下载量），沿用与 Bitwarden CLI 投毒相同的工具链；4 月 22 日 Bitwarden CLI 投毒事件中，恶意包在约 1.5 小时窗口内分发，通过 preinstall 钩子窃取云凭据、CI/CD 密钥并自我传播。

2026 年 5 月（TanStack 流水线劫持）：TeamPCP 借助三个 GitHub Actions 弱点链式利用，6 分钟内于 42 个 @tanstack/* 包发布 84 个恶意制品，全天达 169 个 npm 包、373 个恶意版本，跨 Mistral AI、OpenSearch、UiPath 等生态；并首次实现「无需被盗凭据」的初始访问，以及首个带有效 SLSA 来源证明的恶意 npm 包。

2026 年 6 月（Red Hat Miasma）：至少 32 个 @redhat-cloud-services 命名空间下的包被投毒（恶意版本合计约 8 万周下载量），根因为 Red Hat 员工 GitHub 账户失陷，绕过代码评审直接推送。

2026 年 7 月 14 日（AsyncAPI Miasma-train-p1）：攻击者攻陷四个核心 AsyncAPI GitHub 仓库的发布流水线，发布 5 个木马化包（@asyncapi/generator、@asyncapi/specs 等）。与 6 月不同，此次初始访问来自 CI/CD 流水线自身的流程缺口——未受保护的 pre-production 分支（next、schema）被直接推送恶意提交，触发自动化构建并窃取 NPM_TOKEN、GITHUB_TOKEN。开发者即便不手动 npm install，工具（如 GitHub Copilot 自动加载依赖）也会代为执行，静默拉起 Miasma RAT。

三、Miasma RAT 的规避与韧性

Miasma 变种架构升级：开发者 npm install 时，被植入的源文件（如 index.js、validator.js）导出看似合法的 schemas 对象，导入时却触发混淆加载器，从 IPFS 拉取 Stage-2 RAT 并以分离进程持久化。其 C2 极具韧性：主 C2 被封后，依次回退至以太坊 RPC 上的链上智能合约（去中心化 C2 注册表）、Nostr 中继、BitTorrent DHT，单一层封禁无法清除植入。

四、防护与缓解建议

引入冷静期：通过私有仓库或代理（如 Artifactory）屏蔽近 24–72 小时内发布的包版本，多数恶意包会在此窗口内被识别下架。
禁用生命周期脚本：在 .npmrc 设置 ignore-scripts=true，阻断 preinstall/postinstall 外泄。
版本锁定与 npm ci：使用 package-lock.json，CI/CD 用 npm ci 而非 npm install，防止构建期「隐藏」升级。
私有仓库代理：开发机与 CI runner 不直接访问 registry.npmjs.org，全部经私有仓库路由。
命名空间遮蔽：内部库一律使用域限定包（如 @myorg/internal-lib），私有仓库仅内部解析该域。
来源证明校验：用 slsa-verifier 等工具在构建期验证 OIDC Attestation——但需注意：来源证明只确认「由哪条流水线构建」，不证明「流水线内部状态干净」，因此安装期行为分析仍不可或缺。
CI/CD 出站过滤：将 CI runner 出站严格限制到私有仓库与已知部署目标，阻断 ~/.npmrc、~/.ssh 外泄。
SBOM：为每个生产版本自动生成 SBOM，便于新零日公布时即时影响分析。

五、邮件系统与开发运维防护启示

软件供应链已成攻击者首选目标，而邮件安全团队并非局外人：① 开发者凭据（npm token、GitHub PAT、SSH key）一旦经恶意包外泄，常被直接用于向邮件网关、代码托管与部署系统横向移动；② 将 CI/CD 凭据与邮件系统凭据隔离管理，强制使用短时、最小权限的部署令牌，并启用 2FA 或硬件密钥；③ 在邮件安全网关对来自开发者机器、CI 网络的异常外联（指向 C2、云存储、代码托管）做告警与阻断；④ 把「依赖投毒」纳入安全意识培训——诱饵常以「紧急修复」「热门库升级」名义通过邮件或 IM 诱导开发者执行安装。

参考来源

了解更多行业资讯，请访问行业资讯首页或致电 021-69753778 获取安全咨询服务。

—— ztpop.net 编辑团队译