こんにちは！アシスタント 兼 広報のEimiです。
「npmのサプライチェーン攻撃」、ニュースで名前は見かけるけれど、自社の情シスとして結局なにを見ればいいのか。「Shai-Hulud」と、その亜種「Mini Shai-Hulud」の動きを、情シス・コーポレートITの目線で整理してみました。
「うちはnpmパッケージなんて公開していないから関係ない」と思ってしまいがちですが、実はそうとも言い切れません。この記事では、技術の細かい部分よりも、「自社に関係があるのか」「まず何を確認すべきか」 にしぼってお伝えします。
📝 一文でいうと： npmパッケージを自社で公開していなくても、開発者端末やCI/CDに残ったシークレット（認証情報）が狙われるため、影響を受けます。最優先は、CI/CDと開発者端末に露出した可能性のあるシークレットの棚卸しと、予防的なローテーションです。
エグゼクティブサマリー
- npmサプライチェーンワーム「Shai-Hulud」は2025年9月に出現し、初の自己増殖型npmワームとして500超のパッケージ・700超のリポジトリに波及しました。
- 2026年に入り亜種「Mini Shai-Hulud」が登場。正規のCI/CDパイプラインをOIDCで乗っ取り、改ざんパッケージに正当なSLSA Build Level 3の証跡まで付与する初の事例が確認されました（2026年5月11日、CVE-2026-45321）。
- Microsoftの分析では、この5月のキャンペーンはnpm 170超・PyPI 2パッケージ・計404の悪性バージョンに及び、npmとPyPIを同一作戦で同時に侵害した初のサプライチェーン攻撃とされています。
- 攻撃の起点はもはや「盗まれた認証情報」だけではなく、`npm install` 時の自動実行や、Claude Code などAIコーディング支援の設定ファイル（`.claude/settings.json` 等）を使った永続化へと進化しています。
- 2026年5月12日にワームのソースコードが公開され、模倣犯が増加。6月にはRed Hatのnpmパッケージや `node-gyp` を悪用する派生（Miasma系）まで継続しています。
1. 何が起きているのか
Shai-Hulud とは、盗んだnpm/GitHubのトークンを使って正規パッケージにマルウェアを注入し、被害者が公開できる全パッケージへ自動的に再公開していく「自己増殖型のnpmワーム」です。 2025年9月に史上初の自己増殖型npmワームとして出現して以来、亜種・派生を生みながら半年以上にわたって拡大を続けています。まずは、これまでの主な動きを時系列で整理します。
- 2025年9月（初出現）：500超のパッケージ・700超のリポジトリに波及。
- 2025年11月（Shai-Hulud 2.0）：492パッケージ・月間1億3,200万DL規模・25,000超リポジトリに拡大。
preinstallフック（人の操作なしで発火）やホームディレクトリ破壊のフォールバックを追加。 - 2026年4月29日（Mini Shai-Hulud）：SAP開発エコシステムの4パッケージを侵害。この波で、AIコーディングエージェントの設定（
.claude/settings.json）を使った永続化が初めて確認されました。
決定的だったのが2026年5月11日のTanStack侵害です。攻撃者はGitHub Actionsの設定ミス（`pull_request_target`）を突いてキャッシュを汚染し、正規のリリースワークフローとnpmのOIDC公開エンドポイントを乗っ取って、わずか6分間で42個の `@tanstack/*` パッケージに84個の悪性成果物を公開しました（CVE-2026-45321）。 `@tanstack/react-router` だけで週1,270万ダウンロードがあり、被害はMistral AI・UiPath・OpenSearch等へ波及しました。
- 2026年5月12日（ソース公開）：ワームのソースコード（CIキャッシュ汚染、OIDCトークン抽出、認証情報窃取・増殖ロジック）が公開され、模倣犯が発生。
- 2026年5月19日：別アカウント経由で約1時間に323パッケージ・639の悪性バージョンを公開。単一時間あたり最多を記録。
- 2026年6月1日（Miasma）：Red Hatの
@redhat-cloud-services配下32パッケージ（週約8万DL）を、従業員のGitHubアカウント侵害を起点に汚染。感染ごとに固有の暗号ペイロードを生成し、ハッシュ型IOCを無効化。 - 2026年6月4日（Phantom Gyp）：
node-gypのビルドファイル（binding.gyp）で実行する型（57パッケージ）が登場。
💡 ここが転換点： TanStack侵害では、改ざんパッケージに正当なSLSA Build Level 3の来歴証跡（Sigstore発行）が付いた初の事例となり、「来歴が正しい＝中身が安全」ではない、ということが実証されました。Microsoftの分析では、この5月のキャンペーンはnpm 170超・PyPI 2・計404の悪性バージョンに及び、npmとPyPIを同一作戦で同時侵害した初の事例ともされています。
2. なぜ情報システム・セキュリティ担当者に関係するのか
「自社はnpmパッケージを公開していないから関係ない」と考えるのは危険です。攻撃の主目的は、開発者端末とCI/CDランナーに存在するシークレットの窃取だからです。5月の亜種は、GitHubトークンが失効（HTTP 40x）すると `rm -rf ~/`（ホームディレクトリ破壊）を実行する常駐サービスを仕込み、60秒ごとに `api.github.com/user` をポーリングし、24時間で自動停止する設計でした。
実際、OpenAIは社内の2台の従業員端末がTanStack侵害の影響を受けたと開示し、第三者のフォレンジック・IR会社を起用、macOS版アプリの署名証明書をAppleと調整のうえ更新（更新期限を2026年6月26日に延長）したと公表しています。 巨大なAI企業ですら、開発者2名の端末が起点になり得るということです。
窃取対象には、クラウド認証情報（AWS/GCP/Azure）、npm/GitHubトークン、CI/CDシークレット、Kubernetes・Vaultの資格情報、SSH鍵に加え、Claude Code等の設定ファイル（`~/.claude.json`、`~/.claude/mcp.json`、`~/.kiro/settings/mcp.json` など）が含まれます。 AIコーディング支援とMCP連携を全社展開している組織ほど、盗まれて困る接続情報が手元に集まっている、という構造です。
3. よくある誤解
- 「SLSAやSBOMがあれば安全」→ 5月のTanStack事例は正規ビルドを乗っ取ったため、SLSA Build L3の証跡が正しく付いた改ざんパッケージでした。来歴は「ビルド過程の正しさ」を保証するもので、コードの安全性は保証しません。
- 「`preinstall` を無効化すれば防げる」→ 攻撃は `binding.gyp`（node-gyp）やIDEのフォルダオープン、AIエージェントのSessionStartフックなど、ライフサイクルスクリプト以外へ実行点を移しています。
- 「ベンダーが検知・対応済みなら大丈夫」→ Trivy侵害（2026年3月）でも示されたとおり、検知しても認証情報を完全に無効化・再発行できたかが成否を分けます。残存資格情報が後続侵害につながる構図は本系列でも共通です。
- 「IOCをブロックすれば十分」→ Miasma系は感染ごとに固有暗号ペイロードを生成するため、ハッシュ型IOCは特定バージョンにしか効きません。
4. 実務で問題になりやすいポイント
多くの企業で論点になりやすいのは、次のような状態です。
- 誰がいつ発行したか分からないPAT・APIキーが残っている
- CI/CDランナーがゼロトラストの監視射程から外れている
- 開発者端末で、長寿命トークンをローカルに平文で保持している
- AIコーディング支援を各自が自由に導入し、MCP接続が棚卸しされていない
いずれも本系列の攻撃が直接突くポイントです。運用開始後に問題化しやすく、監査や経営説明でも問われやすい領域なので、早めに見ておくと安心です。
5. 技術的・運用的な確認ポイント
- GitHub Actionsの参照をコミットSHAに固定：`@v6` のような可変タグではなく `@<フルSHA>` で参照し、Dependabotで更新運用と両立させる（GitHubの公式ドキュメント「Secure use reference」でも推奨されています）。
- `pull_request_target` の点検：フォークのコードをベースリポジトリの権限で実行していないか、キャッシュスコープ・`GITHUB_TOKEN` の露出がないかを確認する。
- OIDC/短命認証への移行：長寿命のクラウドキーをワークロードIDフェデレーション（GitHub OIDC等）に置き換え、シークレットをKey Vault / Secrets Managerに集約して自動ローテーションする。
- インストール時のランタイム監視：静的解析・依存スキャンだけでは正規ビルドへの直接注入を検知できないため、CIランナーやビルド時のプロセス挙動・想定外の外部通信を監視する。
- `npm ci` とロックファイル固定：再現性のあるインストールにし、必要に応じて `overrides` でバージョンを固定する。
- AIコーディング支援の設定保護：`~/.claude.json` / `~/.claude/mcp.json` 等を機微情報として扱い、MCPトークンは短命化・最小権限・個別revoke可能にする。
6. 対応方針の比較表
| 対応領域 | やること | 主眼となるリスク | 優先度 |
|---|---|---|---|
| CI/CD参照固定 | Action参照をSHA化、`pull_request_target`点検 | 正規パイプライン乗っ取り | 高 |
| シークレット棚卸し・ローテーション | 露出した可能性を前提に予防的に再発行 | 認証情報窃取・横展開 | 高 |
| OIDC/短命認証 | 長寿命キーを排除しJIT化 | トークン流出時の被害範囲 | 高 |
| ランタイム/ビルド監視 | CIランナーの挙動・外部通信を監視 | インストール時実行の検知 | 中 |
| AI支援・MCP統制 | 設定ファイル保護、接続棚卸し、最小権限 | 永続化・接続情報窃取 | 中 |
7. 導入・見直し時のチェックリスト
- 直近数週間にCI/CDランナーへ露出したシークレットを一覧化したか
- クラウドキー・PAT・SSH鍵・OAuth/MCPトークンを失効・再発行できる体制があるか
- サードパーティActionをSHA固定し、Dependabotで更新しているか
- 開発者端末のローカル設定ファイル（AI支援含む）を機微情報として扱っているか
- 感染時に「どれだけ速く無効化・再発行できるか」を実機で確認したか
- 依存パッケージのインストールを `npm ci`（lockfile固定）にしているか
8. 経営層・監査部門への説明ポイント
経営層・監査部門に説明するときの要点は、次の3つに絞れます。
- 攻撃の入口は「派手なゼロデイ」ではなく、開発者1〜2名の端末やCI設定。AI企業ですら起点になり得ます（OpenAIの事例）。
- 来歴証跡（SLSA/SBOM）があっても安全とは限らない。だからこそ、予防的なシークレット・ローテーションと監視への投資が必要です。
- 侵害は前提。評価軸は「防げるか」よりも、「気づいて止め、再発行できるまでの時間」です。
この3点は、投資判断の説明にも、インシデント発生時の報告にも、そのまま使えます。
9. 実務担当者が次に取るべき対応ステップ（優先順位つき）
- CI/CDで露出した可能性のあるシークレットを棚卸しし、予防的にローテーション（最優先）。
- サードパーティActionをコミットSHAに固定し、`pull_request_target` を点検。
- 長寿命クラウドキーをOIDC/短命認証へ移行し、Key Vault/Secrets Managerに集約。
- CIランナー・ビルド時のランタイム監視を整備。
- AIコーディング支援の設定ファイル保護とMCP接続の棚卸し・最小権限化。
10. まとめ
Shai-Huludから始まった一連のnpmワームは、OIDC悪用・正規のSLSA来歴の悪用・AIコーディング支援の永続化・registry横断（npm/PyPI）と、半年で着実に高度化しています。 しかも2026年5月にソースが公開され、模倣と派生（Miasma系）が続いています。
防御の本質はシンプルで、依存を無条件に信頼せず、侵害を前提に「速く無効化・再発行できる」設計と監視を持つことです。まず自社のCI/CDとシークレット、そしてAI支援の設定ファイルから棚卸しを始めてみてください。
よくある質問
Q. Shai-Hulud と Mini Shai-Hulud は別物ですか？
A. 同じワームファミリーの系譜です。Shai-Huludが2025年9月に出現し、2026年に入って高度化した亜種がMini Shai-Hulud、その派生がMiasma系です。
Q. npmパッケージを公開していなければ無関係では？
A. いいえ。主目的は開発者端末・CI/CDのシークレット窃取で、利用しているだけで影響を受けます。OpenAIでも従業員端末2台が影響を受けました。
Q. SLSAやSBOMを導入していれば防げますか？
A. 完全には防げません。5月のTanStack事例は正規ビルドを乗っ取り、正当なSLSA Build L3証跡が付いた改ざんパッケージでした。
Q. 何を最優先で確認すべきですか？
A. 直近にCI/CDへ露出した可能性のあるシークレットの棚卸しと予防的ローテーションです。
Q. AIコーディング支援（Claude Code等）固有の注意点は？
A. 設定ファイル（`~/.claude.json`、`~/.claude/mcp.json` 等）が窃取対象で、永続化にも使われます。機微情報として保護し、MCPトークンは短命・最小権限・個別revoke可能にしてください。
Q. 検知できれば安心ですか？
A. 検知後に認証情報を完全に無効化・再発行できるかが鍵です。残存資格情報が後続侵害につながります。
Q. node-gyp の「Phantom Gyp」とは？
A. `preinstall` 等ではなく `binding.gyp`（ビルド時ファイル）で実行する手法で、多くのツールが見ない箇所を悪用します。Miasma系の一波です。
お気軽にご相談ください！
自社のCI/CD・シークレット・AIコーディング支援の統制状況を一度棚卸ししたい、という方は、現状整理からご相談ください。
クラウドネイティブでは、ゼロトラストの考え方に基づくシークレット管理・CI/CDハードニング・OIDC/短命認証への移行、AIエージェント/MCP利用ポリシーの設計、EDR/SOCによる端末・ランタイム監視まで、設計から運用まで一気通貫で支援しています。
「どこから手を付けるか」の優先順位づけだけでもお手伝いできます。
参考情報
- Snyk「TanStack npm Packages Hit by Mini Shai-Hulud」／発行元：Snyk／種類：セキュリティベンダー調査（一次に近い詳細解析）／公開日：2026-05-11／https://snyk.io/blog/tanstack-npm-packages-compromised/
- Akamai「Mini Shai-Hulud: The Worm Returns and Goes Public」／発行元：Akamai／種類：セキュリティベンダー調査／公開日：2026-05-15／https://www.akamai.com/blog/security-research/mini-shai-hulud-worm-returns-goes-public
- Unit 42（Palo Alto Networks）「The npm Threat Landscape: Attack Surface and Mitigations（Updated June 2）」／発行元：Palo Alto Networks Unit 42／種類：セキュリティベンダー調査／更新日：2026-06-02／https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
- Microsoft Security Blog「Shai-Hulud 2.0: Guidance for detecting, investigating, and defending（Mini Shai-Hulud 追記）」／発行元：Microsoft／種類：ベンダー調査／更新日：2026-05-13／https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/
- OpenAI「Our response to the TanStack npm supply chain attack」／発行元：OpenAI／種類：当事企業の公式声明（一次）／公開日：2026-05-13／https://openai.com/index/our-response-to-the-tanstack-npm-supply-chain-attack/
- The Register「Shai-Hulud malware worms Red Hat npm package versions…」／発行元：The Register／種類：報道（一次はWiz/Socket調査）／公開日：2026-06-01／https://www.theregister.com/security/2026/06/01/shai-hulud-malware-infects-red-hat-npm-packages-downloaded-80k-times-weekly/5249803
- Snyk「Node-gyp Supply Chain Compromise（Phantom Gyp / Miasma）」／発行元：Snyk／種類：ベンダー調査／公開日：2026-06-04／https://snyk.io/blog/node-gyp-supply-chain-compromise-self-propagating-npm-worm-binding-gyp/
- StepSecurity「Shai-Hulud: Here We Go Again（AntV ecosystem, 5月19日波）」／発行元：StepSecurity／種類：ベンダー調査／公開日：2026-05-19／https://www.stepsecurity.io/blog/shai-hulud-here-we-go-again-mass-npm-supply-chain-attack-hits-the-antv-ecosystem
- NHS England Digital「Supply Chain Attack Affecting Numerous npm and PyPI Packages（CC-4781）」／発行元：NHS England／種類：政府機関アラート／公開日：2026-05-12／https://digital.nhs.uk/cyber-alerts/2026/cc-4781
- Microsoft Learn「ゼロ トラスト セキュリティを開発者ワークフローに埋め込む（GitHub OIDC / シークレットスキャン）」／発行元：Microsoft／種類：ベンダー公式ドキュメント／更新日：2025-04-18／https://learn.microsoft.com/ja-jp/security/zero-trust/develop/embed-zero-trust-dev-workflow
- GitHub Docs「Security hardening — Secure use reference」／発行元：GitHub／種類：公式ドキュメント（GitHub ActionsのコミットSHA固定の根拠）／https://docs.github.com/en/actions/reference/security/secure-use
- Wiz「Red Hatのnpmパッケージを狙うサプライチェーン攻撃（Miasma）」／発行元：Wiz／種類：セキュリティベンダーの一次調査（Red Hat波・Miasmaの一次ソース）／https://www.wiz.io/blog/miasma-supply-chain-attack-targeting-redhat-npm-packages
- GitHub Security Advisory「GHSA-g7cv-rxg3-hmpx」／発行元：GitHub／種類：公式アドバイザリ（TanStack侵害の当事者/公式ソース）／https://github.com/advisories/GHSA-g7cv-rxg3-hmpx
