TanStack npmサプライチェーン侵害の全体像

2026年5月11日に発生したTanStack npmサプライチェーン侵害は、単なる「有名パッケージにマルウェアが混入した事件」ではない。より正確には、オープンソースの公開基盤、CI/CD、npmのTrusted Publishing、GitHub Actionsのキャッシュ、SLSA来歴証明、開発者端末、AIコーディングツールが一本の攻撃線で結ばれた事件だった。

TanStack公式ポストモーテムによると、攻撃者は2026年5月11日19時20分から19時26分 UTCの約6分間に、42個の@tanstack系npmパッケージへ84個の悪性バージョンを公開した。日本時間では5月12日午前4時20分から4時26分ごろにあたる。各パッケージには原則として2つの悪性バージョンが公開され、たとえば@tanstack/react-router、@tanstack/vue-router、@tanstack/solid-router、@tanstack/router-core、@tanstack/react-start、@tanstack/router-pluginなど、RouterとStart周辺の開発者が触れやすい領域が中心だった。

重要なのは、攻撃者がTanStackメンテナのnpmトークンを盗んで直接公開したわけではない点である。TanStackのリリースは、開発者の手元のノートPCからnpm publishを実行する形ではなく、GitHub Actions上の正規リリースワークフローから行われていた。さらにnpmのOIDC Trusted Publishingを使っており、長期間有効なnpm公開トークンをCIのSecretsや開発者端末に置かない構成だった。これは2020年代半ば以降、オープンソースの安全な公開方法として推奨されてきた方向性であり、設計思想そのものは間違っていなかった。

それでも攻撃は成立した。攻撃者は「トークンを盗む」のではなく、「正規のワークフローがトークンを発行できる瞬間に、正規ワークフローの内部で悪性コードを動かす」という経路を選んだ。つまり、鍵を盗んだのではなく、鍵を作る機械の前に忍び込んだのである。

なぜTanStackが狙われたのか

TanStackはReact、Vue、Solidなどのフロントエンド開発者に広く使われるライブラリ群で、Router、Query、Table、Form、Virtualなど複数のプロジェクトを持つ。とくにRouter系パッケージは、アプリケーションのルーティング、ビルド、サーバーサイドレンダリング、開発ツールに関わるため、開発環境やCIで頻繁にインストールされる。SocketやSnykなど複数の調査では、@tanstack/react-router単体でも週あたり1000万回を超える規模のダウンロードが確認されており、攻撃者にとっては非常に効率のよい入口だった。

ただし、TanStackだけが目的地だったわけではない。StepSecurity、Aikido、SafeDep、Snyk、Socket、Wizなどの調査を突き合わせると、この攻撃はMini Shai-Huludと呼ばれる自己増殖型キャンペーンの一部であり、TanStackはその中でも目立つ起点の一つだった。集計時点により数字は変わるが、Aikidoは169個のnpmパッケージ名にまたがる373個の悪性パッケージ・バージョンを検出し、Snykの脆弱性データベースではTanStack関連と追加パッケージを含む172件規模の一覧が示されている。影響先にはMistral AI、UiPath、OpenSearch、Guardrails AI、Squawk、TallyUI、DraftLabなどが含まれる。

この数字のばらつきは、情報が不正確だからではない。ワーム型攻撃では、被害が調査中にも増え、削除、隔離、非推奨化、再公開、二次感染の確認が同時進行する。そのため「何パッケージが侵害されたか」は、いつ、どのレジストリを、どの検知基準で数えたかによって変わる。確定値として扱うべきなのは、TanStack公式が確認した42パッケージ84バージョンであり、広域の被害数は更新され続ける暫定値である。

攻撃の第一段階、見えないPR

攻撃はnpmレジストリ上で突然始まったように見えるが、準備はその前日に始まっていた。TanStack公式の時系列によると、攻撃者は2026年5月10日17時16分 UTCにTanStack/routerのフォークを作成した。このフォークはzblgg/configurationという名前に変更されており、通常のフォーク一覧から直感的に見つけにくい名前だった。5月10日23時29分には、攻撃者が偽のclaudeというコミット作者名を使い、packages/history/vite_setup.mjsという約3万行のJavaScriptバンドルを追加した。

翌5月11日10時49分、攻撃者はTanStack/router本体に対してPRを開いた。タイトルは「WIP: simplify history build」。一見すると、履歴関連のビルドを単純化する作業中のPRに見える。ここで鍵になったのがGitHub Actionsのpull_request_targetである。

pull_request_targetは、フォークからのPRに対しても、ベースリポジトリ側の文脈でワークフローを走らせる仕組みである。コメント付与、ラベル操作、軽い検査など、ベースリポジトリ側の権限が必要な処理には便利だが、PR側の未信頼コードをチェックアウトしてビルドやインストールを行うと危険になる。GitHub Security Labは2021年の時点で、この組み合わせを「Pwn Request」として警告していた。2024年にはセキュリティ研究者Adnan Khanが、GitHub Actionsのキャッシュ汚染によって、見た目は低権限のワークフローから高権限ワークフローへ横移動できることを実証している。

TanStackのbundle-size.ymlは、まさにこの境界をまたいでしまった。ワークフローはpull_request_targetで動き、PRのmerge refをチェックアウトし、pnpm installとbundle-size向けのビルドを実行した。TanStack側は読み取り権限のジョブとして分離する意図を持っていたが、actions/cacheの保存は通常のGITHUB_TOKENのpermissions設定だけでは完全には止まらなかった。攻撃者はこの挙動を使い、悪性のpnpmストアをキャッシュとして保存した。

第二段階、キャッシュが時限爆弾になる

キャッシュは開発者にとって味方である。依存パッケージを毎回ダウンロードし直さず、ビルド時間を短縮できる。大規模なモノレポでは、キャッシュがなければCIの実行時間とコストが大きく膨らむ。しかし今回の事件では、この便利な仕組みが時限爆弾になった。

攻撃者が仕込んだvite_setup.mjsは、すぐにnpmへ公開する処理をしたわけではない。正規のrelease.ymlが後で参照するpnpmストアのキャッシュキーを先回りして計算し、Linux-pnpm-storeで始まる特定のキーへ悪性ファイルを保存した。TanStack公式によると、このキャッシュは約1.1GBで、2026年5月11日11時29分 UTCに保存された。その後、攻撃者はPRを最新のmainと同じ状態に戻し、差分が0件に見えるようにしたうえでPRを閉じ、ブランチも削除した。表面上は何も起きていないように見えたが、ベースリポジトリのキャッシュには毒が残った。

この「見えない残留物」が約8時間後に発火した。19時15分ごろ、通常のメンテナ作業によってmainブランチに変更が入り、release.ymlが起動した。release.ymlは正規のリリースワークフローであり、npmのOIDC Trusted Publishingに必要なid-token: write権限を持っていた。そしてSetup Toolsステップで、先ほどの悪性pnpmストアを復元した。攻撃者は、人間が悪性PRをマージする必要すらなく、正規の変更がmainに入るのを待つだけでよかった。

この点が今回の事件の特異性である。マルウェアはTanStackのmainブランチに混入していない。レビュー済みのソースコードが直接改ざんされたわけでもない。汚染されたのは、ワークフローとワークフローの間で共有されるキャッシュだった。コード監査、署名付きコミット、レビュー文化だけでは、この層を見落とす可能性がある。

第三段階、OIDCトークンをメモリから抜き出す

release.ymlはnpm公開のためにOIDCトークンを発行できる。OIDCはOpenID Connectの略で、ここではGitHub Actionsが「このワークフローはこのリポジトリのこの実行である」とnpmに証明し、npmが短命の公開権限を認める仕組みを指す。長期のnpmトークンを保存しないため、従来型のトークン窃取に強い。

しかし、攻撃者はその短命トークンを発行できるワークフロー内でコード実行を得た。悪性バイナリはGitHub Actions Runner.Workerプロセスを探し、Linuxのprocファイルシステムを通じてプロセスメモリを読み、OIDC関連トークンを抽出した。TanStack公式は、この手法が2025年3月のtj-actions/changed-files侵害で使われたメモリ抽出スクリプトと同系統であり、攻撃者がまったく新しい技術を発明したのではなく、既知の手法を組み合わせたと説明している。

抽出されたトークンは、ワークフローの正式なPublish Packagesステップを経由せず、registry.npmjs.orgへ直接POSTするために使われた。実際、TanStackの公開ステップはテスト失敗によりスキップされていた。それにもかかわらず、npm側から見ると公開は正規のOIDC trusted-publisher bindingを通じて認証されていた。ここに防御側の盲点がある。レジストリは「正しいワークフローから来た」ことを確認できるが、「そのワークフロー内のどのプロセスが、どの意図で公開したか」までは十分に検証できなかった。

悪性パッケージの中身

公開された悪性TanStackパッケージには、主に2つの変更が入っていた。第一に、package.jsonへ@tanstack/setupというoptionalDependenciesが追加された。これはnpmレジストリ上の通常パッケージではなく、github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885cというGitHub依存を指していた。見た目はTanStack公式リポジトリ内のコミットのように見えるが、実際にはフォークネットワークに存在する孤立コミットを参照していた。GitHubではフォーク間でオブジェクトが共有されるため、攻撃者のフォークに置いたコミットでも、親リポジトリ名を含むURLで到達できる場合がある。この仕様が、社会工学的な偽装にも使われた。

第二に、パッケージのルートへrouter_init.jsという約2.3MBの難読化JavaScriptが追加された。このファイルは通常のビルド成果物というより、文字列配列の回転、制御フロー平坦化、AES-256-GCMによる暗号化ペイロード、Bunランタイム依存などを持つ本格的な窃取ツールだった。Socketは公開後6分以内にSocket AI Scannerが全84アーティファクトを検知したと説明しているが、人間が目視で読めるようなコードではなかった。

optionalDependenciesで参照された@tanstack/setupは、prepareライフサイクルスクリプトを持っていた。npmはGit依存をインストールする際にprepareを実行するため、npm install、pnpm install、yarn installの過程で悪性処理が起動する。しかもoptionalDependencyは失敗してもインストール全体を失敗にしないことがある。攻撃者は末尾でexit 1を使い、痕跡を薄くしながら本体を動かす設計を採った。削除後のnode_modulesだけを見て「何もない」と判断すると見逃す可能性がある。

何を盗もうとしたのか

マルウェアの狙いは、一般ユーザーのブラウザ閲覧履歴だけではない。主対象は開発者端末、CI/CDランナー、クラウド環境、パッケージ公開権限である。GitHub AdvisoryやSnyk、StepSecurityの解析によると、ペイロードはAWSのインスタンスメタデータ、AWS Secrets Manager、GCPメタデータ、Kubernetesサービスアカウントトークン、HashiCorp Vaultトークン、npmトークン、GitHubトークン、gh CLI設定、.git-credentials、SSH秘密鍵を探索した。

とくに危険なのは、クラウドネイティブ環境に合わせた探索が丁寧だった点である。AWSについてはIMDSv1だけでなく、IMDSv2のセッショントークン取得を実装していた。これは、古いメタデータ取得だけを遮断した環境でも、設定次第では認証情報が抜かれる可能性を意味する。Kubernetesでは/var/run/secrets/kubernetes.io/serviceaccount配下のトークンを探し、Vaultではvault.svc.cluster.localのようなクラスター内サービス名を対象にしていた。Kubernetesのサービスアカウントが過剰権限を持っている環境では、単なるnpm installがクラスタ全体の秘密情報流出につながる。

さらに、攻撃対象には開発者の生活圏も含まれていた。Claude Codeのセッション履歴、VS Code設定、暗号資産ウォレット、VPN設定、Signal、Slack、Discord、Telegramなどのメッセージング関連データ、シェル履歴も探索対象だった。シェル履歴が狙われる理由は単純で、多くの開発者が一時的にAPIキーやトークンをコマンドラインへ貼り付けてしまうからである。サプライチェーン攻撃は、依存パッケージの問題であると同時に、日々の開発習慣の問題でもある。

盗んだ後の送り先と持続化

盗まれたデータは、主にSession/OxenのファイルアップロードネットワークやGitHub GraphQL APIを使って送信された。Sessionはプライバシー志向のメッセージング基盤であり、攻撃者専用のわかりやすいC2サーバーではない。そのため、単純なIPブロックでは防ぎにくい。Snykは、現実的なネットワーク対策としてfilev2.getsession.orgやseed1、seed2、seed3.getsession.orgなどをDNSレベルで監視または遮断する必要があると述べている。

もう一つの経路はGitHub上のdead dropである。攻撃者はGitHub GraphQL APIのcreateCommitOnBranchを使い、盗んだデータを暗号化して攻撃者管理リポジトリへコミットする。コミット作者はclaude@users.noreply.github.comに偽装され、メッセージはchore: update dependencies、ブランチ名はDune作品の用語を含むDependabot風の名前だった。Dune由来のShai-Huludという名前自体も、砂漠の巨大ワームに由来する。攻撃者は技術的な隠蔽だけでなく、キャンペーン全体に一貫したテーマを持たせていた。この遊び心は無害ではない。調査者に認知されるための署名であり、同時に検知ルールの手がかりにもなる。

持続化も入念だった。ペイロードはプロセス開始時に自身をデーモン化し、標準出力を閉じ、npm installの画面から見えにくくした。さらに.claude/settings.jsonへフックを仕込み、Claude Codeのセッション開始時に再実行されるようにした。VS Codeでは.vscode/tasks.jsonを使い、フォルダを開いたときにsetup.mjsを動かす経路が用意された。Linuxではsystemdユーザーサービス、macOSではLaunchAgentとしてgh-token-monitorが作られる可能性が報告されている。つまり、npm uninstallだけでは不十分である。元のパッケージを消しても、開発ツールの設定に残ったフックが再感染や再送信を続ける可能性がある。

自己増殖するワームとしての怖さ

Mini Shai-Huludが単なる情報窃取マルウェアと異なるのは、盗んだ認証情報を使って次のパッケージへ広がろうとする点である。ペイロードはnpmトークンを探し、2要素認証を回避できるbypass_2fa付きトークンがあれば、それを使って被害者が管理するパッケージ一覧を取得し、同じ注入を行う。あるいはCI上のOIDC発行権限を悪用して、正規の公開経路から次の悪性版を出す。

この仕組みは、生物の感染に近い。感染した開発環境が単なる終点ではなく、次の公開者になる。たとえば、ある企業のCIが悪性TanStackパッケージをインストールし、そのCIが自社npmパッケージを公開する権限を持っていた場合、ワームはその自社パッケージにも悪性optionalDependencyやrouter_init.jsを混入させる可能性がある。そこから別の利用者が感染し、さらに別のパッケージへ広がる。

2025年9月のShai-Hulud初期波では、数百のnpmパッケージと多数のGitHubリポジトリが影響を受け、2025年11月の第2波では月間1億回以上のダウンロード規模に関わるパッケージが話題になった。2026年4月のMini Shai-HuludではSAP、Intercom、Lightningなどが取り上げられ、AIコーディングツールへの持続化が見え始めた。今回の2026年5月の波では、TanStackを起点に正規CIと来歴証明を巻き込んだ。攻撃者は、毎回少しずつ防御側の「安心材料」を逆手に取っている。

SLSAとprovenanceが破られたという誤解

今回の事件で最も誤解されやすい表現は、「SLSAが破られた」という言い方である。より正確には、SLSA provenanceやnpm provenanceは仕様どおり機能したが、それだけでは安全性の判定に足りなかった。

npmのprovenanceは、パッケージがどこでビルドされ、どの公開者によって出されたかを検証可能にする仕組みである。Sigstoreの短命証明書や透明性ログを使い、出所を改ざんしにくくする。これは重要な前進であり、長期トークンをSecretsへ置きっぱなしにするより安全である。しかし、provenanceが保証するのは「正規のビルド環境から出た」という事実であって、「そのビルド環境の内部で実行されたコードが善良だった」という評価ではない。

今回の悪性TanStackパッケージは、正規のGitHub Actionsリリースランナーから、正規のOIDC経路で、正当な来歴証明付きで公開された。だからこそ厄介だった。防御側が「署名あり」「provenanceあり」「OIDCあり」を安全の最終判定にしていた場合、悪性版を見逃す可能性がある。ぽちょ研究所のように教養コンテンツとしてこの事件を眺めるなら、ここが最大の学びである。出所証明は必要条件であって、十分条件ではない。

被害を受けた可能性がある人

TanStack公式は、2026年5月11日に影響バージョンをインストールした開発者やCI環境は、インストールホストを侵害された可能性があるものとして扱うべきだと述べている。日本時間では主な公開窓は5月12日午前4時20分から4時26分ごろだが、悪性版が削除、非推奨化、サーバー側除去されるまでの時間差があるため、単純に6分間だけを見ればよいわけではない。ロックファイルに該当バージョンが入っている環境、CIキャッシュに残っている環境、社内ミラーやプロキシが保持している環境も確認対象である。

TanStack側で確認された悪性バージョンの例として、@tanstack/react-router、@tanstack/vue-router、@tanstack/solid-router、@tanstack/router-coreは1.169.5と1.169.8が挙げられている。@tanstack/historyは1.161.9と1.161.12、@tanstack/react-startは1.167.68と1.167.71、@tanstack/router-pluginは1.167.38と1.167.41など、RouterとStart周辺に多く見られる。完全な一覧はGitHub AdvisoryとTanStack公式の追跡情報で確認されている。

一方で、TanStack公式は@tanstack/query、@tanstack/table、@tanstack/form、@tanstack/virtual、@tanstack/store、@tanstack/startのメタパッケージについては、今回のTanStack単体の影響範囲では確認済みクリーンなファミリーとして扱っている。ただし、パッケージ名が似ているもの、start配下のサブパッケージ、Router系のdevtoolsやSSR関連パッケージを混同しないことが重要である。

具体的に何を確認すべきか

第一に、ロックファイルを確認する。package-lock.json、pnpm-lock.yaml、yarn.lockに、該当する@tanstack系悪性バージョン、または@tanstack/setup、github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885cという文字列がないかを見る。node_modules配下にrouter_init.jsが残っていないか、package.jsonのoptionalDependenciesに@tanstack/setupが追加されていないかも確認する。tarballを調べる場合は、インストールスクリプトを実行しない方法で中身だけを取り出す必要がある。

第二に、開発者端末とCIランナーの痕跡を確認する。.claude/settings.json、.claude/setup.mjs、.claude/router_runtime.js、.vscode/tasks.json、.vscode/setup.mjsが不審に変更されていないかを見る。Linuxでは~/.config/systemd/user/gh-token-monitor.service、macOSでは~/Library/LaunchAgents/com.user.gh-token-monitor.plistのような持続化ファイルが指標になる。GitHubリポジトリでは、claude@users.noreply.github.comによる意図しないコミット、chore: update dependenciesというメッセージ、Dune用語を含むDependabot風ブランチを探す価値がある。

第三に、ネットワークとログを確認する。npm installやビルド中にfilev2.getsession.org、seed1.getsession.org、api.masscan.cloud、git-tanstack.com、litter.catbox.moe上の特定ペイロードへ通信していないかを見直す。GitHub Actionsログでは、想定外のBun実行、tanstack_runner.js、router_init.js、python3が/procのメモリを読みにいく挙動、想定外のnpm publishを確認する。

第四に、認証情報を扱う順序に注意する。一般論として、影響環境からアクセス可能だったGitHub PAT、npmトークン、AWS、GCP、Azure、Vault、Kubernetes、SSH鍵、PyPIトークンはローテーション対象である。しかし、StepSecurityやSnykは、npmトークンに「IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner」という説明が付いた場合、いきなり取り消す前に端末を隔離し、持続化や破壊的処理の可能性を確認するよう警告している。これは、トークン取り消しをきっかけに破壊ルーチンを起動する設計が解析されたためである。現場対応では、ネットワーク隔離、フォレンジック保全、持続化除去、認証情報ローテーションを混乱なく進める必要がある。

組織が学ぶべき防御策

この事件への対策は、単に「TanStackをアップデートする」で終わらない。第一に、pull_request_targetを棚卸しする必要がある。未信頼PRのコードをチェックアウトし、npm installやビルドを行い、かつベースリポジトリのキャッシュや権限に触れるワークフローは高リスクである。GitHub Security Labが推奨するように、必要がなければpull_requestを使い、権限が必要な処理はworkflow_runで分離し、未信頼コードを実行する場所と権限を持つ場所を分けるべきである。

第二に、リリースワークフローのキャッシュを見直す。Adnan Khanの2024年の研究は、キャッシュ汚染がSLSAや署名付き成果物を伴うビルドにも影響しうると警告していた。今回、それが実際の大規模インシデントで現れた。TanStackは事件後、影響ワークフローのキャッシュを削除し、リリースパイプラインでpnpmキャッシュを無効化し、組織内のActionsをコミットSHAへ固定した。タグや@mainのような浮動参照は、将来別のサプライチェーンリスクになる。

第三に、OIDC権限を最小化する。id-token: writeをワークフロー全体へ広く与えるのではなく、実際に公開するジョブだけへ限定する。npmのTrusted Publisher設定も、リポジトリ単位でゆるく許可するのではなく、特定ブランチ、特定ワークフローファイル、必要なら環境保護と承認を組み合わせる。短命トークンは長命トークンより安全だが、実行中のランナーが乗っ取られれば短命であっても悪用される。

第四に、インストール直後の挙動を監視する。署名や来歴だけでなく、パッケージがinstall、preinstall、postinstall、prepareで何を起動するか、BunやPythonを突然ダウンロードしないか、クラウドメタデータやVault、GitHub APIへ通信しないかを検査する。新規公開後すぐのバージョンを自動採用しない「クールダウン」も有効である。pnpm 11のようなエコシステム側の遅延導入機能、社内パッケージプロキシ、SCA、SBOM、ランタイムのネットワーク制御を組み合わせると、ゼロデイ的な悪性公開の初動被害を小さくできる。

第五に、開発者端末を本番秘密情報の置き場にしない。Claude Code、VS Code、gh CLI、npmrc、ssh、shell history、ローカルVaultトークンなどは、攻撃者にとって宝の山になりうる。AIコーディングツールの設定ファイルが実行フックを持つ時代には、ソースコードだけでなく、開発ツールの設定も監査対象である。2020年代前半のサプライチェーン攻撃は、依存パッケージの名前やメンテナアカウントが焦点だった。2026年の今回の事件は、開発者の作業空間そのものが攻撃対象になったことを示している。

この事件の本質

TanStack npmサプライチェーン侵害は、防御の失敗というより、防御の境界がずれていたことを示す事件である。2FAは有効だった。長期npmトークンを置かないOIDCも有効だった。provenanceも正しく付いた。にもかかわらず、pull_request_target、Actionsキャッシュ、OIDCトークン発行、npm公開という別々の信頼境界が、攻撃者によって一本の経路につながれた。

この種の攻撃では、個々の対策を導入しただけでは足りない。重要なのは、未信頼コードがどこで実行され、その実行結果がどのキャッシュに残り、どの後続ワークフローに復元され、どの瞬間に公開権限やクラウド権限と接触するかを、流れとして見ることである。サプライチェーンとは、ソフトウェアの部品表だけではなく、レビュー、CI、キャッシュ、レジストリ、証明書、開発者端末、AIツールを含む運用の連鎖である。

今回の攻撃者は、その連鎖の中で最も見えにくい場所を選んだ。PRは閉じられ、差分は消え、mainブランチは清潔に見え、公開は正規CIから行われ、パッケージには来歴証明が付いていた。それでも、インストールした環境では認証情報が盗まれ、次のパッケージへ広がる可能性があった。

教訓は単純ではない。npmを使うな、GitHub Actionsを使うな、AIツールを使うな、という話ではない。むしろ、現代の開発基盤は便利さと自動化によって強くなった一方で、その自動化が攻撃者にも利用されるという話である。信頼できる仕組みを導入した後も、その仕組みがどの前提の上に立っているかを点検し続けなければならない。TanStack事件は、2026年時点のオープンソース・サプライチェーンにおいて、「正規の経路から出たものは安全」という直感を更新する必要があることを示した。

参考資料

β TEST 2026/05/04

じも恋「地元に来い！」

あなたのポチるで、街の「足りない」を可視化。

住民のポチるを集め、地域ニーズをデータとして蓄積。誘致の保証はなくても、街の声を次の一手へつなげます。

ポチる

自叙伝ドットコム

あなたの人生は書く価値がある。

AIにだから語れる、本当の自分がある。記憶の断片を拾い集め、ひとつの物語へ。

覗いてみる

TanStack npmサプライチェーン侵害の全体像

目次