攻撃は「正規の経路」を通った——TanStack・Nx Console・GitHubの連鎖で開発者が確認すること

影響を受けたのは@tanstack/react-router、@tanstack/react-start、@tanstack/router-core、@tanstack/history など、Router/Start系の42パッケージ・84バージョンです（全一覧はGitHubのアドバイザリ GHSA-g7cv-rxg3-hmpx）。TanStackによれば、Query・Table・Form・Virtualなど他のパッケージは影響を受けていません。ロックファイルの現在の内容だけでなく、2026年5月11日前後の変更履歴も見てください。不正版は公開から数時間でnpmから削除されているため、今のロックファイルに残っていなくても、その間に一度入った可能性があります。CIの実行ログで、5月11日 19:20（UTC、日本時間5月12日 4:20）以降にインストールを実行したジョブも確認します。

Nxの事後報告は、code --list-extensions --show-versions の出力から Nx Console（拡張機能IDは angular-console を含む）の版を確認する方法を示しています。影響を受けたのはv18.95.0だけで、公開されていたのは5月18日 12:30〜13:09（UTC、日本時間21:30〜22:09）です。Nxは、この時間帯にNx Consoleを入れていて自動更新が有効だった人は、実際に入ったかどうかにかかわらず侵害されたものとして扱うよう求めています。事後報告には、端末に残るファイルやプロセスの確認項目（侵害の痕跡）も載っているので、該当する人はそれに沿って点検してください。

TanStackとNxが挙げている対象は共通しています。GitHubのトークン、npmのトークン、SSH鍵、クラウド（AWS・GCP・Azure）の認証情報、Kubernetes、Vaultのトークン、そして .env ファイルの中身です。Nxは加えて、その時間帯に端末上のツールが新しく発行できた認証情報（クラウドの一時認証情報やGitHub CLIのトークンなど）もローテーションし、ローテーションのあとで端末の作り直しも検討するよう勧めています。失効の順序と、常駐するプログラムの扱いは npmサプライチェーン攻撃の守り方 の「感染が疑われるとき」の節を参照してください。

TanStackの事後報告によれば、このコードは感染した人がメンテナンスしている他のパッケージを探し、同じ仕掛けを入れて公開し直そうとする動きを持っていました。自分がnpmにパッケージを公開しているなら、5月11日以降に自分が出した覚えのないバージョンがないかをnpmの公開履歴で確認します。

Nxの事後報告によれば、盗まれたのはGitHub CLIのトークンで、その環境では端末上のファイルに保存されており、同じユーザーで動くどのプロセスからも読める状態でした。盗まれてから74秒以内にGitHubのAPIで使われています。gh auth status で保存場所を確認し、ファイルに平文で置かれているなら、OSの鍵保管庫や、実行するときだけ認証情報を渡すパスワードマネージャーの仕組みに移すことを検討してください。Nxは事件後、開発端末でGitHub CLIを直接使うことを社内ルールで禁止しています。トークン自体の寿命と範囲の絞り方は npmサプライチェーン攻撃の守り方 にまとめています。

Nxの事後報告によれば、侵害された貢献者のプロジェクトには .npmrc に minimum-release-age=10080（7日）が書かれていましたが、プロジェクトが指定していたpnpm 10.14はこの設定に対応しておらず、警告も出さずに無視しました。対応はpnpm 10.16以降です。不正版は入った時点で公開から77分しかたっておらず、設定が効いていれば止まっていました。package.json の packageManager で指定している版を確認し、設定が効く版であることをCIでも検査してください。npmを使う場合の同種の設定は npmサプライチェーン攻撃の守り方 で扱っています。

GitHubは5月26日、GitHub Enterprise Serverの更新パッケージに署名する鍵をローテーションしたと発表しました。管理者はインスタンス内のGPG公開鍵を入れ替える必要があり、入れ替えないと今後のバージョンアップが「有効なパッケージではない」という検証エラーで失敗します。手順と、手順用スクリプトのSHA256ダイジェストはGitHubの発表に掲載されています。GitHubは、更新ファイルを公式の配布元からだけ取得すること、今後数か月はセキュリティ更新が増える前提で準備することも求めています。GitHub Enterprise Cloudの利用者は対応不要です。

TanStackの事後報告によれば、バンドルサイズを測るワークフローが pull_request_target で動き、その中でフォークから来たプルリクエストのコードをチェックアウトしてビルドしていました。pull_request_target は本体リポジトリの権限で動くうえ、TanStackによれば初めての貢献者に承認を求める設定もこのトリガーには効きません。ラベル付けやコメントのように、外部のコードを実行しない用途に限ります。TanStackは事件後、全ワークフローから pull_request_target を取り除きました。

TanStackによれば、GitHub Actionsのキャッシュはリポジトリ単位で共有され、pull_request_target の実行もmainへのpush時の実行も同じ範囲を使います。さらに、キャッシュの保存はワークフローの permissions: で読み取り専用にしても止まりません。そのため、外部のコードを動かしたジョブが書いたキャッシュを、リリース用ワークフローが復元していました。TanStackは事件後、リリースのパイプラインでパッケージのキャッシュを無効にし、全キャッシュを削除しています。公開を行うワークフローでは、キャッシュを復元しないのが最も単純な線引きです。

TanStackのリリース用ワークフローは、npmへの信頼された公開（OIDC）のために id-token: write を持っていました。事後報告によれば、不正な公開はワークフローで定義された公開ステップからではなく、同じ実行の中の別の段階で動いたコードがトークンを取り出して行っています。TanStackは教訓として「信頼された公開の設定には公開ごとの確認がない」と書いています。公開ジョブを、ビルドやテストから分けた専用ジョブにし、その権限をそこだけに与え、GitHubの環境（Environment）の必須レビュアーで人の承認を挟みます。Nxは事件後、公開には起動した本人以外の承認を必須にしました。

TanStackとNxはどちらも、事件後にすべてのアクションの参照をタグやブランチ名からコミットのSHAに固定しました。TanStackは、タグやブランチを参照する状態を「この事件とは別に常にあるサプライチェーンのリスク」と書いています。

Nxが改ざん版に気づいたきっかけは、拡張機能のマーケットプレイスが公開のたびに送る定型の通知メールでした。公開の予定がなかったメンテナーが異常だと気づき、約11分で取り下げています。一方、もう一つの配布先には同じ通知がなく、取り下げまで約36分かかりました。また、盗まれたトークンでワークフローの実行記録が消されるなどの動きが1週間、監査ログに残ったまま気づかれていませんでした。公開通知の宛先がチームの誰かに届くか、監査ログの「実行記録の削除」を誰かが見ているかを確認してください。