🐛 Shai-Hulud：npm生态的自我复制蠕虫风暴
紫禁玄科 · 2026年08月11日 · 阅读约15分钟
#供应链安全#npm恶意软件#Shai-Hulud蠕虫
📌 **导读：**2026年，开源供应链安全形势急剧恶化------npm生态爆发了史上首个真正意义上的自我复制蠕虫Shai-Hulud，从Axios到Red Hat，从PyTorch Lightning到TanStack，数百个核心包被感染，周下载量超26亿次。本文深度剖析蠕虫传播机制、五大攻击波次复盘、以及开发团队的实战防御方案。
2026年3月31日，一个看似平常的周一，全球数百万开发者像往常一样在终端敲下npm install axios。然而他们不知道的是，这个每周下载量高达1亿次、被17.4万个依赖包引用的JavaScript基础库，已经变成了一台精密的恶意软件投递机器。在被发现并下架之前的短短三个小时内，至少135个端点连接了攻击者的C2服务器，恶意代码如同病毒一般渗透进了全球无数CI/CD流水线。
这仅仅是2026年npm供应链攻击浪潮的序幕。在随后的四个月里，一个被称为"Shai-Hulud"（沙丘巨虫）的自我复制蠕虫，在npm和PyPI生态系统中掀起了至少五次大规模攻击波次，感染了超过800个软件包，累计影响周下载量超过26亿次。更令人不安的是，攻击者来自至少六个有组织的威胁团伙，其中包括被归因于朝鲜的国家级APT组织。
这不是一次孤立的安全事件，而是开源软件供应链安全范式的根本性转变------从偶发的、依赖人工投毒的"恶作剧式"攻击，进化为自动化、蠕虫化、工业化的系统性威胁。
Sonatype 2026报告 · 核心数据
1,233,000+
累计恶意开源包被拦截，同比增长75%
图1：开源软件供应链攻击传播路径------从维护者账号到全球CI/CD流水线
一、Shai-Hulud：从沙丘到代码库的致命巨虫
"Shai-Hulud"这个名字源自弗兰克·赫伯特的科幻巨著《沙丘》中的巨型沙虫------一种在沙漠中自由穿行、不可阻挡的生物。用它来命名npm历史上第一个真正意义上的自我复制蠕虫，可谓恰如其分。
2025年9月，Shai-Hulud首次被安全研究人员发现。与以往依赖人工投毒的供应链攻击不同，这个蠕虫具备了完整的自动化感染链：它通过精心伪装的npm安全警报钓鱼邮件获取维护者的npm和GitHub凭证，然后利用这些凭证自动感染并重新发布合法包的新版本，同时部署密钥扫描工具发现更多凭证，形成自我传播的正反馈循环。
⚠️ 关键机制：Shai-Hulud在
preinstall阶段触发执行，这意味着它能在大多数安全防御机制介入之前就开始运行。当它发现没有有效凭证可窃取时，会转而进入破坏模式，像勒索软件一样篡改本地文件。
Shai-Hulud的出现标志着npm威胁格局的根本性转变。正如Palo Alto Networks Unit 42团队所言："2025年9月的Shai-Hulud事件并非暂时的威胁尖峰，而是软件供应链风险的新基线。"
二、2026年五大攻击波次全复盘
从2026年3月到7月，Shai-Hulud及其变种在短短五个月内发起了至少五次大规模攻击。每一次都比前一次更加精密、更加隐蔽、影响范围更广。下面我们逐一复盘。
📋 第一波：Axios劫持事件（2026年3月31日）
📅 **时间：**2026年3月31日
🏢 **受影响包：**axios --- 周下载量1亿次，174,000个依赖包
⚔️ **攻击方式：**归因于朝鲜国家级APT组织。攻击者窃取维护者的npm和GitHub凭证，发布携带跨平台远程访问木马(RAT)的恶意版本
⏱️ **窗口期：**恶意版本存活约3小时，但已至少有135个端点连接了C2服务器
📝 **教训：**即便是最广泛使用的JavaScript基础库，也可能在维护者凭证泄露后瞬间沦为攻击载体。"npm install"不再是一个安全的操作
📋 第二波：SAP生态与PyTorch Lightning（2026年4月底）
📅 **时间：**2026年4月29日 - 4月30日
🏢 **受影响方：**SAP开发者生态系统npm包、PyTorch Lightning
⚔️ **攻击方式：**被称为"Mini Shai-Hulud"的新变种，针对SAP开发者社区的四个npm包发起定向攻击。次日又感染了PyTorch Lightning
📝 **教训：**攻击者已从"广撒网"转向"精准打击"企业级开发工具链，SAP和PyTorch这类企业级框架成为高价值目标
📋 第三波：TanStack/Mistral AI/UiPath大爆发（2026年5月11-14日）
📅 **时间：**2026年5月11日 - 5月14日
🏢 **受影响方：**TanStack、Mistral AI、UiPath等160+个npm/PyPI包
⚔️ 攻击方式： 威胁组织TeamPCP的杰作。攻击者fork了TanStack/router仓库，提交恶意PR触发pull_request_target工作流，投毒GitHub Actions缓存。恶意包使用合法OIDC token发布，携带有效的npm来源证明(provenance)
💰 **影响规模：**373个恶意包版本，跨越169个npm包名和2个PyPI包。node-ipc恶意版本周下载量超1000万次
📝 **教训：**此次攻击颠覆了一个关键假设------npm的provenance证明机制不再是安全信号。恶意包拥有合法的来源证明，传统的信任链彻底断裂
📋 第四波：Red Hat命名空间沦陷（2026年6月1日）
📅 **时间：**2026年6月1日
🏢 受影响方：@redhat-cloud-services命名空间下32个npm包
⚔️ **攻击方式：**攻击者通过泄露的员工GitHub账号入侵Red Hat的Hybrid Cloud Console JavaScript生态系统。恶意版本周均下载量约8万次
📝 **教训：**即便是Red Hat这样的开源巨头，其内部员工账号管理也可能成为供应链安全的阿喀琉斯之踵
📋 第五波：Miasma与Hades变种横跨npm/PyPI（2026年6月-7月）
📅 **时间：**2026年6月5日起持续至7月底
🏢 **受影响方：**npm上57+个包（Miasma变种）、PyPI上29+个包（Hades变种）、AsyncAPI核心仓库
⚔️ 攻击方式： Miasma利用武器化的binding.gyp文件绕过postinstall执行逻辑。Hades在PyPI端使用*-setup.pth文件在Python启动时执行恶意代码，下载Bun JavaScript运行时后执行JS载荷
📝 **教训：**攻击者正在突破npm单一生态的限制，向PyPI、VS Code扩展市场、Go模块等多元包管理器扩展。跨生态联合防御已成刚需
图2：Shai-Hulud蠕虫的自我复制传播链------凭证窃取→包重新发布→新一轮感染
三、技术深度拆解：蠕虫是如何工作的
要真正理解Shai-Hulud的威胁本质，我们需要深入其技术内核。这个蠕虫的精妙之处在于它将传统的供应链投毒技术与自动化凭证窃取、自我传播机制完美融合，形成了一个几乎不需要人工干预的攻击闭环。
🔹 阶段一：初始入侵（Initial Access）
攻击的起点几乎总是钓鱼邮件。攻击者精心伪装成npm安全团队，发送包含"紧急安全通知"的邮件，诱导维护者点击链接并输入凭证。这些钓鱼页面使用AI生成，语法自然、格式专业，甚至会根据目标维护者的历史活动记录进行个性化定制，使得即便是经验丰富的开发者也难以辨别。
在第五波攻击中（Mini Shai-Hulud），攻击者甚至开发了一种不需要窃取凭证的全新初始访问技术------通过GitHub的pull_request_target工作流机制，直接投毒GitHub Actions缓存，使恶意代码通过合法的OIDC token发布，首次实现了带有有效SLSA来源证明的恶意npm包。
🔹 阶段二：凭证窃取（Credential Harvesting）
一旦恶意包被安装，载荷会在preinstall生命周期钩子中触发执行------这比大多数安全扫描器的检测窗口更早。窃取的凭证范围极其广泛：
1**npm/GitHub凭证：**npm token、GitHub Personal Access Token (PAT)
2**云平台凭证：**AWS凭据（通过IMDSv2）、GCP和Azure凭据、Kubernetes服务账号Token
3**密钥管理：**HashiCorp Vault Token
4**环境变量：**所有包含敏感信息的环境变量，包括API密钥、数据库密码等
🔹 阶段三：自我传播（Self-Propagation）
这是Shai-Hulud与传统供应链攻击最本质的区别。蠕虫利用窃取到的npm token和GitHub PAT，自动完成以下操作：
①使用npm token登录，获取当前维护者名下的所有包列表
②部署密钥扫描工具（如TruffleHog）在CI/CD环境中搜索更多token
③篡改这些包的package.json，在其中注入恶意依赖或直接修改源码
④自动发布新版本到npm注册表，触发新一轮感染
⑤被感染的包又感染其维护者的其他包，形成指数级扩散
💡 关键洞察：Shai-Hulud的行为模式酷似生物病毒------它不依赖"宿主"的有意识操作，而是利用自动化工具在"细胞"（软件包）之间被动传播。每一次
npm install都可能成为新的"感染窗口"。
四、六大威胁组织全景画像
根据Group-IB的研究报告，目前至少有六个有组织的威胁团伙活跃在npm、PyPI和MSP（托管服务提供商）供应链攻击领域。他们各有特色，形成了完整的攻击生态。
🔴 威胁组织一：朝鲜国家级APT
归因于Axios劫持事件的幕后黑手。其目标不仅是破坏，更是经济利益------通过窃取的加密货币和云资源获利。具有国家资源支撑，技术能力和持久性极强。
🟠 威胁组织二：TeamPCP
策划了TanStack/Mistral AI/UiPath大爆发的攻击组织。擅长利用GitHub Actions工作流缺陷进行初始入侵，技术手段在所有已知组织中最为先进。已至少发起三波独立攻击。
🟡 威胁组织三：Shai-Hulud原始作者
2025年9月首次部署Shai-Hulud蠕虫的组织。首次实现npm生态的真正自我复制传播，开创了蠕虫化供应链攻击的先河。在首轮攻击中即感染了180+个包，后扩展到约500个。
🟢 威胁组织四：Miasma/Hades运营商
开发了跨npm和PyPI的双生态攻击能力。Miasma通过weaponized binding.gyp文件绕过npm安全检测，Hades则使用Python启动文件实现持久化。两者实为同一组织的双线作战。
ReversingLabs 2025年度报告
90%
的所有检测到的开源恶意软件来自npm生态，同比增长超100%
五、为什么传统防御彻底失效了
面对Shai-Hulud及其变种，我们不得不承认一个残酷的事实：传统的软件供应链安全防线几乎全线失守。以下是几个关键的信任假设被颠覆的案例。
🔹 信任假设一：npm Provenance证明 = 安全？错了
npm的provenance机制曾被认为是供应链安全的"银弹"------它通过SLSA（Supply chain Levels for Software Artifacts）框架，为每个发布的包提供加密签名的来源证明，理论上可以验证包确实来自声明的代码仓库和构建流水线。
然而，在5月的TanStack攻击中，攻击者通过投毒GitHub Actions缓存，使恶意代码在合法的CI/CD环境中构建和发布。结果是：这些被感染的npm包拥有完全有效的provenance证明。npm团队不得不承认，provenance alone不是可靠的安全信号。
🔹 信任假设二：Lock文件能保护你？部分正确
package-lock.json确实可以锁定已安装包的版本，防止意外升级到恶意版本。但Shai-Hulud的蠕虫特性意味着，你依赖的包可能已经被感染------即使你没有升级，你的CI/CD环境中的开发者可能在不知不觉中安装了恶意版本，而他们的凭证可能已被窃取，进而感染你依赖的上游包。
🔹 信任假设三：知名包=安全包？大错特错
Axios（1亿周下载）、@ctrl/tinycolor（200万+周下载）、node-ipc（1000万+周下载）、Red Hat官方包------这些都是开发者社区中最受信任的包。攻击者恰恰瞄准的就是这些"信任锚点"，因为他们知道，越受信任的包被安装的频率越高，传播速度也就越快。
六、npm vs PyPI：防护能力差异显著
值得注意的是，PyPI在引入强制2FA和可信发布机制后，恶意包数量同比下降了43%，而npm的恶意包数量却同比增长了超过100%。这一鲜明对比说明了一个关键事实：攻击者不会"硬啃"安全防护，他们会绕过去。
1**npm：**占所有检测到的开源恶意软件的约90%（ReversingLabs数据）。恶意包数量同比增长超过100%，2025年Sonatype报告新增恶意包超45.46万个
2**PyPI：**恶意包数量同比下降43%。强制2FA和可信发布机制显著提高了攻击门槛，但Hades变种证明攻击者正在寻找新的绕过路径
3**NuGet：**恶意包数量同比下降60%，同样受益于安全加固措施
⚠️ 核心启示：安全措施确实有效，但攻击者会转向防护最薄弱的环节。npm的庞大生态、较低的安全门槛和丰富的CI/CD token暴露，使其成为当前供应链攻击的首选目标。当PyPI加固后，npm的恶意软件占比从此前的不到50%飙升至90%。
七、实战防御方案：从个人到企业的全栈防护
面对如此严峻的威胁态势，开发者和安全团队需要从多个层面构建纵深防御体系。以下是经过实战验证的防护措施。
🛡️ 开发者个人防护
①**启用npm 2FA：**为npm账号设置双因素认证，使用硬件安全密钥（如YubiKey）而非短信验证码。这是防止凭证被钓鱼窃取后直接利用的第一道防线
②使用npm audit + Socket.dev： 在每次npm install前运行npm audit，并集成Socket.dev的依赖分析工具，它可以检测异常的网络请求、环境变量访问等行为特征
③锁定依赖版本： 始终使用package-lock.json，并定期审查lock文件中的版本变更。考虑使用npm ci代替npm install，它会严格按照lock文件安装
④最小化依赖： 定期审查项目依赖，移除不必要的包。每一个依赖都是一个潜在的攻击面。使用npm ls --all查看完整依赖树，评估每个包的必要性
🛡️ CI/CD流水线防护
①**Token最小权限原则：**npm token和GitHub PAT应仅授予最小必要权限，设置过期时间，避免使用classic PAT而改用fine-grained token。CI/CD中的token应为只读且限定scope
②沙箱化安装： 在Docker容器或隔离环境中执行npm install，限制网络访问，禁止环境变量泄露。使用--ignore-scripts标志跳过生命周期钩子，然后手动审查需要运行的脚本
③监控异常发布： 设置告警机制，当项目依赖的包突然发布新版本（尤其是非预期的patch版本）时立即通知。使用npm outdated和Dependabot的自定义规则
④保护GitHub Actions： 审查pull_request_target工作流的使用，限制缓存写入权限，使用actions/dependency-review-action在PR阶段检测恶意依赖
🛡️ 企业级防护策略
①**建立私有npm镜像：**使用Verdaccio或npm Enterprise搭建私有注册表，所有依赖先经过安全扫描再进入内部仓库。这可以将供应链攻击的检测时间窗口从"安装时"提前到"入库时"
②**部署SCA工具：**使用Snyk、Socket、Semgrep Supply Chain等软件成分分析工具，持续监控依赖的健康状态。重点关注依赖的维护者活跃度、版本发布频率和安全审计历史
③**SBOM管理：**生成并维护软件物料清单(SBOM)，确保在供应链事件发生时能快速定位受影响的组件和系统。使用SPDX或CycloneDX格式
④**零信任网络访问：**对CI/CD环境实施零信任策略，限制出站网络连接，监控异常的DNS查询和HTTP请求模式。Shai-Hulud需要回传窃取的凭证------阻断C2通信可以有效遏制其传播
🔍 快速检测脚本：你的项目是否已受影响
📄 check-supply-chain.sh --- 检查项目依赖是否包含已知恶意版本
#!/bin/bash # 快速检查项目是否受到Shai-Hulud系列攻击影响 # 使用前请确保已更新npm audit数据库 echo "🔍 检查已知恶意包版本..." echo "================================" # 检查npm审计 echo "[1/4] 运行 npm audit..." npm audit --json 2>/dev/null | jq '.vulnerabilities | length' | \ xargs -I{} echo "发现 {} 个已知漏洞" # 检查可疑的生命周期脚本 echo "[2/4] 检查可疑的preinstall/postinstall脚本..." find node_modules -name "package.json" -exec grep -l \ '"preinstall"\|"postinstall"\|"prepare"' {} \; 2>/dev/null | head -20 # 检查异常的网络连接行为 echo "[3/4] 检查.env文件是否被引用..." grep -r "\.env\|process\.env" node_modules --include="*.js" \ -l 2>/dev/null | head -20 # 检查lock文件完整性 echo "[4/4] 验证package-lock.json完整性..." npm ls --json 2>/dev/null | jq '.problems | length' | \ xargs -I{} echo "发现 {} 个依赖问题" echo "" echo "⚠️ 如发现异常，请立即：" echo " 1. 撤销所有npm/GitHub token" echo " 2. 删除node_modules并重新安装" echo " 3. 检查CI/CD环境变量是否泄露"八、历史脉络：从event-stream到Shai-Hulud的进化之路
要理解今天的威胁有多么严峻，有必要回顾npm供应链安全的关键节点。从2018年的event-stream事件到2026年的Shai-Hulud风暴，我们可以清晰地看到一条攻击能力持续升级的进化曲线。
1**2018 · event-stream：**攻击者通过社交工程获取维护者权限，植入窃取加密货币的恶意代码。"经典"的单点投毒模式，手动操作
2**2021 · ua-parser-js/coa/rc：**攻击者批量劫持多个知名包，投毒范围扩大但仍为手动操作。开始出现"依赖混淆"等自动化投毒技术
3**2022 · node-ipc（抗议式投毒）：**包维护者主动注入破坏性代码以表达政治立场，暴露了"信任维护者"模型的脆弱性
4**2025年9月 · Shai-Hulud V1.0：**首个自我复制npm蠕虫诞生。通过钓鱼获取凭证→自动感染→自动发布，实现指数级扩散。180+包被感染
5**2025年底 · Shai-Hulud V2.0：**扩展到约800个包，感染Zapier、PostHog、Postman等知名企业工具
6**2026年 · Mini Shai-Hulud + Miasma/Hades：**攻击工业化。无需凭证的新入侵技术、跨npm/PyPI双生态传播、GitHub Actions投毒、有效SLSA证明------传统防线全线突破
🔑 核心要点
✅ npm供应链攻击已从"偶发事件"进化为"工业级威胁"，Shai-Hulud蠕虫实现了真正的自动化自我复制传播
✅ 2026年已有至少6个有组织威胁团伙活跃于开源供应链攻击领域，其中包括国家级APT组织
✅ npm的provenance证明机制已被证明不是可靠的安全信号，传统信任链已断裂
✅ PyPI强制2FA使恶意包下降43%，证明安全措施有效------但攻击者会转向防护最薄弱的npm
✅ 防御需要纵深体系：开发者个人防护 + CI/CD流水线加固 + 企业级SCA监控，缺一不可
觉得有用？点个「在看」让更多人看到 👇
🔒 本文由紫禁玄科原创 | 转载请注明出处