2026年6月、自己増殖型の供給網ワーム「Shai-Hulud」から派生した複数の亜種が、npmとPyPIを同時に襲った。中心にいるのが、PyPIを標的とする新系統「Hades」と、npmを標的とする「Miasma」、そしてRustで書かれた別系統「IronWorm」だ。Socket Threat Researchの集計では、この一連の波で合計471個の悪性アーティファクトが確認されている。
今回の波がこれまでと違うのは、攻撃者が明確に「MCP（Model Context Protocol）開発者」と「バイオインフォマティクス研究者」を狙い撃ちにした点だ。langchain-core-mcp や openai-mcp のような、いかにも本物らしい *-mcp パッケージがPyPIに大量投入された。さらにHadesの悪性コードは、AIベースのコードスキャナを撹乱する「偽のシステム指示」を仕込むという新手口まで備えていた。
本記事は攻撃ペイロードのコードは一切掲載しない。代わりに、Socket・JFrog・SecurityWeekの一次解析をもとに、何が起きたかの整理と、自分の環境を守るための検知・対応・復旧コマンドだけを体系化する。
サプライチェーン攻撃全体の防御フレームワークと恒久対策は、上位のサプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリストで俯瞰している。本記事はその配下で「2026年6月のAI開発者狙いワーム」に絞った各論だ。
- Shai-Hulud系ワームが npm 411バージョン（106パッケージ）＋ PyPI 60アーティファクト（37パッケージ）＝合計471 を汚染した（Socket集計）。
- Hades＝PyPI狙い、Miasma＝npm狙い、IronWorm＝Rust製の別系統。2026年6月に同時多発した。
- 狙いは
*-mcp命名のtyposquatと、Claude Code・Cursor・OpenAI Codexの設定ファイルに残る本物のAPIキー。 - Hadesは
.pth起動フックで importせずとも自動実行し、偽のシステム指示でAIスキャナを撹乱する新手口を持つ。 - 対策は単発では効かない。--ignore-scripts既定化・provenance検証・egress allowlist・即時ローテーションの多層で初めて成立する。
何が起きたか——Shai-HuludからHades・IronWormへの系譜
時系列を整理する。すべての起点は2025年9月に観測された初代「Shai-Hulud」だ。これは盗んだ認証情報で自分自身を別のパッケージへ注入し続ける、自己増殖型のnpmワームだった。
転機は2026年5月中旬だ。攻撃グループ「TeamPCP」がワームのソースコードを公開したことで、模倣亜種が一気に量産される土壌ができた。5月19日の@antv npmパッケージ汚染（Mini Shai-Hulud）は、その公開後に起きた「コンテスト参加型」攻撃の典型例だった。
そして6月に入り、亜種は名前と標的を変えながら波状的に押し寄せた。
2025年9月
npm自己増殖ワーム"] --> B["ソースコード公開
2026年5月中旬
TeamPCPが流出"] B --> C["Mini Shai-Hulud
npm亜種の量産"] C --> D["Miasma
The Spreading Blight
npm狙い"] C --> E["Hades
The End for the Damned
PyPI狙い・MCP標的"] C --> F["IronWorm
Rust製ELF
eBPF＋Tor C2"] D --> G["2026年6月
同時多発
合計471アーティファクト"] E --> G F --> G
各系統の命名には意味が込められている。Miasmaは「広がる瘴気（The Spreading Blight）」、Hadesは「呪われし者の終焉（The End for the Damned）」を名乗る。攻撃者がブランド化を意識している点に、模倣の連鎖が長期化する兆候が見える。
公称された被害規模（一次ソースの数値のみ）
推測を排し、各社が公表した数値だけを並べる。
| 指標 | 数値 | 出典 |
|---|---|---|
| 悪性アーティファクト合計 | 471 | Socket |
| npm（バージョン数 / パッケージ数） | 411 / 106 | Socket |
| PyPI（アーティファクト数 / パッケージ数） | 60 / 37 | Socket |
| Hades PyPI波（wheel数 / パッケージ数） | 37 / 19 | Socket（6月7日公開） |
| IronWorm汚染npmパッケージ数 | 36 | JFrog / BleepingComputer |
| IronWormが狙う環境変数 | 86 | JFrog |
| IronWormが狙う認証ファイル | 20種超 | JFrog |
| IronWormが鍵を抜くAI/MLプラットフォーム | 14 | JFrog |
タイムラインも一次ソースに沿って整理する。
| 日付 | 出来事 |
|---|---|
| 2025年9月 | 初代Shai-Hulud campaign観測 |
| 2026年5月中旬 | TeamPCPがワームのソースコードを公開 |
| 2026年6月1日 | 新たな協調攻撃波が始動 |
| 2026年6月5日 | npm 57パッケージ超を確認 |
| 2026年6月7日 | SocketがHades PyPI波（37 wheel / 19パッケージ）を公表 |
| 2026年6月8日 | 第2次Hades PyPI波を検知 |
Hadesの手口——importせずに走る .pth ローダー
HadesがMCP開発者にとって厄介なのは、「インストールしただけで発火する」点だ。通常のマルウェアは汚染パッケージを import して初めて動くが、HadesはPythonの起動メカニズムそのものを悪用する。
Socketの解析によれば、悪性wheelには *-setup.pth というファイルが含まれる。Pythonの site モジュールはインタプリタ起動時にこの .pth を処理するため、被害者が当該パッケージをimportしなくても、インストール直後の起動だけで自動実行される。これが「startup execution primitive（起動時実行プリミティブ）」だ。
実行経路は3つの分岐が確認されている。
・.pth 起動フック方式：*-setup.pth が _index.js ペイロードを同梱し、起動時に呼び出す
・ネイティブ拡張方式：.abi3.so ネイティブ拡張がimport時にJavaScriptを実行する
・ローダー分離方式：langchain-core-mcp で確認された手口。.pth が sys.path を走査して _index.js を探し出し、ペイロード本体は別に置く
.pth ローダーは、GitHubから Bun v1.3.13 ランタイムをダウンロードし、難読化された _index.js を実行する。Bunを使うのは、システムにNode.jsが無くてもJavaScriptペイロードを走らせるためだ。盗む対象は、GitHubトークン・AWS/GCP/Azureのクラウド資格情報・Kubernetesシークレット・SSH鍵・.env ファイルに及ぶ。
新手口：偽のシステム指示でAIスキャナを撹乱する
今回もっとも注目すべき進化が、_index.js の冒頭に置かれた「偽のシステム指示」だ。Socketによれば、ペイロードは巨大なJavaScriptブロックコメントから始まり、その中に偽のシステム指示やポリシー誘発文（policy-triggering content）が書き込まれている。
狙いは、LLMベースのコードスキャナや解析用コパイロットを撹乱することだ。具体的には、AIに拒否応答・プロンプト混乱・文脈汚染・早期の誤分類を起こさせ、解析の手を止めさせる。人間のレビュアーには単なるコメントでも、AI支援の自動解析パイプラインを狙い撃ちにする「対AI防御回避層」になっている。
- 従来の難読化は「機械的なパターンマッチ」を逃れる狙いだった。
- 偽システム指示は「LLMの判断そのもの」を逆手に取る。AIコードレビューを導入したチームほど刺さる。
- 対策：AIスキャナの出力を鵜呑みにせず、
.pth実行行・リモートランタイム取得・subprocess実行という決定論的なシグナルで二重に判定する。
確認された悪性パッケージ一覧
Socketが公表したパッケージ名を、性質ごとに分けて掲載する（バージョンは確認済みのもの）。いずれもインストール禁止。正規パッケージのtyposquatである点に注意してほしい。
| 分類 | パッケージ名 | 確認バージョン | 狙い |
|---|---|---|---|
| MCP関連 typosquat（PyPI） | langchain-core-mcp | 1.4.2 / 1.4.3 | LangChain利用者を誘導 |
openai-mcp | 2.41.1 / 2.41.2 | OpenAI SDK利用者を誘導 | |
instructor-mcp | 1.15.2 / 1.15.3 | 構造化出力ライブラリ偽装 | |
tiktoken-mcp | 0.13.1 / 0.13.2 | トークナイザ偽装 | |
ray-mcp-server | 0.2.1 | 分散処理MCPサーバ偽装 | |
| 汎用 typosquat（PyPI） | rsquests | — | requestsの綴り違い |
tlask | — | タスクライブラリ偽装 | |
rlask | — | 同上 | |
| バイオインフォ系（Hades PyPI波） | dynamo-release | — | 高DL（数十万）の本命標的 |
spateo-release | — | 高DL（数十万）の本命標的 | |
coolbox | — | ゲノム可視化 | |
ufish / napari-ufish | — | FISHスポット検出 | |
pantheon-agents / pantheon-toolsets | — | エージェント系偽装 | |
bramin / cmd2func / magique 他 | — | 計19パッケージ・37 wheel |
Hades PyPI波の19パッケージ全体は、bramin・cmd2func・coolbox・dynamo-release・executor-engine・executor-http・funcdesc・magique・magique-ai・mrbios・napari-ufish・nucbox・okite・pantheon-agents・pantheon-toolsets・spateo-release・synago・ufish・uprobe だ。中でも dynamo-release と spateo-release は数十万ダウンロード規模のバイオインフォマティクスツールで、研究機関のCI環境への波及が懸念されている。
IronWorm——Rustで書かれた「もう一段上」の併発系統
Hades・Miasmaと同時期に、JFrog Security Researchが別系統の「IronWorm」を解析した。これはShai-Huludと多くの特徴を共有しつつ、実装言語と機能で一段上のものになっている。
IronWormはRustで書かれたLinux向けELF実行ファイルだ。BleepingComputerの報道とJFrogの解析によれば、36個のnpmパッケージを汚染し、初期侵入アカウントは asteroiddao だった。Arweave/WeaveDBエコシステム（Web3系）を起点に広がった点も特徴だ。
機能面では、従来のインフォスティーラーを大きく超える。
・86個の環境変数と20種類超の認証ファイルを窃取する
・14のAI/MLプラットフォーム（Anthropic・OpenAI・Gemini・Cohere・Mistral・Groq・Perplexity・xAI ほか）のAPIキーを収集する
・eBPFカーネルルートキットでプロセスやファイルを隠蔽する
・Torネットワーク経由のC2通信でオペレーターと連絡する
・npmのTrusted Publishing（OIDCトークン）を悪用して自己増殖する
とりわけ深刻なのは、AI開発ツールの設定ファイルを名指しで狙う点だ。JFrogが挙げた認証パスには、~/.claude/.credentials.json、~/.codex/auth.json、~/Cursor/auth.json、~/.gemini/settings.json が含まれる。AWS・Docker・Kubernetesの標準的な設定や、Exodus暗号通貨ウォレットのファイルも対象だ。
さらに痕跡の隠蔽も巧妙だ。悪性コミットの作者名を「claude」に偽装し、AnthropicのAIによる正規のコミットに見せかける。タイムスタンプは過去に遡って改ざんされ、JFrogによれば最大13年前まで遡るバックデートが、9つのGitHub組織にまたがる57件のコミットで確認された。
AI開発ツールの認証情報を狙う攻撃の防御設計は、多層防御でトークン窃取を止める実践ガイドで詳しく扱っている。本記事はその攻撃側の最新事例にあたる。
三系統を一枚で比較する
「総まとめ」として、Hades・Miasma・IronWormの違いを整理しておく。同じShai-Hulud系でも、レジストリ・実装・隠蔽手法が異なるため、検知の当たりどころも変わる。
| 観点 | Miasma | Hades | IronWorm |
|---|---|---|---|
| 別名の意味 | The Spreading Blight | The End for the Damned | （Shai-Huludの鉄製いとこ） |
| 主標的レジストリ | npm | PyPI | npm（Web3起点） |
| 実装 | JavaScript（Bun実行） | JavaScript（.pth＋Bun） |
Rust（Linux ELF） |
| 起動契機 | インストールフック | .pth 起動時実行 |
preinstall＋依存解決前 |
| 特徴的な隠蔽 | 署名を通す | 偽システム指示でAI撹乱 | eBPFルートキット＋Tor C2 |
| 主な標的層 | npmメンテナ | MCP・バイオインフォ研究者 | AI/Web3開発者 |
この比較から分かるのは、「1つの検知手法では3系統すべてを捕まえられない」ということだ。npmのフック監視だけではPyPIの .pth を見逃し、署名検証だけではIronWormのOIDC悪用を止められない。だからこそ、次章の多層防御が要る。
なぜMCP開発者が狙われるのか——2つの構造的理由
攻撃者がバイオインフォマティクスと並んでMCP開発者を選んだのは偶然ではない。2つの構造的な理由がある。
理由1：*-mcp 命名の急増がtyposquatの土壌を作った
MCP（Model Context Protocol）の普及で、server-mcp・xxx-mcp・mcp-yyy といった命名の正規パッケージがnpm・PyPIに急増した。新しい命名規則が定着する過渡期は、利用者が「どれが本物か」を判断しにくい。攻撃者はこの曖昧さに付け込み、langchain-core-mcp のような「あってもおかしくない名前」を投入した。
実際、MCPサーバーは「LangChainやOpenAI SDKと組み合わせて使う」ケースが多く、langchain や openai に -mcp を足した偽物は、急いでいる開発者ほど信じてしまう。
理由2：AI開発ツールの設定に本物のAPIキーが眠っている
MCP開発者の端末には、Claude Code・Cursor・OpenAI Codex・Geminiの設定ファイルが揃っていることが多い。そしてこれらの設定には、課金に直結する本物のAPIキーが平文で保存されているケースが珍しくない。
攻撃者から見れば、MCP開発者の端末は「高価値の認証情報が1か所に集まった宝箱」だ。1台踏むだけで、複数のLLMプロバイダのキー・GitHubトークン・クラウド資格情報をまとめて奪える。IronWormが14ものAIプラットフォームを列挙していたのは、この「まとめ取り」を最大化する設計に他ならない。
~/.claude/.credentials.json"] A2["Cursor 認証
~/Cursor/auth.json"] A3["Codex 認証
~/.codex/auth.json"] A4["SSH鍵 / .env"] end subgraph L2["第2層：開発インフラ"] B1["GitHubトークン"] B2["npm / PyPI 公開トークン"] B3["クラウド資格情報
AWS / GCP / Azure"] B4["Kubernetes Secret"] end subgraph L3["第3層：拡散"] C1["管理パッケージへ
悪性版を公開"] C2["GitHubリポへ
悪性バイナリ注入"] C3["CI/CDで連鎖感染"] end A1 --> B1 A2 --> B3 A3 --> B2 A4 --> B4 B1 --> C2 B2 --> C1 B3 --> C3 C1 --> C3
この図のとおり、被害は「端末→インフラ→拡散」と段階的に広がる。最初の1パッケージを止められなくても、層の境界（特に第2層→第3層）で食い止められれば、ワーム化を防げる。
検知・対応・防御——実践コマンド
ここからは、攻撃コードではなく守る側のコマンドだけを扱う。自分の環境に当てはめて実行してほしい。
Step 1. 汚染パッケージとIoCを検知する
まずロックファイルで本文の悪性パッケージ名を確認する。
# npm / pnpm
grep -E "langchain-core-mcp|openai-mcp|instructor-mcp|tiktoken-mcp|ray-mcp-server" \
package-lock.json pnpm-lock.yaml 2>/dev/null
# PyPI（requirements / uv / poetry）
grep -E "dynamo-release|spateo-release|coolbox|ufish|pantheon-agents|rsquests" \
requirements*.txt uv.lock poetry.lock 2>/dev/null
次にHades特有のファイルシステム指標（IoC）を探す。
# Hadesの起動時実行プリミティブの痕跡
find "$(python3 -c 'import site; print(site.getsitepackages()[0])')" \
-name "*-setup.pth" -o -name "_index.js" 2>/dev/null
# Bunが落とされた痕跡
ls -la /tmp/.bun_ran 2>/dev/null
# Pythonが外部からBunを取得していないか（実行中プロセス確認）
ps aux | grep -i "bun" | grep -v grep
Step 2. インストール時のスクリプト実行を止める
.pth やpostinstallフックの自動実行を抑止する。CI環境から既定化するのが安全だ。
# npm: postinstallフックを全面無効化
npm config set ignore-scripts true
# あるいはプロジェクトの .npmrc に記述
echo "ignore-scripts=true" >> .npmrc
# pip: ビルド分離と隔離を活用（信頼できないwheelは入れない）
pip install --require-hashes -r requirements.txt
Step 3. 署名・来歴（provenance）を検証する
「署名された＝安全」ではないが、provenance検証は偽パッケージの多くを弾ける。
# npm: パッケージ署名の検証
npm audit signatures
# PyPI: pip-auditで既知の悪性・脆弱性を確認
pip install pip-audit && pip-audit
# SLSA provenanceの検証（公開元の来歴確認）
slsa-verifier verify-artifact <artifact> \
--provenance-path <provenance> \
--source-uri github.com/<org>/<repo>
Step 4. 多層で固める（SBOM・Cooldown・Egress）
単発の検知では取りこぼす。次の多層を組み合わせる。
・SBOM生成と差分監視：syft でSBOMを生成し、依存の増減を継続監視する
・Sigstore / cosign：成果物に署名し、検証を必須化する
・Cooldown（公開直後の隔離）：公開から一定時間経過していないバージョンをCIで採用しない
・Admission Control：未署名・未検証のパッケージをビルドに入れない
・GitHub Actions allowed-publishers明示：Trusted Publisherを明示し、OIDC悪用の余地を狭める
・egress allowlist：CI Runnerの外向き通信を許可リスト方式にし、github.com/oven-sh/bun/releases/download/ やTor出口への通信を遮断する
公開から十分な時間?"} B -->|No| X["採用しない"] B -->|Yes| C{"provenance / 署名
検証OK?"} C -->|No| X C -->|Yes| D{"npm audit signatures
pip-audit クリーン?"} D -->|No| X D -->|Yes| E{"Egress allowlist
不審な外部通信なし?"} E -->|No| X E -->|Yes| F["ビルド許可
SBOMに記録"]
特に egress allowlist は、今回のHades（Bun取得）とIronWorm（Tor C2）の双方に効く。たとえペイロードが起動しても、外部への通信を断てば認証情報の持ち出しと拡散を止められる。
すでに被害を受けた場合の復旧手順
IoCに1つでも該当したら、「侵害された」前提で動く。順番を間違えると、ローテーション前に攻撃者が先に動く。
GitHub・npm・PyPIトークン
SSH鍵・クラウド資格情報"] B --> C["2. AI APIキー再発行
Anthropic・OpenAI・Gemini 等"] C --> D["3. 自分の管理パッケージ点検
不審な新バージョン公開の有無"] D --> E["4. GitHub点検
見覚えのないリポジトリ・
偽装コミット作者 claude"] E --> F["5. CI Runner破棄
クリーンビルドへ置換"] F --> G["6. node_modules / venv 削除
クリーンインストール"] G --> H["7. egress / SBOMで再発防止"]
各ステップの要点を補足する。
・ローテーションが最優先：ネットワーク遮断より先に、漏れた可能性のあるトークンを無効化する。攻撃者は窃取後すぐに動くため、時間との勝負だ
・AI APIキーは必ず再発行：Claude Code・Cursor・Codexの設定に残っていたキーは漏洩前提。再発行と同時に旧キーを失効させる
・自分が加害側になっていないか確認：ワームは盗んだ公開トークンで「あなたの管理パッケージ」に悪性版を出す。npm・PyPIの公開履歴を点検する
・偽装コミットを探す：作者名 claude の見覚えのないコミットや、不自然にバックデートされた履歴がないか確認する
・CI Runnerは使い捨てる：感染したRunnerはクリーンにせず破棄し、新しいクリーンイメージで再構築する
これらを終えたら、再発防止として前述の多層防御（Cooldown・provenance・egress allowlist・SBOM）を恒久化する。一度のインシデント対応で終わらせず、パイプラインの既定設定に組み込むことが肝心だ。
まとめ——MCP普及の影で進む「便乗型」供給網攻撃
2026年6月の波が示したのは、攻撃者が「新しく普及した技術の命名規則」と「AI開発ツールに集まる高価値の認証情報」の両方に、極めて素早く便乗するという現実だ。
・HadesはPyPIの *-mcp typosquatと .pth 起動時実行で、importせずとも発火する
・偽システム指示という対AIスキャナの撹乱層は、AIコードレビューを導入したチームほど注意が要る
・IronWormはRust製ELFとして14のAIプラットフォームの鍵を名指しで狙い、作者名を claude に偽装する
・防御の本質は単発の検知ではなく、–ignore-scripts・provenance検証・Cooldown・egress allowlist・即時ローテーションの多層化にある
MCPやAIエージェントの開発に関わるなら、自分の端末は「複数LLMのキーが集まる宝箱」だという前提で守りを設計してほしい。攻撃コードを追う必要はない。本記事の検知・対応・復旧コマンドを、いま自分のCIと端末に当てはめることが最善の一歩だ。
AI固有の脅威を体系で俯瞰したい場合は、AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドも参照してほしい。
参照ソース
・Socket Threat Research「Mini Shai-Hulud, Miasma and Hades worms target bioinformatics and MCP developers via malicious packages」 https://socket.dev/blog/mini-shai-hulud-miasma-and-hades-worms-target-bioinformatics-and-mcp-developers-via-malicious
・Socket Threat Research「Shai-Hulud Descends to Hades: Miasma PyPI Wave」 https://socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave
・JFrog Security Research「IronWorm: Shai-Hulud’s rustier cousin」 https://research.jfrog.com/post/iron-worm-shai-hulud-rustier-cousin/
・SecurityWeek「Over 100 NPM, PyPI Packages Hit in New Shai-Hulud Supply Chain Attacks」 https://www.securityweek.com/over-100-npm-pypi-packages-hit-in-new-shai-hulud-supply-chain-attacks/
・BleepingComputer「New IronWorm malware hits 36 packages in npm supply-chain attack」 https://www.bleepingcomputer.com/news/security/new-ironworm-malware-hits-36-packages-in-npm-supply-chain-attack/
