React/Vueエコシステムで広く使われるルーティング・データ管理ライブラリ「TanStack」のNPMパッケージが何者かに乗っ取られ、悪意あるコードを含むバージョンが配信される事案が発生した。影響範囲はTanStackを直接・間接に依存する全プロダクトに及ぶ可能性があり、ビルド時に取り込んだコードがエンドユーザーの認証情報や環境変数を窃取する典型的なサプライチェーン攻撃の構図が浮かび上がる。
何が起きたか
メンテナである Tanner Linsley氏が公開した TanStack NPM Packages Compromised(GitHub Issue #7383) によると、TanStackが管理するNPMパッケージ群の一部が第三者によって不正に発行された。攻撃者は何らかの手段でpublish権限を奪取し、正規のパッケージ名で汚染版を npm publish した形だ。
TanStackは @tanstack/react-router @tanstack/react-query @tanstack/react-table などを擁し、react-query だけで週間ダウンロード数が1,000万を超える、React開発における事実上のインフラである。Next.js / Remix / Viteベースの新規プロジェクトにおいて、これらが package.json に並ばないケースの方が珍しいと言ってよい。
汚染されたバージョンはすでにNPMレジストリから削除（unpublish ないしdeprecate）されているとされるが、package-lock.json や pnpm-lock.yaml に汚染バージョンがピン留めされたまま、あるいはCI上のキャッシュに残っている可能性は依然として残る。
なぜこのニュースが重要か
NPMサプライチェーン攻撃は新しい話題ではない。2021年の ua-parser-js、2022年の node-ipc のprotestware、2024年の lottie-player、そして2024年末に世界を揺さぶった XZ Utilsバックドア事件(CVE-2024-3094) と、攻撃者は「広く使われ、メンテナが少ないOSS」を狙い続けている。
しかしTanStack汚染が深刻なのは、その立ち位置だ。react-query はSSR/CSRを問わずアプリのデータレイヤそのものを担う。つまり攻撃者は、ブラウザで動作するコードに任意のJavaScriptを差し込めるだけでなく、ビルドプロセス（postinstallスクリプト経由）でCI環境変数 — GITHUB_TOKEN AWS_ACCESS_KEY_ID NPM_TOKEN などを直接抜き取れる可能性がある。
2026年現在、Claude CodeやCursor、GitHub Copilot Workspaceが自動で npm install と npm update を実行する開発フローが定着している。AIエージェントが「依存を最新に保つ」ことを善意で実行した結果、汚染版を引き込むリスクは、人間が手動で更新していた時代より格段に高い。
エンジニア視点での技術的示唆
まず即座にやるべきは、汚染期間に該当するインストールログの洗い出しだ。pnpmユーザーであれば以下が起点になる。
# 直近のインストール履歴と解決バージョンを確認
pnpm why @tanstack/react-router
pnpm why @tanstack/react-query
# lockfileから @tanstack/* の解決バージョンを抽出
grep -A2 "@tanstack/" pnpm-lock.yaml | grep version
汚染版が混入していた場合、対応は単なる pnpm update では済まない。node_modules を全削除し、lockfileを再生成、CIキャッシュ（GitHub ActionsのactionsCache、CircleCIのrestore_cache等）も全パージする必要がある。Dockerイメージのレイヤキャッシュも要注意で、FROM node:20 AS deps 以降のレイヤを --no-cache で焼き直すのが安全だ。
中長期では、npm config set ignore-scripts true を組織標準とし、postinstallスクリプトの実行を明示許可制にする運用が望ましい。さらに Socket.dev や Snyk のようなパッケージ振る舞い解析サービスをCIに組み込み、新規依存追加時に「ネットワーク通信を試みる」「子プロセスを起動する」といった挙動を自動検出させる。
GitHubの npm Provenance を有効化したパッケージのみを許可するポリシーも有効だ。npm install --foreground-scripts でpostinstallを可視化する、package.json の overrides フィールドで汚染版を強制的に安全版に差し替える、といった応急処置も覚えておきたい。
{
"overrides": {
"@tanstack/react-router": "1.x.x-known-safe"
}
}
経営者・技術責任者として次に取るべき動き
第一に、依存関係の「自動更新」を一律に止めるのではなく、メジャー/マイナー/パッチで分離する設計に切り替える。Renovate であれば rangeStrategy: "pin" と dependencyDashboardApproval: true の組み合わせで、人間のレビューを挟む運用が現実的だ。
第二に、SBOM（ソフトウェア部品表）の生成と保管を義務化する。CycloneDXやSPDX形式で各リリースのSBOMを残しておけば、今回のような事案で「自社の本番環境にいつ・どのバージョンが入ったか」を秒で特定できる。米国のEO 14028以降、SaaS調達の現場でもSBOM提出を求める企業が増えており、これは攻撃対応だけでなく営業面でも資産になる。
第三に、AIエージェントによるコード生成・依存追加に対する人間のゲート設計だ。「AIが書いたPRはAIがレビューする」体制はスピードは出るが、サプライチェーン攻撃に対しては脆い。新規依存の追加だけは必ずシニアエンジニアの目を通す、というシンプルなルールが、結局のところ最後の砦になる。
TanStackチームは迅速に告知を出し、コミュニティと協調して被害拡大を防ごうとしている。OSSメンテナを責めても何も解決しない。むしろ、ここまで重要なインフラを少人数で支えるメンテナへの資金援助（GitHub Sponsors、Open Collective）こそ、利用企業が負うべき責任である。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。