一个Shai-Hulud，差点攻陷整个npm生态

毫不夸张地说，如果没有平台的介入，整个npm生态的依赖包都会被Shai-Hulud蠕虫感染。
从2025年9月至今，黑客组织TeamPCP利用Shai-Hulud，发动了3轮特大规模供应链投毒，数千个npm包被攻陷，其中不乏CrowdStrike、SAP、TanStack、AsyncAPI、Postman/PostHog这些知名公司和明星软件包。Shai-Hulud（2025/09）Sha1-Hulud / Shai-Hulud 2.0（2025/11）Mini Shai-Hulud（2026/04-2026/05）与常规供应链攻击攻陷单个热门依赖包不同，Shai-Hulud在攻陷零号感染者后，会自动感染受害者所属其他npm包，最快可在30分钟内感染超过600个版本，因此被认为是npm生态首个大规模自动化传播的供应链蠕虫。
更令人担忧的是，今年5月，TeamPCP公开了Shai-Hulud源码，这就意味着它正在成为一个去中心化的黑产工具，迭代速度、投毒规模将远超想象。回顾Shai-Hulud所有关联的攻击，零号npm包的失陷过程，已经成为最关键的问题，对于防范供应链攻击至关重要。对此，微步情报局进行了全面分析。本次完整分析报告（含完整攻击过程、代码分析、投毒恶意包）暂不开放线上获取，如有需求，请联系我们的工作人员。初见：npm生态的首个供应链蠕虫
Shai-Hulud第一次在npm平台出现，是2025年9月14日17:55（UTC），医疗软件开发商RXNT旗下名为rxnt-authentication的npm包感染恶意代码。代码比较简单，主要是通过下载/运行TruffleHog扫描窃取凭据。
至于具体感染方式，目前尚不得而知。但由于其不通过GitHub CI/CD发布，所以只能是维护者techsupportrxnt的npm token泄漏导致。
微步情报局推测，TeamPCP一定是通过某种方式，如使用GitHub Pwn Requests攻击，窃取到了GitHub Actions runner中维护者的npm token，进而篡改、发布恶意版本。
由于Shai-Hulud会自动利用窃取到的npm token，篡改、发布受害者所属的其他npm包，因此本轮投毒很快形成了规模化扩散。短短3天内多达500+npm包迅速失陷，传播速度之快前所未有。其中受影响比较严重的有：lrxnt-authentication@0.0.3 (17:58:50)ljson-rules-engine-simplified@0.2.1 (17:58:51)lreact-jsonschema-form-conditionals@0.3.18 (17:58:52)lencounter-playground@0.0.2 (17:58:52)lrxnt-healthchecks-nestjs@1.0.2 (17:58:53)lrxnt-kue@1.0.4 (17:58:54)在npm平台的快速干预下，2025年9月18日，这轮投毒活动告一段落。然而危险的种子已经种下，npm token依然暴露在攻击者面前，这也为下一轮更大规模的投毒埋下了伏笔。
2.0：持续利用npm token暴露面
果不其然，两个月后的2025年11月24日凌晨（UTC），Shai-Hulud 2.0来了。
TeamPCP对蠕虫代码做了部分调整，包括新增了持久化手段以及破坏性的手段，在无法获取GitHub/npm token时，删除当前用户主目录中的数据。
@zapier、@asyncapi、@postman、@posthog等npm包接连出现恶意版本，共同成为了第二轮投毒的零号感染者。在所有失陷分析报告中，PostHog提及了一个关键错误配置：pull_request_target。
维护者在使用Github流水线自动发布npm包时，会提前配置需要的npm token，因此存在一个长时间的暴露窗口。TeamPCP正是抓住了这个机制，利用pull_request_target的配置缺陷，在官方服务器运行攻击脚本，窃取了npm token。
结合失陷厂商的分析报告，微步情报局还原了零号感染者的失陷过程。第一步：流水线审计
攻击者通过研究项目的GitHub Actions workflow，发现项目使用pull_request_target，并且会checkout提交PR的代码、执行仓库内脚本。
第二步：植入恶意载荷
攻击者fork项目，并在个人副本仓库中，修改将被官方工作流调用的脚本或测试文件，植入恶意载荷，它的作用是静默读取当前进程环境变量、内存空间以及外传凭证。
第三步：触发恶意代码
攻击者向目标项目提交Pull Request（PR），激活官方仓库的pull_request_target工作流，在缺乏安全隔离的情况下，触发了恶意代码，导致环境中默认全局共享的npm token失窃。
第四步，发布恶意版本
攻击者利用窃取到的npm token，发布恶意版本，随后产生链式污染。根据公开数据统计，Shai-Hulud 2.0制造了超过800个恶意软件版本。
这轮投毒过后，市场警觉了起来。
几乎所有失陷厂商都在分析报告中宣布，不再使用长期token发布npm包，转而让GitHub做担保申请npm平台一次性token，即OIDC（OpenID Connect），避免被攻击者轻易窃取。截图：Postman分析报告或许是OIDC技术起到了一定作用，或许是TeamPCP忙着去做别的事情，亦或其他原因，总之第二轮投毒过后，Shai-Hulud沉寂了一段时间。在此期间，供应链投毒虽然依旧猛烈，但大规模的链式传播并不多。
3.0：针对OIDC技术的定向绕过
直到2026年4月，沉寂被打破了。TeamPCP在其最新代码仓库的描述中写着：A Mini Shai-Hulud has Appeared。
TeamPCP针对Mini Shai-Hulud做了很多的改良，包括内置硬编码去扫描凭证，使用AES+RSA混合加密回传信息，但更重要的是在投毒过程中，绕过了失陷厂商使用的OIDC技术。
本轮投毒明确的零号感染者有两个：4月29日，SAP旗下@cap-js失陷，攻击者发布了4个恶意npm包；5月11日，@TanStack也宣告失守，42个@tanstack/* npm包产生了84个恶意版本。为了更好理解TeamPCP的绕过手法，先对使用OIDC发布npm包的流程做一个简单科普。第一，项目发布信息构建。
维护者将代码合并至发布分支，触发GitHub Actions workflow对代码进行打包和安全测试。
第二，申请OIDC身份令牌。
随后，workflow会向GitHub官方申请OIDC ID Token，并将得到的包含数字签名的短期OIDC身份令牌，发送给npm平台。
第三，身份验证与发布授权。
npm会严格核验令牌签名的真实性，同时校验workflow文件、仓库、分支，确认与预设的可信发布者完全一致，才会开放临时发布权限，发布后即失效。
但就是这样一个看起来很安全的检验机制，还是被TeamPCP还是钻了空子。
SAP/@CAP-js失陷的原因是OIDC配置不当，没有严格指定发

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291418.htm