TanStackを起点とした「Mini Shai-Hulud」第二波の特徴と対応策を解説

2026年5月11日から12日未明にかけて、TanStack (@tanstack/*) を起点とした大規模なサプライチェーン攻撃が発生しました。本キャンペーン「Mini Shai-Hulud」では、TanStackエコシステムで42パッケージ・84バージョンが侵害され、PyPI/npm あわせて200を超えるパッケージが影響を受けています。

最大の特徴は、攻撃者が「正規のビルドパイプラインをハイジャックし、有効なSLSA署名を持ったまま悪意のあるコードを配布した」ことです。「署名されているから安全」という前提が崩されたインシデントとして、サプライチェーンセキュリティの転換点と言えます。

本記事では、TanStackから公開されたポストモーテムをもとに、攻撃の特徴・脅威・対応策、そしてOSSを公開する立場の方への注意喚起までを解説します。

国内唯一のISMAP登録済
脆弱性管理ツール

サマリー

今回の攻撃の3つの特徴

Pwn Requestによるビルドパイプラインのハイジャック

攻撃者はメンテナーの認証情報を直接盗むのではなく、GitHub Actionsの pull_request_target  ワークフローの設定不備を突き、外部のプルリクエストから書き込み権限のあるコンテキストで悪意あるコードを実行。
実行中に /proc 経由でランナーのメモリから npm publish用のOIDCトークンを窃取し、正規のリリースフローに割り込みました。

SLSA署名付きで配布されたnpmワームとしては初の事例

攻撃は正規のGitHub Actionsランナー上で実行されたため、Sigstoreによって有効なSLSA Build Level 3署名が付与されたまま悪意あるバージョンがnpmレジストリへ公開されました。

「署名検証=安全」というメンタルモデルを利用した高度なサプライチェーン汚染です。

optionalDependencies + GitHub URL参照によるスキャナ回避

攻撃者は package.json の optionalDependencies に、パッケージ名ではなく github:tanstack/router#<コミットハッシュ> の形式で悪意ある依存関係を注入しました。

多くの汎用脆弱性スキャナはnpmレジストリ外の参照を検査対象外としており、この時点で検知の網をすり抜けました。

注目すべきは、起動経路が preinstall から optionalDependencies 経由の prepare スクリプトに変わっている点です。optionalDependencies の「失敗しても無視される」仕様を逆手に取り、悪性スクリプトの実行を済ませた上でインストールを成功させます。

Git URL依存はビルド済み tarball を持たないため、利用者側で prepare を実行する必要があります。

npm 10 系以前は --ignore-scripts を付けても Git 依存の prepare は発火し、抑止が効くのは npm 11.0.0 以降です。

pnpm も 10.26.0 未満は素の pnpm install で発火し、デフォルトでブロックされるのは 10.26.0 以降です。

「--ignore-scripts しているから安全」「pnpm ならデフォルトで安全」という直感が利用バージョン次第で崩れる地点で、攻撃手法の進化がうかがえます。

サプライチェーン攻撃の高度化

近年のnpmサプライチェーン攻撃は、メンテナーのアカウント乗っ取りから、CI/CDパイプラインそのもののハイジャックへと進化しています。

Mini Shai-Huludはその象徴的なキャンペーンであり、署名・スキャン・ignore scriptsといった既存の防御が同時に機能しない領域に踏み込んできました。自衛戦略の見直しが必要なフェーズに入ったと認識すべきです。

事象の解説

時系列タイムライン

侵害されたのは Router 系を中心としたパッケージ群で、Query, Table, Form, Virtual, Store, Start メタパッケージは影響を受けていません。

攻撃メカニズム

今回の侵害は、以下の3段階が連鎖して成立しました。

GitHub Actionsキャッシュ汚染

信頼境界をまたぐ pnpm-store キャッシュを汚染し、後続のビルドで悪意あるバイナリが読み込まれる状態を構築。

pull_request_target 経由でのコード実行（Pwn Request)

フォークからのPRをトリガーに、書き込み権限のあるコンテキストで攻撃コードを実行。

OIDCトークンのメモリ抽出

ランナープロセスの /proc/<pid>/mem を走査し、npm publish 権限を持つ短命のOIDC IDトークン(JWT)を窃取。publishステップを直接通らずに、正規ランナーから悪意あるバージョンを公開しました。

影響範囲

侵害されたパッケージをインストールした環境では、以下が実行されます。

広範な秘密情報の窃取

AWS / Google Cloud / Azure / Kubernetes / Vault のクレデンシャル、GitHub・npmトークン、SSH秘密鍵、~/.npmrc、Claude Code / MCPの構成ファイル、ブラウザに保存された認証情報、暗号資産ウォレット(Electrum, Ethereum等)、クラウドメタデータが盗み出されます。

機密情報の窃取経路(Exfiltration)

主な窃取経路は、Session(Oxen) メッセンジャーの公開ファイルサーバ(filev2.getsession.org, seed{1,2,3}.getsession.org)で、E2E暗号化された状態でデータがアップロードされます。

Session側が応答しない場合のフォールバックとして、GitHub GraphQL API経由で被害者のGitHubアカウント配下に公開リポジトリが作成され、窃取データがコミットされます。

リポジトリ名は {dune_word}-{dune_word}-{3桁数字} の形式で、説明文に「A Mini Shai-Hulud has Appeared」が含まれます。自社/個人のGitHubアカウントに身に覚えのない公開リポジトリが作られていないかは、侵害判定の有力なシグナルになります。

開発環境への永続化(Persistence)

汚染バージョンを実行すると、ローカル環境の以下のファイルが書き換えられ、プロジェクトを開き直すたびに攻撃コードが再実行される、極めて執拗なバックドアが設置されます。

• .vscode/tasks.json (folderOpen タスク)
• .claude/settings.json (SessionStart フック)
• macOS: ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
• Linux: systemd user service gh-token-monitor
• .github/workflows/codeql_analysis.yml

脅威の特徴

本マルウェアには、サプライチェーン攻撃として特異性の高い自爆機構が組み込まれています。

gh-token-monitor サービスが60秒ごとにGitHubトークンの有効性をチェックし、HTTP 40x(=トークン失効)を検知すると rm -rf ~/ を実行してホームディレクトリを破壊します。

通常のインシデント対応の定石である「まずシークレットを失効させる」をそのまま実行すると、開発端末のデータが消失する設計になっています。後述の通り、対応の順序を間違えてはいけません。

緊急対応（感染が疑われる場合）

⚠️対応順序を厳守してください

自爆機構の解除前にトークンを失効させると、rm -rf ~/ が起動します。必ず下記の順で実施してください。

手順1. 影響範囲の確認

npm audit だけでは検知漏れが発生します。以下の4つの観点で侵害の痕跡を確認してください。

① ロックファイルの確認

#npm
grep "@tanstack/" package-lock.json | grep -v node_modules

#pnpm
grep "@tanstack/" pnpm-lock.yaml

#yarn
grep "@tanstack/" yarn.lock

#TanStack以外の影響パッケージも確認
grep -E "(draftlab|draftauth|taskflow-corp|tolka)" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

検出されたバージョンを、GHSA-g7cv-rxg3-hmpx ほか各パッケージのアドバイザリに記載された侵害バージョン一覧と照合してください。あわせて、github:tanstack/router#<hash> のような GitHub URL形式の依存が optionalDependencies 等に紛れていないかも確認します。

② 悪意のあるファイルの確認

node_modules 内に注入されたペイロード本体および悪意ある optional dependency を検索します。

#注入されたペイロード本体
find node_modules -name "router_init.js" -type f 2>/dev/null

#悪意あるoptionalDependencyの参照
grep -r "@tanstack/setup" node_modules/*/package.json 2>/dev/null

③ CI/CDログの確認

GitHub Actions のログから、ワームの実行を示す以下のシグナルを探してください。

• @tanstack/setup 依存関係のインストール中の参照
• ビルド/テスト工程での予期しないアウトバウンドネットワーク接続(getsession.org 系ドメインへの通信など)
• bun run tanstack_runner.js プロセスログの出現
• router_init.js に関連するファイルシステム操作の痕跡

④ GitHubアカウントの確認

自社/個人のGitHubアカウントに、説明文が「A Mini Shai-Hulud has Appeared」となっている公開リポジトリ(命名規則: {dune_word}-{dune_word}-{3桁数字})が存在しないかを確認してください。存在する場合、窃取データのフォールバック・アップロードが発生した証拠です。

手順2. 永続化機構の停止(最優先)

シークレットを無効化する前に、トークンの有効性を監視している悪意のあるプロセスを停止・削除し、自爆機構を無力化してください。

Linux

systemctl --user stop gh-token-monitor && systemctl --user disable gh-token-monitor
rm ~/.config/systemd/user/gh-token-monitor.service

macOS

launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
rm ~/Library/LaunchAgents/com.user.gh-token-monitor.plist

IDE / AIツール設定の浄化

• .vscode/tasks.json の "runOn": "folderOpen" 設定を削除
• .claude/settings.json の不審な SessionStart フックを削除
• .github/workflows/codeql_analysis.yml の改ざんを確認

手順3. シークレットの即時ローテーション

⚠️手順2の完了を確認した後にのみ実施してください

汚染環境からアクセス可能だったすべてのクレデンシャルを「変更」ではなく「失効(Revoke)」させた上で、新しいキーを発行してください。

対象

• AWS / Google Cloud / Azure / Kubernetes / Vault のアクセスキー
• GitHub Personal Access Token / Fine-grained PAT
• npm publish トークン
• SSH秘密鍵

手順4. キャッシュの浄化

GitHub Actions の Web UI から「Caches」メニューにある関連キャッシュをすべて手動で削除してください。汚染されたバイナリがキャッシュに残っている限り、再感染のリスクは消えません。

自衛の強化

今回のような攻撃を前提に、平時の防御策を見直す必要があります。

ignore scripts も pnpm デフォルトも、バージョン次第

第二波の optionalDependencies は Git URLを参照しており、Git依存は利用者側でビルドのために prepare が実行されます。

手元の再現環境で optionalDependencies 経由のインストールを試したところ、以下を確認しました（パッケージマネージャの content-addressable store を完全クリアした上で各バージョンを実機検証）。

• npm 10 系以前では --ignore-scripts を付けても、 .npmrc で ignore-scripts=true を指定しても、Git 依存の prepare は発火します。本手口を npm 側で --ignore-scripts で抑止できるのは npm 11.0.0 以降です。なお、npm はいずれのバージョンもデフォルトでは保護されないため明示が必要です。

• pnpm は 10.26.0 で onlyBuiltDependencies（11.0.0以降では allowBuilds にリネーム）の必須化がGit-hosted パッケージの prepare にも適用されるようになり、デフォルトの pnpm install でも ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED で停止します。optionalDependencies 経由の場合は親パッケージはインストールされ、Git 依存だけがスキップされます。一方、pnpm 10.26.0 未満（v9 / v8 含む）はデフォルトで prepare が発火します。

「ignore scripts しているから安全」「pnpm を使っているから安全」という認識は、npm 11 + 明示的 --ignore-scripts か、pnpm 10.26.0 以降を前提にすれば一定の効力を持ちますが、それ未満のバージョンでは成立しません。

後述のクールダウンと組み合わせるのが安全です。

クールダウン戦略(重要)

サプライチェーン攻撃は 発見 → アドバイザリ発行 → スキャナ反映までに数時間〜半日のラグがあります。新規リリース直後のバージョンを即座に取り込まないだけで、今回のような侵害の大半を回避できます。

• パッケージマネージャ側で「公開後N日以内のバージョンを禁止」する設定を導入(minimumReleaseAge 等)
• 社内プロキシレジストリで新規バージョンの取り込みを遅延
• 依存更新PRの自動マージは公開から一定期間経過後に限定

クールダウンは「最新を追わない」運用に見えますが、現在のサプライチェーン攻撃に対する最も実効性の高い防御の一つです。

脆弱性管理クラウド「yamory（ヤモリー）」による検知・支援

yamoryでは、ロックファイル内のGitHub URL参照を含む依存関係も走査対象とし、Mini Shai-Hulud関連の侵害バージョンを検出します。クールダウン期間中の継続スキャンや、影響範囲の可視化を通じて、今回のような攻撃への対応を支援します。

yamoryの無料トライアルにて、自社システム内にMini Shai-Hulud関連の侵害バージョンが含まれていないかを簡単にスキャン・確認できますので、ぜひ一度お試しください。

>>脆弱性管理クラウド「yamory」の無料トライアルに申し込む

【OSSメンテナー向け】 pull_request_target の注意喚起

本セクションはOSSを公開している方向けの内容です。

今回の侵害の根本原因は、フォークからのPRに対して書き込み権限のあるコンテキストで処理を実行できる pull_request_target の誤用にあります。同様の構成を持つリポジトリは、攻撃者にとって格好の標的です。

確認すべきポイント

• ワークフローの permissions をデフォルトで none または最小権限に設定し、id-token: write 等の強い権限は本当に必要なJobのみに付与する

• pull_request_target でフォーク提供のコード(checkout の ref に PRブランチを指定する等)を実行しない

• どうしてもフォークコードを扱う必要がある場合は、信頼境界をまたぐキャッシュ(pnpm-store等)を分離し、メンテナー承認ゲート(environment の required reviewers)を挟む

• OIDCの id-token を発行するワークフローは、PRトリガーから完全に隔離する

「自分のOSSが他者を攻撃する踏み台になる」リスクを想定した運用が、今後のメンテナンスでは必須になります。

サプライチェーンの脆弱性を可視化する 脆弱性管理クラウドyamoryのご紹介

株式会社アシュアードが提供する脆弱性管理クラウド「yamory」は、システム内に潜む脆弱性などのITリスクの検知から対応の優先度付けまでを自動で行う、国産のクラウドサービスです。

yamoryを使えば、重大な脆弱性が発生したときでも、「どのプロジェクトで、どのバージョンの該当パッケージが利用されているか」を即座に特定することが可能です。

幅広いレイヤーのITリスクを一元管理

クラウド・オンプレミス環境に問わず、インフラからアプリレイヤー内のITリスク（脆弱性・EOL・OSSライセンスリスク・クラウド設定不備）を一元管理することができます。

分かりやすいダッシュボードで結果を可視化

お使いのシステム環境に合わせて、検出したITリスクの対応優先度を自動で判別し、結果をダッシュボードに可視化。専門家でなくてもリスクの状況をひと目で把握することができます。

間接依存関係にあるライブラリの脆弱性も瞬時に発見

ライブラリの依存関係をツリー構造で可視化。間接依存関係にあるライブラリの脆弱性も瞬時に発見することができます。

今回侵害にあったTanStackも、どこで使われているのかを瞬時に確認することができます。

政府認定のクラウドセキュリティ評価制度『ISMAP』に登録された唯一の脆弱性管理ツール

yamoryは、政府情報システムのためのセキュリティ評価制度『ISMAP』において、
「唯一、SBOM・脆弱性管理ツールとして登録された国産クラウドサービス」です。

経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」においても、唯一の有償国産ツールとして紹介され、数多くの企業様に導入いただいております。

「TanStackのような重大な脆弱性が発生したとき、すぐに自社システムで使われているかを確認したい」

「ITリスクを一元管理できるサービスを探している」

というご担当者様。
ぜひこの機会に、ISMAP登録済みのセキュアな基盤で、ITリスク管理をスタートしませんか？

国内唯一のISMAP登録済
脆弱性管理ツール

■参考文献

• TanStack「npm Supply Chain Compromise Postmortem」
• StepSecurity blog「TeamPCP's Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages」
• Safedep blog「Mass Supply Chain Attack Hits TanStack, Mistral AI npm and PyPI Packages」