メインコンテンツへスキップ
security 20分で読める

npmのMiasmaワームがAIコーディングツールを狙う:全3波の攻撃詳細と対策

この記事はこんな人におすすめ
  • Node.js/npmを使うフロントエンド・バックエンドエンジニア
  • Claude Code、GitHub Copilot、CursorなどAIコーディングツールを日常的に使う開発者
  • CI/CDパイプラインでnpm installを実行しているチームのリードエンジニア・DevOps担当

「since the tooling was made publicly available, other threat actors now have access to the same techniques and can replicate or adapt them(ツールが公開されたことで、他の脅威アクターも同じ手法にアクセスでき、複製・改変が可能になった)」。Aikido SecurityリサーチャーのIlyas Makari氏が6月1日に発表したレポートでこう警告した(Aikido Security)。HackerNewsに立ったスレッドでは同日中に200件超のコメントが集まり、「自分のパイプラインもこのスコープを間接依存に含んでいた」という報告が相次いだ(HN thread)。

2026年6月1日、@redhat-cloud-services npmスコープ配下の32パッケージが汚染された。RedHatInsights GitHubオーガニゼーションへの不正コミットを起点に、4.2 MBの難読化ペイロードがnpmのpreinstallフックとして埋め込まれた。攻撃者は盗んだnpm OIDCトークンを使って感染を被害者のパッケージへと自己複製する「ワーム」として機能させた。週次ダウンロード数は80,000〜117,000件。そして6月3日には新バリアントが確認され、AIコーディングIDEを開いた瞬間にバックドアが実行される仕掛けまで加わった(Snyk Blog)。

Miasmaワームの攻撃手順: 感染から自己増殖まで

攻撃の起点はRedHatInsightsのGitHubオーガニゼーションへの不正コミットだ。どのようにしてコミット権限を得たかは執筆時点で未公開だが、盗まれたサービスアカウントの認証情報か、OAuthトークンの横流しが疑われている(Microsoft Security Blog)。

不正コミットが通ると、攻撃者はnpmへの新バージョン公開をトリガーする。公開されたパッケージには4.2 MBの難読化Javascriptがpackage.jsonscripts.preinstallフィールドに仕込まれており、npm installを実行した時点で自動的に起動する。

盗まれる情報の一覧

ペイロードが実行されると、以下を網羅的にスキャンして外部サーバーに送信する。

  • GitHub Actions OIDCトークン / 個人アクセストークン
  • AWS アクセスキー・セッショントークン
  • GCP アプリケーションデフォルト認証情報・サービスアカウントキー
  • Azure サービスプリンシパル・マネージドIDトークン
  • HashiCorp Vault トークン
  • Kubernetes サービスアカウント・kubeconfigファイル
  • npm / PyPI publish トークン
  • SSH秘密鍵
  • Dockerレジストリ認証情報
  • GPGキー
  • すべての .env ファイル

そして、入手したnpm OIDCトークンを使って被害者が管理する他のnpmパッケージにも同じペイロードを仕込んだ新バージョンを公開する。これが「ワーム」的な自己増殖の仕組みだ。CI/CDパイプラインが自動でそのパッケージを使っているプロジェクトがあれば、感染が連鎖する(Orca Security)。

Phantom Gyp: セキュリティツールをすり抜ける新技術

6月3日に確認された第2バリアントは、さらに一歩進んだ技術を使う。セキュリティ研究機関StepSecurityが「Phantom Gyp」と命名したこの手法は、binding.gypというビルド設定ファイルを悪用する(StepSecurity Blog)。

従来の悪意あるnpmパッケージのほとんどはpreinstallまたはpostinstallライフサイクルスクリプトにペイロードを仕込む。この手口はすでに広く知られており、Snyk・Socket.dev・npm auditを含む多くのセキュリティツールが検知対象にしている。

Phantom Gypが使うbinding.gypは、ネイティブNode.jsアドオンをコンパイルするためのビルド設定ファイルだ。このファイルにコマンドが記述されていると、npm install実行時にnode-gypが呼び出されてビルドとして処理される。わずか157バイトのbinding.gypファイルで、インストールスクリプトを監視するセキュリティツールの大半をすり抜けながら任意コードを実行できる。

「これは既知の攻撃ベクターの再発見ではなく、セキュリティ産業が長年見落としてきたブラインドスポットへの攻撃だ」とStepSecurityはレポートで指摘した。

なぜAIコーディングツールが標的になるのか

Miasmaの第2バリアントが際立っているのは、AIコーディングIDEへの標的化だ。感染したパッケージをnpm installした環境では、プロジェクトのリポジトリに特定のファイルが書き込まれる。そのファイルは、開発者がVS Code・Cursor・Claude Code・JetBrainsなどのAIコーディングツールでプロジェクトを開いた瞬間に実行される。

攻撃者がAIコーディングツールを狙う理由は明快だ。

第一に、AIコーディングツールはプロジェクト全体のコンテキストを読む。コードベース全体・環境変数・設定ファイルにアクセスするため、IDEが起動する文脈でコードが実行されれば大量の機密情報にアクセスできる。

第二に、AIコーディングツールはCI/CDに統合されることが多い。Claude Code GitHub Actions、GitHub Copilot for CI、Cursor Backgroundなどのエージェント機能はクラウド認証情報を必要とし、それらが仕込まれたバックドアの格好の標的になる。

第三に、開発者はAIツールへの信頼が高い。「AIが提案したコード」という文脈でのファイルの変更は、人間が直接書いたコードより見落とされやすい。

同日に汚染が確認された@vapi-ai/server-sdk(月間408,000DL超の音声AIエージェント開発SDK)の4バージョン(0.11.1、0.11.2、1.2.1、1.2.2)は、AIネイティブな開発者コミュニティを直接狙ったものだ(Corgea Research)。

第3波: IronWorm(6月5日)— AIキーを狙う高度亜種

6月5日、さらに高度な亜種「IronWorm」が確認された。Rust製の976KB ELFバイナリを核に、eBPFカーネルルートキット、Tor経由のC2サーバー、そして86の環境変数と20以上の認証情報ファイルパスを標的とする(Phoenix Security)。

IronWormが特に際立つのは、AI関連の認証情報を明示的に標的リストに含む点だ。

  • AnthropicのAPIキー(~/.claude.jsonを含む)
  • OpenAI APIキー
  • Google Gemini認証情報
  • Cohere、Mistral、Groq、Perplexity、xAI APIキー

Claude Codeを使っている開発者の~/.claude.json(Claude CodeのAPIキーが保存される設定ファイル)も標的だ。IronWormはMicrosoftのAzure GitHub組織にまで到達し、4組織・73リポジトリが無効化されたと報告されている(OX Security)。3波を通じた月間DL数への影響は累計60万件超と推定される。

Miasmaの由来: オープンソース化されたマルウェアフレームワーク

Miasmaは完全に新規のツールではない。攻撃者はTeamPCPが2026年5月12日に公開した「Mini Shai-Hulud」フレームワーク(Frank Herbertの小説『デューン』のサンドワームにちなんだ名前)をベースにしている。TeamPCPはMITライセンスでGitHubに公開すると同時に、BreachForumsで「このコードを使った最大の供給チェーン攻撃に1,000ドルの賞金」というコンテストを開催した。GitHubはリポジトリを削除したが、複数のフォークの流通を防ぎきれなかった。Miasmaの作者はこのフレームワークをギリシャ神話の「瘴気(ミアズマ)」という名前でリブランドし、Red Hatのnpmエコシステムを最初の標的に選んだ(The Register)。

この背景が示すのは、高度なサプライチェーン攻撃の「民主化」が進んでいる現実だ。数年前なら国家レベルの攻撃者だけが持ち得た能力が、今ではオープンソースのフレームワークを組み合わせるだけで再現できる。公開からMiasmaの実行まで3週間しかかからなかった。セキュリティ研究者の間ではこの傾向を「ワーム・アズ・ア・サービス」と呼び始めている。

今すぐとるべき対策

ステップ1: 影響確認

# 直接依存の確認
npm ls | grep "@redhat-cloud-services"
# トランジティブ依存を含む確認
npx npm-check --production
# 監査実行
npm audit

@redhat-cloud-services/*パッケージが含まれている場合、次のステップに進む。

ステップ2: シークレットのローテーション

影響パッケージのインストール履歴がある環境では、以下をすべてローテーションすること。

  • GitHub Personal Access Token / GitHub Actions のシークレット
  • AWS IAMアクセスキー(AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY
  • GCPサービスアカウントキー
  • npmのアクセストークン
  • .envファイルに記載されていたすべての値

ステップ3: バックドアの検出

AIコーディングツールを使っている場合、プロジェクトに不審なファイルが追加されていないか確認する。

git log --all --oneline --diff-filter=A -- "*.js" "*.sh" "*.py" | head -20
git diff HEAD~10 --name-only

最近の不審なファイル追加(見覚えのないスクリプト・設定ファイル)は精査すること。

ステップ4: 再発防止

  • CI/CDではnpm ci(lockfileからの決定論的インストール)を使い、npm installを避ける
  • GitHub Actionsではstep-security/harden-runnerを導入してネットワーク外への通信をブロックする
  • socket.devsnykを依存関係スキャンに組み込む
  • Renovate/Dependabotの自動更新に対してPRレビューを必須にする

npmエコシステムの光と影

Miasmaが突きつけるのは、npmエコシステムの根本的な構造問題だ。

問題: npmのデフォルト設計ではインストール時スクリプトの実行が許可されている。binding.gypのような正規ユースケース向けのファイルさえも攻撃ベクターになりうる。

対策の限界: npm install --ignore-scriptsを常用すればリスクは下がるが、ネイティブアドオン(bcrypt、argon2など)が動作しなくなるケースがある。

npmの対応: npmレジストリはMiasma発覚後に汚染バージョンを取り下げたが、レジストリ自体の設計(インストール時スクリプトの制限)には着手していない。npmはこれまでも同様の問題(event-streamインシデント、node-ipcインシデント)に直面してきたが、根本的なアーキテクチャの変更には至っていない。

「npmは実質的に任意コード実行を許可するパッケージマネージャーだ」というのはHackerNewsコミュニティでの定番の批判だが、今回の攻撃はその批判に新たな証拠を加えた(HN discussion)。

希望の兆し: Socket.devはAIを使った悪意あるパッケージのリアルタイム検知を提供しており、@redhat-cloud-servicesの汚染を数時間以内に特定した。StepSecurityのharden-runnerはCI/CDでの不審な外部通信をブロックできる。技術的な対策は存在する。問題は多くのプロジェクトがそれを導入していない点だ。

Miasmaと先行する類似事例

npmサプライチェーン攻撃はMiasmaが初めてではない。2018年のevent-stream事件(暗号通貨ウォレット窃取)、2022年のnode-ipc事件(ウクライナ戦争に絡んだデータ破壊コード)、2024年のxzインシデント(LinuxのSSHデーモンへのバックドア挿入)と、信頼されたパッケージへの長期潜伏・汚染は繰り返されてきた。Miasmaの新しさは「ワーム的自己増殖」と「AIコーディングツールの標的化」の組み合わせだ。

同じくnpmが関係したセキュリティ事案としてClaude Codeソースコード流出の全貌も読んでほしい。AIコーディングツール自体のセキュリティ設計についてはClaude Codeのセキュリティアナウンスを読むで解説している。VS Code拡張機能の脆弱性についてはVS Code拡張機能の脆弱性まとめが参考になる。

詳しく見る

関連記事


本記事の情報は2026年6月9日時点。影響パッケージのリスト・バリアントの情報はSnyk・StepSecurity・GitHub Advisoryで継続的に更新されている。最新の汚染パッケージ一覧は各セキュリティベンダーの公式情報を参照すること。本記事に記載の手順は一般的なガイダンスであり、具体的な対応は各組織のセキュリティチーム・インシデントレスポンス担当者の判断に基づいて行うこと。本記事は特定ツールの安全性を保証するものではなく、セキュリティ上の決定を代替するものでもない。本記事に記載の数値・日付・影響範囲は各セキュリティ研究機関の報告に基づく。外部リンク先の内容については当サイトは責任を負わない。

Share