TanStackのnpmサプライチェーン攻撃から学ぶ：開発者が知るべき新しい脅威と対策#
2026年5月11日、人気のJavaScriptライブラリTanStackが巧妙なnpmサプライチェーン攻撃を受けました。この攻撃は従来の手法を組み合わせた新しいパターンで、多くの開発者に衝撃を与えています。この記事では、攻撃の詳細と開発者が取るべき対策について詳しく解説します。
要点まとめ：5分で理解できる重要ポイント#
攻撃の概要#
- 発生日時: 2026年5月11日 19:20-19:26 UTC
- 被害範囲: 42パッケージ、84バージョンが感染
- 攻撃手法: GitHub ActionsのキャッシュポイズニングとOIDCトークンの悪用
- 検出: 外部研究者により20分以内に発見
特に重要な点#
- npmトークンは盗まれておらず、公式の公開ワークフロー自体は侵害されていない
- 攻撃者は「pull_request_target」パターンを悪用してGitHub Actionsを操作
- 感染したパッケージをインストールした場合、各種認証情報の漏洩リスクあり
攻撃の詳細解説#
新しい攻撃パターンの仕組み#
今回の攻撃は3つの要素を組み合わせた巧妙な手法でした：
「Pwn Request」パターンの悪用
pull_request_targetトリガーを使用したGitHub Actionsワークフローを標的- フォークからのPRでも本リポジトリの権限で実行される脆弱性を利用
GitHub Actionsキャッシュポイズニング
- フォークと本体リポジトリ間の信頼境界を越えたキャッシュ汚染
- 悪意のあるコードを含むキャッシュが本体のビルドプロセスに混入
OIDCトークンの実行時抽出
- GitHub Actions実行環境からOIDCトークンをメモリから抽出
- 正規のnpm公開プロセスを偽装して悪意のあるパッケージを公開
攻撃のタイムライン#
準備段階（キャッシュポイズニング）#
- 2026年5月10日 17:16: 攻撃者がTanStack/routerのフォーク「github.com/zblgg/configuration」を作成
- 2026年5月10日 23:29: 悪意のあるコード（約30,000行のJSペイロード）を含むコミットを投稿
- 2026年5月11日 10:49: WIPプルリクエスト「simplify history build」を開設
- 2026年5月11日 11:01-11:11: 複数回の強制プッシュでワークフローを繰り返し実行
- 2026年5月11日 11:29: 汚染されたキャッシュエントリ（1.1GB）がTanStack/routerに保存
実行段階（悪意のあるパッケージ公開）#
- 2026年5月11日 19:20:39: 最初の悪意のあるパッケージ群がnpmレジストリに公開
- 2026年5月11日 19:26:14: 2回目の悪意のあるパッケージ群が公開
マルウェアの動作#
感染したパッケージをインストールすると、以下の動作が自動実行されます：
認証情報の収集
- AWS IMDS/Secrets Manager
- GCP メタデータ
- Kubernetes サービスアカウントトークン
- Vault トークン
~/.npmrcファイル- GitHub トークン（環境変数、
ghCLI、.git-credentials） - SSH 秘密鍵
データの外部送信
- Session/Oxen メッセンジャーのファイルアップロードネットワーク経由で送信
- エンドツーエンド暗号化により、IPやドメインブロックのみが対策手段
感染拡大
- 被害者が管理する他のパッケージを自動検索
- 同様の手法で他のパッケージにも感染を拡大
背景と意義：なぜ重要なのか#
従来の攻撃との違い#
今回の攻撃は単なるアカウント侵害ではなく、CI/CDシステムの設計上の脆弱性を巧妙に組み合わせた点で画期的です。特に：
- 正規の認証メカニズムを悪用: OIDCによる信頼されたパブリッシャー機能を不正利用
- 検出困難性: 正規のワークフローから発行されたように見える
- 広範囲な影響: インストール時に自動実行される特性を悪用
開発者コミュニティへの影響#
この攻撃は、現代の開発環境における新しいリスクを浮き彫りにしました：
- CI/CDパイプラインの信頼性問題
- オープンソースエコシステムの脆弱性
- 自動化されたパッケージ管理の危険性
実際の影響：ユーザー・業界への変化#
被害範囲#
確認された感染パッケージ: 42パッケージ、84バージョン
安全が確認されたパッケージファミリー:
@tanstack/query*@tanstack/table*@tanstack/form*@tanstack/virtual*@tanstack/store@tanstack/start（メタパッケージのみ、@tanstack/start-*は除く）
推奨される対応策#
2026年5月11日に感染したバージョンをインストールした場合、以下の認証情報のローテーションが強く推奨されています：
- AWS認証情報
- GCP認証情報
- Kubernetes認証情報
- Vault認証情報
- GitHub認証情報
- npm認証情報
- SSH認証情報
対策と予防策#
開発者が取るべき即座の対策#
パッケージのバージョン確認
- 2026年5月11日にインストールしたTanStackパッケージのバージョンを確認
- 感染バージョンリストは元記事の追跡イシューで確認可能
認証情報のローテーション
- 感染の可能性がある場合は、上記の認証情報を即座に更新
ネットワーク監視
- Session/Oxenメッセンジャーネットワークへの通信を監視・ブロック
filev2.getsession.org、seed{1,2,3}.getsession.orgへの接続を確認
長期的なセキュリティ対策#
依存関係の監視強化
- パッケージの自動更新を控える
- セキュリティスキャンツールの導入
CI/CDパイプラインの見直し
pull_request_targetの使用を最小限に抑制- フォークからのPRに対する権限設定の厳格化
業界への教訓#
CI/CDセキュリティの再考#
この攻撃により、以下の点で業界全体の見直しが必要となりました：
GitHub Actionsの設計パターン改善
pull_request_targetの安全な使用方法の確立- キャッシュの信頼境界の明確化
パッケージレジストリの保護強化
- OIDC認証の追加検証機能
- 異常な公開パターンの自動検出
検出・対応体制の重要性#
今回、外部研究者による迅速な発見が被害の拡大を防ぎました。これは以下の重要性を示しています：
- セキュリティ研究者コミュニティとの連携
- 異常検知システムの充実
- インシデント対応プロセスの整備
疑問解決：よくある質問への回答#
Q: 自分のプロジェクトが感染しているかどうか確認する方法は？#
感染パッケージの完全なリストは元記事の追跡イシューで公開されています。2026年5月11日に@tanstackパッケージをインストールした場合は、バージョン番号を確認することを推奨します。
Q: なぜnpmのセキュリティ機能では防げなかったのか？#
今回の攻撃は正規のOIDC認証メカニズムを悪用しており、npm側から見ると正当な公開に見えるためです。パッケージレジストリ側での検出は非常に困難でした。
Q: 同様の攻撃は他のパッケージマネージャーでも発生する可能性があるか？#
類似の認証メカニズムを使用する他のパッケージマネージャー（PyPI、RubyGems等）でも、同様の攻撃手法が適用される可能性があります。
今後の展望と注目ポイント#
セキュリティ対策の進化#
GitHub Actionsの機能改善
- より細かな権限制御
- フォーク境界での追加検証
パッケージレジストリの強化
- 公開パターンの異常検知
- 多要素認証の強化
業界標準の確立#
この事件を受けて、以下の標準化が進むと予想されます：
- CI/CDセキュリティのベストプラクティス
- サプライチェーン攻撃の検出・対応手順
- パッケージの信頼性検証メカニズム
まとめ：押さえておくべき3つの要点#
新しい攻撃手法の登場: GitHub ActionsとOIDCを組み合わせた巧妙な攻撃により、従来の防御策では不十分であることが判明
迅速な対応の重要性: 感染パッケージをインストールした場合は、即座に認証情報をローテーションし、システムを侵害されたものとして扱う必要がある
業界全体での対策強化: CI/CDパイプラインのセキュリティ設計とパッケージレジストリの保護機能について、根本的な見直しが必要
この事件は、現代のソフトウェア開発における新しいリスクを浮き彫りにしました。開発者は依存関係の管理により慎重になる必要があり、組織レベルでのセキュリティ対策も再考が求められています。
