Shai-Hulud（シャイ・フルード）とは？npmサプライチェーン攻撃の全体像と2.0・Mini最新動向、影響確認と対策

Shai-Hulud（シャイ・フルード）は、JavaScriptのパッケージレジストリnpmを舞台に広がった自己増殖型のサプライチェーン攻撃です。2025年9月に初めて確認されて以降、手口を変えながら「2.0」「Mini」と波状的に再来しており、開発者・組織にとって継続して警戒が必要な脅威になっています。この記事では、Shai-Huludとは何かという基本から、3つの波の違い、攻撃の仕組み、盗まれる情報、そして「自分は影響を受けたのか」の確認方法と侵害時の対応・予防策までを、最新動向を踏まえて整理します。

まとめ（先に結論）

本記事の要点を先にまとめます。

• 正体：Shai-Huludは、汚染されたnpmパッケージを起点に、開発環境から認証情報を盗み、盗んだトークンで別のパッケージを汚染して自動的に広がるワーム型のサプライチェーン攻撃です。
• 3つの波：初代（2025年9月）→ Shai-Hulud 2.0「The Second Coming」（2025年11月）→ Mini Shai-Hulud（2026年4月〜）と進化し、規模も手口も拡大しています。
• 影響の可能性があるなら最優先で：汚染バージョンを入れた疑いがあるなら、まずnpm・GitHub・クラウド・SSHなど全クレデンシャルの失効と再発行、preinstall/postinstallの自動実行停止、ロックファイルでのバージョン固定を行ってください。詳細は後半の「確認」「対応」で解説します。

以下、定義から順に詳しく見ていきます。

Shai-Huludとは何か：名前の由来と「なぜ危険か」

「Shai-Hulud」という名称は、SF小説『デューン』に登場する巨大な砂漠の蠕虫（ワーム）に由来します。攻撃者が盗んだ情報を置くGitHubリポジトリ名に使ったことから、研究者の間で攻撃の呼称として定着しました。名前のとおり、このマルウェアは一度侵入すると自分自身を複製し、次々と新たなパッケージへ広がる性質を持ちます。

従来のnpm向け悪性パッケージの多くは「インストールした人の情報を盗んで終わり」でした。Shai-Huludが一線を画すのは、盗んだ公開（publish）権限を使って被害者を次の感染源に変える点です。これにより、ひとりの開発者の侵害が、その人が管理する全パッケージ、さらにその利用者へと連鎖します。npmエコシステムで初の本格的なワーム型攻撃とされ、ソフトウェア供給網の弱点を浮き彫りにしました。

3つの波の全体像：初代・2.0・Miniの違い

Shai-Huludは単発の事件ではなく、複数回にわたって再来しています。まず全体像を時系列で押さえると理解しやすくなります。

初代 Shai-Hulud（2025年9月）

人気パッケージ@ctrl/tinycolorの不審な新バージョンを糸口に発覚しました。インストール時のpostinstallスクリプトでマルウェアが起動し、秘密情報を収集して被害者のGitHub上に公開リポジトリ「Shai-Hulud」を作成、そこへ窃取データを公開するという手口です。最終的に180以上のパッケージが連鎖感染しました。

Shai-Hulud 2.0「The Second Coming」（2025年11月）

2025年11月下旬、同系統の第二波が確認されました。最大の変化は、実行タイミングをpostinstallからpreinstall（インストール処理の前段）へ移したこと。これにより、依存解決の途中でも発動し、開発者マシンとCI/CDの双方で影響範囲が広がりました。新たにsetup_bun.jsでBunランタイムを導入し、bun_environment.jsで本体を実行する多段構成を採用。さらに、窃取・送信に失敗した場合にユーザーのホームディレクトリ破壊を試みる報復的な挙動が報告され、データ窃取から破壊へと危険度が増しました。約700以上のパッケージ、25,000を超えるGitHubリポジトリ、約1.4万件のシークレット流出に及び、Zapier・ENS Domains・PostHog・Postman・AsyncAPIなど著名なパッケージが一時的に汚染されました。

Mini Shai-Hulud（2026年4月〜）

2026年は「TeamPCP」とされる攻撃グループによるMini Shai-Huludが登場しました。4月29日にSAPのCAP系パッケージを起点に始まり、5月11〜12日には172パッケージ・約404の不正バージョンへ一気に拡大。特筆すべきは、npmとPyPIの両レジストリを同一キャンペーンで同時に侵害した初の事例であること、そして有効なSLSA Build Level 3のprovenance（来歴証明）を持つパッケージまで突破したことです。供給網の信頼性そのものを揺るがす内容で、@tanstack（react-router等）・@uipath・@mistralai・@opensearch-projectといった広く使われるスコープが対象になりました。6月1日にはMini Shai-Huludの亜種「Miasma」によって、Red Hatのnpmパッケージ（@redhat-cloud-services）も侵害が確認されています。ワームのソースコードが公開されたことで模倣犯も現れており、収束したとは言い切れません。

攻撃の仕組み：どう侵入し、どう広がるのか

波によって細部は異なりますが、基本の流れは共通しています。概念として理解しておくと、後述の「確認」「対応」が腑に落ちます。

• 侵入：汚染パッケージをインストールすると、ライフサイクルスクリプト（preinstall／postinstall）経由でマルウェアが自動実行される。
• 秘密情報の収集：シークレット検出ツールTruffleHogなどを使い、.npmrcのnpmトークン、.env、SSH鍵、クラウドの認証情報を探索する。クラウド上ではメタデータサービスから一時キーを取得することもある。
• 外部送信：窃取データを攻撃者のサーバーではなくGitHubの公開リポジトリに置くことで、通常の通信監視をすり抜ける。
• 持続化：被害者のリポジトリに悪性のGitHub Actionsワークフローを仕込み、以後も継続的に情報を抜き取る。
• 自己増殖：盗んだnpmトークンで被害者が管理する別パッケージに悪性版を公開し、感染を連鎖させる。

2.0以降は、ここにpreinstall化（より早い段階で発動）、Bunランタイムの利用、窃取失敗時のホーム破壊、Miniでのnpm＋PyPI横断とSLSA突破が加わり、検知と防御の難易度が上がっています。なお、npmの依存に潜む脆弱性とサプライチェーン防御の具体例は、CVE-2026-40175（axios）のサプライチェーン防御解説も参考になります。

盗まれる情報（影響の対象範囲）

Shai-Huludが狙うのは、開発の利便性のために手元に置かれている各種クレデンシャルです。代表的なものは次のとおりです。

• npmアクセストークン（.npmrc 等）：パッケージの不正公開に悪用される。
• GitHub Personal Access Token（PAT）：リポジトリ操作やアカウント乗っ取りの足がかりになる。
• クラウドの認証情報（AWS／GCP／Azureのキー、メタデータ経由の一時トークン）：インフラ侵入につながる。
• SSH秘密鍵：サーバーへのなりすましログインを許す。
• 環境変数中の秘密（DB接続情報、各種APIキー）、Kubernetes/Vaultなどのシークレット。

一つでも漏れれば重大インシデントに直結します。盗まれた情報はクラウドリソースの不正利用、ソースコード改ざん、社内ネットワークへの横展開など二次被害の起点になり得ます。

自分は影響を受けたか確認する方法

「汚染パッケージを入れていないか」を確認するポイントを挙げます。いずれも調査・検知のための安全な操作です。

• 不審な公開リポジトリ：自分や組織のGitHubに、説明文へ「Shai-Hulud」「Sha1-Hulud」を含む見覚えのないリポジトリが作られていないか確認する。
• 悪性ワークフロー：.github/workflows/ 配下に shai-hulud-workflow.yml など身に覚えのないファイルや、不審なブランチ・プルリクエストがないか確認する。
• ペイロードの痕跡：2.0以降は setup_bun.js / bun_environment.js が痕跡になる。PyPI経由のMiniでは /tmp/transformers.pyz の有無も確認対象。
• 身に覚えのない公開：自分のnpmパッケージに、自分が上げていないバージョンが公開されていないか確認する。
• 依存の特定：ロックファイルで対象パッケージの該当バージョンが含まれていないかを照合する。

ファイルの探索や依存の確認には、たとえば次のような読み取り中心のコマンドが使えます（環境に応じて読み替えてください）。

# 侵害指標となるファイルが残っていないか探索（読み取りのみ）
find . ~ -type f \( -name "bun_environment.js" -o -name "setup_bun.js" \) 2>/dev/null

# 特定パッケージが依存ツリーに含まれるか確認
npm ls <パッケージ名>

# ロックファイル内に該当バージョンが無いか確認
grep -n "<パッケージ名>" package-lock.json

該当が見つかった、あるいは強く疑われる場合は、次の「侵害時の対応」に進んでください。

侵害時の対応手順

影響が疑われるときは、被害拡大を止めることが最優先です。以下の順で進めます。

• 隔離：該当端末・CIランナーをネットワークから切り離し、汚染した node_modules を削除してキャッシュをクリアする（rm -rf node_modules ／ npm cache clean --force）。
• 全クレデンシャルのローテーション：npmトークン、GitHub PAT、クラウドのアクセスキー、SSH鍵、その他のシークレットを「すべて漏れた前提」で一斉に失効・再発行する。フィッシング耐性のあるMFAを併せて見直す。
• GitHubの修復：不審な公開リポジトリ、悪性ワークフロー、shai-hulud 系ブランチ、関連プルリクエストを削除し、公開されてしまったリポジトリは非公開に戻す。監査ログで他の不正操作も確認する。
• クリーン再構築：ロックファイルを見直してクリーンなバージョンで再インストールする。重要サーバーが侵害された場合はOSからの再構築も検討する。
• 調査の記録：流出範囲の特定と再発防止のため、痕跡（ログ・ファイル）を保全する。

クラウドキーが漏れた疑いがあるときは、アクセスログ（AWS CloudTrail等）で不審な操作がないかも確認しましょう。

再発防止・予防策

Shai-Hulud系の攻撃は手口を変えて再来します。設計レベルで「入っても広がらない」体制を整えることが有効です。

• ライフサイクルスクリプトの抑制：CI/CDでは npm install --ignore-scripts（または npm ci --ignore-scripts）を基本にし、preinstall/postinstallの自動実行を絞る。
• バージョン固定：ロックファイルを必ずコミットし、依存は自動更新せず内容を確認してから上げる。pnpmやcorepackでの管理はpnpmとcorepackによるバージョン管理が参考になる。
• 認証の強化：開発・CIアカウントにフィッシング耐性MFAを適用し、npmは短命・スコープ限定のトークンやTrusted Publishingへ移行する。認証技術の動向はDBSCとパスキーが示す認証セキュリティの方向性も押さえておきたい。
• 初期侵入対策：多くの起点はアカウント乗っ取り＝フィッシングである。組織的な対策はフィッシング対策ガイドライン2026年度版とDMARC強化が指針になる。
• 監視と封じ込め：ビルド環境からの外部通信を信頼先に限定し、「Shai-Hulud／Sha1-Hulud」を含む新規リポジトリや、身に覚えのないパッケージ公開を監視する。SBOMで依存の所在を可視化しておくと影響範囲を素早く特定できる。
• ランタイムの最新化：土台であるNode.js自体の脆弱性対応も怠らない。最近の事例はNode.jsの深刻度Highの脆弱性を参照。

よくある質問（FAQ）

Q. Shai-Huludとは何ですか？
A. 汚染されたnpmパッケージを起点に開発環境の認証情報を盗み、盗んだトークンで別パッケージを汚染して自動的に広がる、自己増殖型のサプライチェーン攻撃です。2025年9月の初代以降、2.0・Miniと再来しています。

Q. 自分のプロジェクトが影響を受けたか、どう確認すればいいですか？
A. GitHubに「Shai-Hulud／Sha1-Hulud」を含む不審な公開リポジトリや悪性ワークフローがないか、setup_bun.js／bun_environment.js などの痕跡がないか、身に覚えのないパッケージ公開がないかを確認します。依存はロックファイルで該当バージョンの有無を照合します。

Q. 初代と2.0の違いは？
A. 初代（2025年9月）はpostinstallで実行し、TruffleHogで秘密情報を集めてGitHubの公開リポジトリ「Shai-Hulud」へ窃取データを置きました。2.0（2025年11月）は実行をpreinstallへ前倒しし、Bunランタイムの利用と、窃取・送信に失敗した際にホームディレクトリを破壊する報復機能を追加して、規模・破壊力ともに拡大しています。

Q. 2.0とMini Shai-Huludの違いは？
A. 2.0（2025年11月）はpreinstall実行・Bun利用・窃取失敗時のホーム破壊が特徴です。Mini（2026年）はnpmとPyPIを横断し、有効なSLSA Build Level 3のprovenanceを突破した点が新しく、規模も手口も一段と高度化しています。

Q. npm以外のエコシステムも対象ですか？
A. はい。Mini Shai-HuludではPyPI（Python）も同時に侵害されました。npmだけでなく、Pythonを含む依存全体を確認・防御の対象に含めるべきです。

Q. 侵害が疑われるとき、最優先でやるべきことは？
A. 端末・CIの隔離と、npm／GitHub／クラウド／SSHなど全クレデンシャルの即時ローテーションです。「すべて漏れた前提」で一斉に失効・再発行するのが安全です。

関連記事

• CVE-2026-40175がCVSS満点10.0と評価された理由と開発現場への緊急度
• pnpmとcorepackを使ったNode.jsとpnpmのバージョン管理のまとめ
• Node.jsに深刻度「High」の脆弱性が発覚 – バージョン20.x/22.x/24.x/25.x系統に影響
• フィッシング対策ガイドライン2026年度版が示すDMARC強化の全体像
• DBSCの標準化動向とパスキー連携が示す認証セキュリティの未来