2026年8月——安全公司Aikido披露，npm包@7nohe/openapi-react-query-codegen（一个为TanStack Query生成类型安全hooks的流行代码生成器，周下载量超过15万次）的多个版本遭供应链蠕虫入侵，20分钟内有10个恶意版本发布。攻击同时波及npm包与其GitHub仓库，波及范围包括开发者与CI系统的凭证窃取、仓库后门与进一步投毒。载荷自称“Trinitite: Sponsored by Preview 2 Effects”，其手法与TeamPCP关联活动相似，但归属尚未定论。
最刺痛防御者的细节：溯源证明依然有效
本次攻击被认为利用了GitHub Actions工作流的弱点，且被入侵的发布仍保有有效的来源证明（provenance attestation）。这个细节值得每个信任供应链证明的组织深思：来源证明能确认发布来自被授权的工作流，但当工作流本身已被篡改或攻陷时，它证明不了任何安全性。
换句话说，攻击者没有伪造证明，而是让被攻陷的合法流程自己签发了“合规”的恶意版本。当上游构建管道被攻陷时，溯源只是多层保障中的一层，不是清白的铁证。
执行机制：藏身binding.gyp的安装时载荷
多数受影响版本武器化了binding.gyp——Node.js原生插件的构建配置文件。安装时，node-gyp用Python解释该文件的条件，恶意文件滥用Python的类层级定位catch_warnings、重新获取内建函数访问权、导入os模块并运行混淆的Node.js载荷。全程没有任何合法的原生构建发生：这份配置文件存在的唯一目的，就是作为安装时执行机制。部分预发布版本改用显式的preinstall脚本，后续版本则将两种技术结合。
主载荷3FWCvzduYZg.js是一个5.4MB的单行文件，叠加XOR、AES-GCM与JavaScript混淆三层保护，静默下载Bun运行时后执行凭证收割。其反分析设计相当成熟：检测俄语区域设置、安全工具目录、已知扫描器诱饵凭证、研究账户与StepSecurity的harden-runner，命中分析环境即退出。
收割清单与传播路径
窃取范围几乎覆盖开发者工作站的全部敏感面：GitHub、npm、PyPI、RubyGems令牌；AWS、Azure、GCP与HashiCorp Vault凭证；Kubernetes服务账户与kubeconfig文件；SSH密钥；Docker配置；环境文件；Git凭证；shell历史；加密货币钱包；消息应用会话数据；VPN配置；甚至Claude AI的文件。载荷还会查询云元数据服务，并在外传前验证云凭证的有效性。
收集的信息被加密后提交到攻击者创建的GitHub仓库（典型命名取自东方Project角色，描述栏标记Trinitite）。随后蠕虫开始自我增殖：用窃取的发布令牌向npm、PyPI与RubyGems上的其他包注入恶意文件；用GitHub令牌污染可访问的仓库——投放带后门的VS Code任务、Claude Code hooks、伪造CodeQL工作流，以及其他针对开发者工具的配置文件。
这就是“蠕虫”定名的由来：每一台被感染的开发机都是新的分发节点，每一枚被窃的令牌都是新的入侵入口。
IOC与应急响应
确认被入侵的版本包括：0.5.4、0.5.5、1.6.3、1.6.4、2.2.1、2.2.2、3.0.3、3.0.4。载荷文件的SHA-256哈希为8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3。
曾运行过npm install受影响版本的组织应立即：
- 识别并卸载所有受影响版本的安装；
- 吊销并轮换暴露系统上的开发者、CI、云与注册表凭证——默认全部泄露，不要逐项判断；
- 检查仓库中的未授权提交与配置文件，重点排查VS Code任务、Claude Code hooks与GitHub Actions工作流；
- 回顾所有GitHub Actions工作流的近期变更记录。
防御升级：四条结构性建议
- 固定依赖版本：用锁文件钉住精确版本，避免浮动版本号把恶意新版本自动拉进构建；
- 最小权限发布令牌：发布令牌不该拥有账户级权限，CI令牌不该能写仓库；
- 把溯源当作一层保障而非证明：验证来源证明的同时，也要监控工作流定义本身的变更——本次事件中，被攻陷的工作流签出的证明完美“合法”；
- 保护开发环境的网络出口：载荷依赖下载Bun运行时与外传数据，终端侧对未知进程网络请求的管控能掐断这条链。
npm生态的供应链攻击已从“单包投毒”进化到“工作流劫持+自我增殖蠕虫”。当攻击者的目标从你的代码转向你的构建管道与凭证时，防御重心也必须从“检查依赖”上移到“检查产出依赖的系统”。