TanStack 披露一起复杂的 npm 供应链攻击事件， 42 个包遭入侵

TL;DR

• TanStack 发布安全事件回顾报告，披露一起复杂的供应链攻击，在 6 分钟内攻破 42 个 npm 包并发布 84 个恶意版本。
• 攻击者利用 GitHub Actions 共享缓存投毒及不安全的 pull_request_target 工作流，无需直接窃取 npm 凭证即可向 npm 注入恶意代码。
• 恶意软件通过加密消息外泄云凭证、SSH 密钥及 Kubernetes 令牌，并具备自我传播机制，旨在感染受害者维护的其他 npm 包。
• 该事件发生于 5 月 11 日 19:20-19:26 UTC，因恶意代码导致测试失败而意外暴露，随后 20 分钟内被外部研究人员发现并移除。
• TanStack 已移除不安全模式、固定 GitHub Actions SHA 值并加强发布管道管控，突显 CI/CD 基础设施已成为主要攻击面。

为什么值得看

该案例揭示了现代 CI/CD 自动化信任模型（如 OIDC 令牌和共享缓存）中未被广泛认知的深层漏洞，表明保护源代码已不足以保障供应链安全。对于 AI 从业者和技术管理者而言，理解攻击者如何利用“隐形纽带”（如工作流权限和缓存机制）进行横向移动，对于构建更健壮的开源依赖和自动化基础设施至关重要。

关键数据

• 42 个 npm 包 / 84 个恶意包版本：这是单次攻击中受影响的包数量和发布的恶意版本总数，体现了攻击的高效率。
• 6 分钟（19:20 至 19:26 UTC）：攻击者完成从篡改缓存到成功发布恶意包至 npm 的时间窗口，发生于 5 月 11 日。
• 20 分钟：恶意包出现在 npm 上后被外部安全研究人员发现的时间间隔，标志着响应速度。
• 0 个直接泄露的 npm 凭证：TanStack 确认 npm 令牌本身未被窃取，攻击是利用了 CI/CD 工作流已授予的权限生成 OIDC 令牌。

技术解析

• 缓存投毒与信任边界突破：攻击者首先提交看似无害的拉取请求，利用配置了 pull_request_target 模式的工作流跨越分支信任边界。通过篡改共享的 GitHub Actions 缓存，恶意文件在后续主分支的正常发布流程中被恢复，从而在受信任的环境中执行。
• OIDC 令牌滥用：攻击者利用被入侵的工作流生成 OpenID Connect (OIDC) 令牌，这些令牌直接拥有向 npm 发布包的权限。这种机制虽然消除了长期有效的静态令牌，但一旦工作流被入侵，攻击者即可为关联的所有包生成具有发布权限的临时凭证。
• 多向量凭证窃取与自传播：恶意软件在 npm 安装时自动执行，针对性地窃取 AWS、GCP、Kubernetes、Vault、GitHub、SSH 密钥及 npm 配置。它还能枚举受害者维护的其他 npm 包并重新发布带有相同恶意负载的版本，实现自动化横向移动。
• 隐蔽执行路径：攻击并未直接入侵 npm 账户，而是通过破坏 CI/CD 管道中的信任环节，使恶意代码在测试阶段执行并劫持发布过程。这种路径使得传统的基于凭证监控的安全措施失效。

行业启示

• CI/CD 即攻击面：构建和发布管道本身已成为主要攻击面，企业必须将安全性审查从代码层延伸至工作流配置、缓存管理和自动化信任机制。
• 共享基础设施的风险：GitHub Actions 缓存在不同工作流间共享的特性常被忽视，组织需重新评估此类共享状态的安全隔离措施，防止通过无关 PR 污染生产环境。
• 动态信任模型的脆弱性：OIDC 等动态令牌机制虽好，但加剧了工作流被入侵后的影响范围。需要实施更严格的仓库所有者验证和不可变 SHA 固定，以限制权限提升路径。

常见问题

Q: 攻击者是如何在不获取 npm 账号密码的情况下发布恶意包的？
A: 攻击者通过投毒 GitHub Actions 共享缓存，利用不安全的 pull_request_target 工作流提升权限，进而生成拥有 npm 发布权限的 OpenID Connect (OIDC) 令牌，直接在受信任的 CI 管道中发布恶意版本。

Q: 这次攻击是如何被发现的？
A: 主要是因为在发布过程中，恶意软件意外导致了测试失败。此外，在恶意包出现在 npm 上不到 20 分钟后，安全研究人员和外部贡献者也发现了该事件，促使 TanStack 迅速行动。

Q: 除了移除恶意包，TanStack 采取了哪些具体的强化措施？
A: TanStack 移除了不安全的工作流模式，清除了缓存，将 GitHub Actions 固定到不可变的 SHA 值，添加了存储库所有者验证，并对发布管道实施了更严格的管控，同时承认需改进内部监控机制。