2026年5月11日,流行的开源项目TanStack遭遇了一次高度复杂的供应链攻击,该事件不仅影响了TanStack自身,还波及了包括Mistral AI、UiPath、OpenAI和Grafana Labs在内的160多个npm和PyPI软件包,总计发布了400多个恶意版本。此次攻击由名为TeamPCP的威胁组织发起,并被命名为“Mini Shai-Hulud”,它深刻揭示了现代软件开发中开源生态系统的脆弱性,并为Web3领域的安全防护敲响了警钟。
TanStack供应链攻击事件回顾

此次攻击发生在2026年5月11日UTC时间19:20至19:26之间,攻击者在短短六分钟内,向42个@tanstack命名空间下的npm包发布了84个恶意版本。值得注意的是,攻击者并未直接窃取npm凭证或通过网络钓鱼获取维护者账户,而是利用了GitHub Actions工作流中的一系列漏洞。
- 漏洞链利用: 攻击链涉及三个关键的GitHub Actions漏洞:
pull_request_target工作流配置不当、GitHub Actions缓存投毒以及运行时OpenID Connect (OIDC) 令牌提取。攻击者首先创建了TanStack/router仓库的一个伪装分支,并提交了一个包含恶意负载的拉取请求。由于pull_request_target工作流的配置问题,该拉取请求在具有基础仓库权限的环境中执行,从而允许攻击者向GitHub Actions缓存中注入恶意内容。随后,当合法的维护者合并代码并触发发布工作流时,被投毒的缓存被恢复,攻击者便能从GitHub Actions运行器进程内存中直接提取OIDC令牌。 - 恶意负载与传播: 此次攻击的恶意负载被称为“Mini Shai-Hulud”,它是一个自我传播的凭证窃取蠕虫。一旦被感染的软件包被安装,恶意代码便会在npm生命周期钩子中执行,窃取包括GitHub令牌、npm令牌、AWS、GCP、Azure凭证、Kubernetes服务账户令牌、HashiCorp Vault令牌、SSH密钥和环境变量在内的多种敏感信息。该蠕虫还会识别受害者拥有发布权限的其他npm包,修改这些包的存档以注入相同的恶意依赖,提升版本号,并使用窃取的凭证发布新的受感染版本,从而实现自我传播。
- 隐蔽性与影响: 此次攻击的危险之处在于,恶意软件包是通过TanStack的合法发布管道发布的,并带有有效的npm出处证明(provenance attestations)。这意味着,这些恶意版本在标准验证方法下与合法版本几乎无法区分,甚至通过了SLSA出处检查和有效签名证书的验证。 攻击迅速蔓延,导致OpenAI内部源代码仓库的凭证材料被窃取,Grafana Labs的代码库被下载,并影响了多个高下载量的软件包,如
@tanstack/react-router(每周下载量超过1270万次)。
开源生态系统的安全警钟
TanStack事件凸显了现代软件供应链日益增长的复杂性和脆弱性,并为整个开源生态系统敲响了警钟:

- CI/CD管道成为主要攻击面: 攻击表明,攻击者不再仅仅针对源代码仓库或凭证,而是将目光投向了持续集成/持续部署(CI/CD)管道本身,包括缓存、工作流权限和依赖解析系统。构建管道已成为现代软件开发中的主要攻击面。
- 传统安全措施的局限性: 即使项目启用了双因素认证(2FA)并遵循了SLSA出处验证等最佳实践,也可能无法抵御这种利用CI/CD系统信任链的复杂攻击。
- 信任边界的模糊: 攻击利用了GitHub Actions中跨“fork-to-base”信任边界的漏洞,使得来自fork仓库的恶意代码能够在基础仓库的权限下执行,这模糊了传统上对外部贡献的信任边界。
- “蠕虫式”传播的威胁: 恶意负载的自我传播能力意味着一个初始的妥协可能迅速扩散到整个依赖图,影响成百上千的下游项目,造成广泛而深远的损害。
Web3领域的防护之道
Web3项目因其管理着巨额数字资产的特性,成为供应链攻击的特别有吸引力的目标。供应链攻击可能直接导致用户资金被盗、私钥泄露或恶意合约部署,其后果往往是不可逆转的。 因此,Web3项目必须从以下几个方面加强防护:
1. 加强开发流程与CI/CD安全

- 严格的GitHub Actions配置: 仔细审查所有GitHub Actions工作流,特别是使用
pull_request_target触发器的工作流,确保它们不会在不安全的权限下执行来自fork仓库的代码。 - 凭证管理与轮换: 对CI/CD管道中使用的所有敏感凭证(如云服务密钥、API令牌、SSH密钥)进行严格管理和定期轮换。
- 缓存安全: 实施严格的缓存策略,避免在CI/CD环境中共享或重用可能被投毒的缓存,尤其是在处理来自不受信任来源的代码时。
- 出处验证与额外安全检查: 尽管SLSA出处验证被绕过,但仍应将其作为基础安全措施。同时,部署额外的安全软件来验证新软件包的出处和完整性,例如实施
minimumReleaseAge等包管理器配置,以减少新发布恶意包的即时风险。
2. 依赖管理与软件物料清单(SBOM)
- 全面的依赖审计: 定期对项目所有第三方依赖进行审计,包括直接和间接依赖,确保其来源可靠且无已知漏洞。
- 生成与维护SBOM: 为所有Web3应用生成并维护软件物料清单(SBOM),清晰记录所有组件及其版本,以便在发现漏洞时能够迅速识别受影响的范围。
- 依赖冷却策略: 采用依赖冷却策略,例如阻止新发布的软件包立即安装,以减少对快速移动攻击的暴露。

3. 代码完整性与签名基础设施保护
- 代码提交签名: 强制要求所有代码提交都进行GPG签名,并验证签名,以确保代码的完整性和来源可信。
- 保护签名基础设施: 对用于代码签名和发布二进制文件的基础设施进行最高级别的保护,防止攻击者生成合法签名的恶意软件。
- 静态与动态代码分析: 在CI/CD流程中集成静态应用安全测试(SAST)和动态应用安全测试(DAST)工具,检测潜在的漏洞和恶意代码。
4. 开发者教育与用户防护
- 安全意识培训: 对开发团队进行Web3特有的供应链攻击向量培训,例如恶意npm包如何窃取私钥、受损的开发工具如何修改交易参数以及针对包维护者的社会工程学攻击。
- 用户权限限制: 建议用户在与DApp交互时限制授予的权限,并对高风险操作进行多重验证。
- 硬件钱包与资产隔离: 鼓励用户使用硬件钱包存储长期资产,并将不同风险级别的资产进行隔离,以降低潜在损失。

TanStack供应链攻击再次证明,Web3的安全不仅仅局限于智能合约本身,而是贯穿于整个软件开发生命周期的每一个环节。只有全面提升供应链安全意识和防护能力,Web3生态系统才能更好地抵御日益复杂的威胁。




