TanStack、Nx Console 与 GitHub 的连锁入侵（2026年5月）：开发者需要检查什么

受影响的是 Router/Start 的42个包、84个版本，包括 @tanstack/react-router、@tanstack/react-start、@tanstack/router-core 和 @tanstack/history（完整列表见 GitHub 公告 GHSA-g7cv-rxg3-hmpx）。TanStack 表示 Query、Table、Form、Virtual 及其他包不受影响。不仅要检查锁文件当前的内容，还要检查2026年5月11日前后的变更历史。恶意版本在几小时内就从 npm 上被移除了，所以在那段时间内的安装可能不会出现在今天的锁文件里。在 CI 中，查找5月11日 UTC 19:20 之后运行过安装的作业。

Nx 的事后报告说明了如何用 code --list-extensions --show-versions 查看已安装的版本（扩展 ID 中包含 angular-console）。只有 v18.95.0 受影响，它在5月18日 UTC 12:30 至13:09 之间可以获取。Nx 要求，在该时间段内装有 Nx Console 且开启了自动更新的人，无论最终哪个安装数字是准确的，都要把这台机器视为已被入侵。事后报告还列出了需要查找的文件和进程（入侵指标）；如果你受影响，请逐项检查。

TanStack 和 Nx 列出的对象相同：GitHub 令牌、npm 令牌、SSH 密钥、云凭据（AWS、GCP、Azure）、Kubernetes、Vault 令牌，以及任何 .env 文件的内容。Nx 还补充了机器上的工具在该时间段内可能签发的凭据（临时云凭据、GitHub CLI 令牌等），并建议在轮换后考虑彻底重装这台机器。关于吊销顺序和如何处理常驻恶意软件，参见防御 npm 供应链蠕虫中“怀疑已经感染时”一节。

据 TanStack 称，这段代码会查找受害者维护的其他包，并尝试用同样的注入方式重新发布它们。如果你向 npm 发布包，请检查自5月11日以来，你的包的版本历史中是否有你没有发布过的版本。

据 Nx 称，被盗的凭据是 GitHub CLI 令牌。在那个环境中，它存放在磁盘上的一个文件里，以该用户身份运行的任何进程都能读取，并在74秒内就被用来调用 GitHub API。运行 gh auth status 查看你的令牌存放在哪里；如果是普通文件，考虑把它移到操作系统的钥匙串，或者使用只在运行时注入凭据的密码管理器集成。事件发生后，Nx 的政策已不允许在开发者电脑上直接使用 GitHub CLI。关于缩短令牌有效期和缩小权限范围，参见防御 npm 供应链蠕虫。

据 Nx 称，被入侵贡献者的项目在 .npmrc 中设置了 minimum-release-age=10080（7天），但项目固定使用的 pnpm 10.14 不支持这个设置，并静默忽略了它。pnpm 从 10.16 开始支持。恶意版本在被安装时只发布了77分钟，所以只要设置真正生效，就能拦住它。请检查 package.json 中 packageManager 字段固定的版本，并让 CI 验证它足够新。npm 的对应设置，参见防御 npm 供应链蠕虫。

5月26日，GitHub 宣布正在轮换密钥，包括为 GitHub Enterprise Server 更新包签名的密钥。管理员必须轮换其实例中的 GPG 公钥；否则今后的升级会失败，并报错称该文件不是有效的 GHES 包。操作说明和辅助脚本的 SHA256 摘要见 GitHub 的文章。GitHub 还要求客户只从官方来源下载 GHES 更新，并做好在未来几个月内以更高频率应用安全更新的准备。GitHub Enterprise Cloud 的客户无需采取任何行动。

据 TanStack 称，一个检查打包体积的工作流运行在 pull_request_target 上，并在其中检出并构建了来自 fork 拉取请求的代码。pull_request_target 以基础仓库的权限运行，TanStack 指出，针对首次贡献者的审批关卡不适用于这个触发器。只把它用于永远不运行外部代码的任务，例如打标签和发评论。事件发生后，TanStack 从 CI 中移除了所有 pull_request_target 的使用。

据 TanStack 称，GitHub Actions 缓存按仓库共享：pull_request_target 的运行和推送到 main 的运行使用同一个范围。把工作流的 permissions: 设为只读，也不能阻止保存缓存。结果，发布工作流恢复了一个由运行过外部代码的作业写入的缓存。事件发生后，TanStack 在发布流水线中禁用了包缓存，并清除了所有缓存。在执行发布的工作流中不恢复缓存，是最简单的一条界线。

TanStack 的发布工作流为 npm 可信发布（OIDC）持有 id-token: write。根据事后报告，恶意发布并不是来自工作流中定义的发布步骤；而是在同一次运行的另一个阶段中运行的代码提取了令牌并直接发布。TanStack 自己总结的教训是：可信发布者的绑定没有针对每次发布的审查。把发布拆成独立的作业，与构建和测试分开，只给这个作业权限，并放在设置了必需审阅者（required reviewers）的 GitHub 环境之后。事件发生后，Nx 规定发布必须经过触发运行者以外的人批准。

事件发生后，TanStack 和 Nx 都把所有 Action 引用固定到了提交 SHA，而不是标签或分支。TanStack 把可移动的引用称为“与这次事件无关、一直存在的供应链风险”。

Nx 是通过扩展市场在每次上传时发送的常规通知邮件发现被篡改的版本的。一位并没有预期会有新版本的维护者意识到这是异常，在大约11分钟内撤下了它。第二个分发渠道没有这样的通知，在那里撤下花了大约36分钟。与此同时，用被盗令牌进行的活动（例如删除工作流运行记录）在审计日志中放了一周都无人察觉。请确认发布通知能送达团队中的某个人，并且有人盯着审计日志中被删除的工作流运行记录。