セキュリティ プログラミング ソフトウェア 公開日 2026.05.15 更新日 2026.05.20

Mini Shai-Hulud Worm とは?2026年5月に判明した npm / PyPI 大規模サプライチェーン攻撃を解説

2026年5月12日に The Hacker News が報じた 「Mini Shai-Hulud」 ワームは、TanStack / Mistral AI / Guardrails AI などを含む npm / PyPI 170以上のパッケージを侵害したサプライチェーン攻撃です。CVE-2026-45321(CVSS 9.6)に紐づくこの事件の手口、被害規模、開発チームが今すぐやるべき対策を整理します。

先に要点

  • Mini Shai-Hulud Worm2026年5月12日 に The Hacker News が報じた、npm / PyPI を横断する大規模サプライチェーン攻撃。脅威アクターは TeamPCP
  • 被害は 170 以上のパッケージ、累計 5.18 億ダウンロード 規模。TanStack(CVE-2026-45321 / CVSS 9.6)Mistral AI(PyPI)Guardrails AI など、開発者が普段使う人気 OSS が直撃された。
  • 攻撃の核は 自己拡散ワーム。盗んだ npm トークンを使って同じメンテナーの他パッケージにも汚染版を公開し、感染を広げる。GitHub Actions cache poisoning や orphaned commit からの侵入も組み合わさっている。
  • 感染すると クラウド認証情報 / GitHub トークン / 暗号資産ウォレット / AI ツール認証情報 が盗まれるほか、npm トークン失効を 60 秒間隔で監視し、失効時に 「rm -rf ~/」 を発火する dead-man's switch や、地域判定で 「rm -rf /」 を確率的に実行するロジック まで仕込まれている。

「Mini Shai-Hulud ってよく聞くけど、結局なに?」 「TanStack の CVE が出たって本当?」 「自分が使ってる npm パッケージは大丈夫?」 ── 2026年5月12日に The Hacker News が報じた Mini Shai-Hulud ワーム は、フロントエンド界隈と AI 開発界隈の両方を直撃する、これまでで最も派手な npm / PyPI サプライチェーン攻撃の1つになりました。

ざっくり言うと、これは npm / PyPI の人気パッケージのメンテナーアカウントを乗っ取り、悪意あるバージョンを公開 → そのパッケージを 「npm install」 した開発者の認証情報をごっそり盗む → 盗んだ npm トークンで同じメンテナーの他パッケージにも感染を広げる という 自己拡散型 の攻撃です。

「Shai-Hulud」 は 2025 年に同様の手口で 700 以上のパッケージを侵害した有名な npm ワームのコードネーム。今回の 「Mini」 はその派生・縮小版という位置づけですが、「TanStack / Mistral AI / Guardrails AI / UiPath / OpenSearch」 といった 誰もが使う基盤系パッケージ が含まれている点で、影響範囲は決して 「Mini」 ではありません。

この記事では、現時点(2026年5月15日)で公開されている情報をもとに、攻撃の全体像・被害パッケージ・手口・自分のプロジェクトで何をすべきか を整理します。 状況は数日単位で更新されるので、最終確認は必ず一次情報(The Hacker News、各パッケージの公式アナウンス、GitHub Advisory、CVE 情報)を見てください。

事件の全体像

まず 「何が、いつ、どこで起きたか」 を一枚で押さえます。

項目 内容
事件名 Mini Shai-Hulud(「Shai-Hulud: Here We Go Again」)
初出 2026年5月12日(The Hacker News)
脅威アクター TeamPCP
主要 CVE CVE-2026-45321(TanStack ルーター関連、CVSS 9.6)
影響パッケージ npm / PyPI 合計 170以上
累計ダウンロード数 5.18 億超
生成された不正リポジトリ GitHub 上で 400 以上
攻撃の性質 自己拡散ワーム + 認証情報窃取 + dead-man's switch ワイパー

「派手な事件名 + 中核 OSS が直撃 + ダウンロード規模が桁外れ」 という3点が揃った、2026年でもっとも語られるであろう事件のひとつです。

被害を受けた代表的なパッケージ

「 自分が触ってる依存に含まれていないか」 を判断するために、代表的なパッケージ群を整理します(報道時点の情報、随時更新される可能性あり)。

npm 側の主な被害

@opensearch-project/opensearch v3.5.3 / 3.6.2 / 3.7.0 / 3.8.0、@squawk/mcp 0.9.5、@squawk/weather 0.5.10、@tallyui/connector-medusa v1.0.1〜1.0.3、TanStack ルーター系の特定バージョン群。

PyPI 側の主な被害

guardrails-ai 0.10.1、mistralai 2.4.6。AI 開発界隈で広く使われるパッケージが直撃された形。

その他

UiPath / DraftLab 系の各種パッケージ。「業務 RPA / クリエイティブ系」 のツールチェーンにも侵入していた。

バージョンが超重要

「 パッケージ名だけ」 ではなく、どのバージョンが汚染されたか までセットで確認しないと過剰反応 / 反応漏れの両方が起きる。「lockfile を世代別に検査」 のような確認が現実的。

「AI 開発と TanStack 系フロントエンド開発のどちらも当事者になっている」 のが、今回の事件の刺さり方を象徴しています。

攻撃の手口 — 4段ロケット

「どうやって入ってきて、何をして、どう広がったか」 を順に追います。これを理解すると、「自分のプロジェクトでも同じことが起きうるか」 を判断しやすくなります。

1. 初期侵入

GitHub fork 経由の orphaned commit

正規リポジトリの fork に対し、「どの履歴にも紐づかない孤児コミット」 を仕込む手口。「正規リポを見ているつもり」 が、攻撃者の改変を読み込んでいる状態にされる。

GitHub Actions cache poisoning

GitHub Actions の cache に攻撃用ファイル」 を仕込み、後続の正規ワークフローがそれを取り込んで実行する流れ。「誰も見ていない CI の隙間」 を突くタイプ。

OIDC トークン抽出

CI ランタイムのメモリから 「OpenID Connect トークン」 を抜き取り、「正規の権限で npm publish できる状態」 に成り済ます。

入口は1つではない

これら複数の入口を 組み合わせ て使う。「どこかは塞いだ」 だけだと足りない、というのが今回の難しさ。

「昔ながらの npm アカウントハック」 ではなく、CI / OIDC / Git の弱点を組み合わせた現代型の手口 なのが、Mini Shai-Hulud の特徴です。

2. マルウェアの仕込み

「乗っ取ったメンテナー権限で、何を仕込むか」 が次のステップです。

npm パッケージ向け

難読化された JavaScript(代表的なファイル名 「router_init.js」)を含む新バージョンを publish。Bun ランタイム経由で実行されるよう仕掛けることで、Node のフックを警戒している監視を素通りする狙いがある。

PyPI パッケージ向け

setup.py の preinstall hook」 から 「node setup.mjs」 を呼ばせ、リモートサーバから認証情報窃取ツールをダウンロード → 実行。「Python パッケージなのに Node が動く」 違和感が罠の本体。

永続化フック

Claude Code / VS Code の永続化フック」 をインストール。一度感染した開発者マシンで、「将来の作業も自動的に乗っ取られる」 状態を作る。

監視サービスの仕込み

「gh-token-monitor」 サービスをインストール。「GitHub トークンが新たに発行されたら横取りする」 のような長期戦の設計。

「一度刺さったら、その後の開発活動も全部見られている」 のが、今回の特に怖い部分です。

3. 窃取・流出

「どんな情報が、どこに流れているのか」 を整理します。

盗まれる情報

クラウドプロバイダー認証情報(AWS / GCP / Azure / Cloudflare 等)、② GitHub トークン、③ npm / PyPI のパブリッシュ用トークン、④ 暗号資産ウォレット、⑤ AI ツールの API キー(OpenAI / Anthropic 等)、⑥ メッセージングアプリの認証情報、⑦ CI/CD システムの認証情報。

流出経路

Session Protocol 系の 「filev2.getsession[.]org」、② GitHub API 経由で 「claude@users.noreply.github.com」 名義のコミットとして攻撃者リポへ送出、③ typosquat ドメイン 「git-tanstack[.]com」、④ 「api.masscan[.]cloud」 系の外部サーバ。複数チャネルに分散 しており、「どれか1つを塞いだ」 では止まらない。

不正リポジトリ生成

盗んだ GitHub 認証で 400以上のリポジトリ を新規作成。多くは 「Shai-Hulud: Here We Go Again」 という文字列を含み、「これ見よがしの示威行為」 とも取れる挙動。

気付きにくさ

「 自分が出した覚えのないコミット」 や 「見たことのない外部通信」 が動くまで気付かないケースが多い。「CloudTrail や GitHub の Audit Log」 を後から見ないと検出が難しい。

「認証情報の流出が一気に多方面 + 大量」 という規模感が、Mini Shai-Hulud の被害を桁違いにしています。

4. 自己拡散と破壊

「Mini Shai-Hulud」 という名前が 「Worm(ワーム)」 を冠する理由が、ここにあります。

自動拡散

盗んだ npm トークンが 「2FA バイパスフラグ」 を持っている場合、感染ホストから 同じメンテナーが公開している全パッケージを列挙」 し、それぞれに汚染版を publish する。「1メンテナーをやられると、そのメンテナーの全 OSS が即倒れる」 という構造。

dead-man's switch

感染プロセスは 60 秒間隔で 「自分の npm トークンが取り消されていないか」 をチェック」。取り消された瞬間に 「 rm -rf ~/」 を実行 し、開発者のホームディレクトリを丸ごと吹き飛ばす。「取り急ぎ npm トークンを失効すれば安全」 という直感の逆を突かれる。

地政学ロジック

Mistral AI PyPI パッケージのコードには ロシア言語環境は回避 / イスラエル・イラン地域では 1/6 の確率で 「rm -rf /」 を実行 という地域別ロジックが埋め込まれていた。「サプライチェーン攻撃が地政学的な破壊行為とも連動する」 警告として注目される。

攻撃者のメッセージ性

不正リポジトリやコミットメッセージに 「Shai-Hulud: Here We Go Again」 を残しており、「2025年の Shai-Hulud の続編」 を意識した示威行為的な側面が強い。「金銭目的だけ」 の犯行ではなく、「コミュニティへの挑戦」 として読める要素もある。

「単に情報を盗まれる」 で済まないのが今回の事件で、「ワイパーで開発環境が消える」 「感染を広げる」 までセットなのが、「できれば踏みたくない地雷」 に変えています。

あなたの現場で今すぐやるべき緊急対応

「自分のチームが踏んでいる可能性があるか」 をどう判断し、何をどの順で実行するか整理します。 迷ったら 急がば回れ、特に npm トークンを直ちに失効させない のが重要なポイントです(失効=ワイパー発火、を防ぐため)。

読み込み中...

「焦って npm トークン失効 → ワイパー発火」 が、いま最も避けたい失敗パターンです。

長期的に積んでおきたい防御

事件対応が終わったら、「次に同種の攻撃が来たときに減衰させる」 ための仕組みを積んでおきます。

SLSA / provenance 検証

npm の 「--audit-signatures」 や PyPI の 「Trusted Publishers」、SLSA provenance の検証を CI に組み込む。「本物のメンテナーから出されたパッケージか」 を機械的に確かめる仕組み。

2FA の厳格運用

「 全 npm メンテナーで 2FA 強制」 「bypass_2fa フラグの利用禁止」。今回の自己拡散は 「2FA バイパスのある古い publish トークン」 が起点。

依存の固定とレビュー

「pinned バージョン」 と pnpm の 「pnpm-lock.yaml」 を必ず commit。「新しいバージョンをそのままアップデート」 ではなく、「変更点をレビューしてから」 のフローを徹底。

CI / OIDC の最小権限

GitHub ActionsOIDC」 を使うときは、対象リポジトリやワークフローを 「必要最小限」 に絞る。「オールマイティな OIDC ロール」 を1個作って使い回す、を避ける。

セキュア秘密管理

「 開発 PC にプレーンテキストで API キー」 を置かない。1Password / Vault / 各クラウドの Secret Manager に寄せる。「コードの隣に .env」 だけで管理する文化は脱却すべきフェーズ。

監視・ロギング

「 開発 PC の発信通信」 を XDR / EDR監視。「Audit Log」 を集中ログ基盤に流して、「見たことのない通信先」 をアラート化。

「攻撃そのものをゼロにする」 のは現実的に不可能なので、踏んだときの被害を縮める / 早く気付く に投資するのが、今回の事件から得るべき本筋です。

AI 時代のサプライチェーン攻撃という側面

Mini Shai-Hulud の特に新しい点は、AI 開発エコシステムを正面から狙った ことです。

AI パッケージへの侵入

「 mistralai」 や 「guardrails-ai」 のような AI 開発の中核ライブラリ」 が直撃された。これらは LLM 連携や AI 出力の検証に使われる、「AI を組み込むなら誰でも触る」 系の依存。

AI ツール認証情報の窃取

OpenAI / Anthropic / その他 LLM プロバイダAPI キーが 明示的に窃取対象 になっている。盗まれたキーで使い切られると、高額請求 系の事故と直結する。

Claude Code への永続化

Claude Code / VS Code に永続化フック」 を仕込む手口は、AI コーディング環境そのものを乗っ取る という新しい段階の攻撃を示している。「AI が書いたコードを実行する場」 が、そのまま攻撃対象になる時代。

対策の方向性

「 AI 連携の API キーは開発 PC に置かない」 「1リクエストごとの使用量上限」 を AI プロバイダ側で必ず設定。「v0 のような外部 AI サービス」 でも、「漏洩時の被害を1台 / 1人 / 1チームに閉じ込める」 設計を意識する。

「AI 開発が便利になればなるほど、その入り口を狙う攻撃も高度化する」 という構図を、Mini Shai-Hulud は非常に鮮やかに見せています。

Mini Shai-Hulud Worm に関するよくある質問

Q. 自分が使ってる npm パッケージのバージョンが新しいけど、もう大丈夫ですか?

A. 公開済みの汚染バージョンを 「install せずに済んでいる」 のが大丈夫の条件です。たとえ最新版に上げていても、過去に一度でも汚染バージョンを 「npm install」 した PC があれば、認証情報は盗まれた前提で対応する必要があります。「lockfile の履歴」 を見て、過去のバージョンを使った形跡があるか確認するのが正解です。

Q. 「npm audit」 で検出できますか?

A. 部分的にしか検出できません。GitHub Advisory に登録されているものは 「npm audit」 で見えますが、新規発覚直後はまだ完全には反映されていないケースが多いです。公式アナウンス + GitHub Security Advisory + The Hacker News などの一次情報 を併用するのが現実的です。

Q. npm トークンを今すぐ失効したいです、危険ですか?

A. ` 感染している PC では dead-man's switch ワイパーが発火する可能性があります。「まずネット隔離 → ディスクをイメージング保全 → そのあと別 PC でトークン取り消し」 の順を踏むのが安全です。「感染していないことが確実」 な PC であれば、即座に取り消しても問題ありません。

Q. PyPI 側だけが被害なら、Node プロジェクトは関係ないですか?

A. 関係あります。今回の PyPI パッケージは preinstall hook 経由で Node スクリプトを呼ぶ 設計でした。「Python のプロジェクトで pip install」 した PC で、「Node で書かれた窃取ツール」 が動いた、という事例があります。「PyPI と npm のクロスプラットフォーム攻撃」 を前提に対策する必要があります。

Q. 開発 PC を Mac mini や Linux で物理的に分離していれば安全ですか?

A. 一定の被害局所化効果はあるのが正直なところです。「開発用 PC が侵害されても、ウォレットや個人 PC は守られる」 という意味で、「本業 PC」 と 「開発 / OSS 触り用 PC」 を分ける運用は依然として有効です。ただし 「CI / クラウド側に持つ認証情報」 はネットワーク越しに盗まれる可能性が残るので、それだけでは完全ではありません。

Q. 今後同種の攻撃を完全に防ぐことはできますか?

A. 現状のエコシステムでは完全防御は不可能です。「npm / PyPI 側のメンテナーアカウント保護」 「OSS の signing / provenance 普及」 が進めば改善方向ですが、`使う側にも 「踏んだときの被害を縮める」 仕組みが必要」 です。「完全に防ぐ」 ではなく 「事故ったとき素早く気付いて止める」 にお金と時間を投資するのが現実解です。

Q. 個人開発者は何をすべきですか?

A. ① Mac / Linux / Windows いずれかに開発 PC を集中させ、本業の業務 PC とは分離、② AI API キーは個人鍵で、月の支出上限を必ずクラウド側で設定、③ ロックファイルをコミットする・無闇に最新版に上げない、④ ` 「CloudTrail 系の Audit Log」 を眺める習慣をつける」 の4つから始めるのが現実的です。チームに属していなくても、「自分の小さな OSS が誰かのキーを盗む踏み台になる」 リスクは確かに存在します。

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。