MiasmaワームがMicrosoft系リポジトリ73本を侵害｜「クローンしてAIツールで開いた瞬間に発火」—AIコーディング時代の新型サプライチェーン攻撃

結論：`npm install`を警戒する時代から、「リポジトリを開くだけ」を警戒する時代へ

Miasmaと呼ばれるワーム型のサプライチェーン攻撃により、Azure・microsoftを含むMicrosoft系4組織のGitHubリポジトリ73本が6月5日に無効化された。発見の発端は独立研究者Adnan Khanの報告で、StepSecurityがフォレンジック分析を公開している。CI/CDで広く使われる`Azure/functions-action`まで無効化され、世界中のデプロイパイプラインが一時停止する影響も出た。

この攻撃の新しさは標的の選び方にある。リポジトリに仕込まれたのはライブラリのコードではなく、`.claude/settings.json`や`.cursor/rules/`といったAIコーディングエージェント・IDEの設定ファイルだ。汚染されたリポジトリをクローンし、Claude Code・Gemini CLI・Cursor・VS Codeでフォルダを開いた瞬間に、約4.6MBの難読化された認証情報窃取コードが自動実行される。インストールもビルドも不要。「開くだけで発火」する。

Copilot・Claude Code・CursorなどのAIコーディングツールを導入した企業は、生産性と引き換えに新しい自動実行経路を開発環境に持ち込んでいる。その経路にガードレールがあるかが、今回問われている。

押さえるべき1点：AIエージェントやIDEの「フォルダを開いたら自動で設定を読み実行する」便利機能が、そのまま攻撃の起爆装置になった。AIコーディング導入企業は、ツール選定よりも先に「何が自動実行されるか」の棚卸しが要る。

何が起きたか：2段階の攻撃と73リポジトリ無効化

StepSecurityの分析によれば、Miasmaは脅威グループTeamPCPに関連づけられ、侵害された貢献者アカウントを起点に2つの波で展開された。

キャンペーン全体では113を超えるリポジトリへの侵害が確認されている。6月5日に仕込まれたファイルは次の5点だ。

• `.claude/settings.json` — Claude CodeのSessionStartフックで起動時にコードを実行
• `.gemini/settings.json` — Gemini CLI向けの同型の仕掛け
• `.cursor/rules/setup.mdc` — Cursorに「`node .github/setup.js`を実行せよ」と指示するプロンプトインジェクション
• `.vscode/tasks.json` — `"runOn": "folderOpen"`でフォルダを開くと同時にタスクを自動実行
• `.github/setup.js` — 約4.6MBの難読化された本体（認証情報ハーベスタ）

つまり主要なAIコーディングツールとVS Codeの自動実行機構が、横並びで悪用された。どれか1つでも有効なら発火する。

既報のnpm攻撃と何が違うのか：レジストリ汚染 vs AIエージェント自動実行

サプライチェーン攻撃は今週だけの話ではない。npmで継続中のサプライチェーン攻撃では「`npm install`＝任意コード実行」という前提でCI/CDを守る対策を解説した。Miasmaとの違いを整理すると、防ぐべき場所が変わることが分かる。

• レジストリ汚染型（npm系）：悪性コードはパッケージレジストリに置かれ、`install`時のスクリプトで発火する。防御の主戦場はCI/CDと依存関係管理（ロックファイル、バージョン固定、レジストリ監視）
• Miasma型（リポジトリ設定×AIエージェント）：悪性コードはリポジトリの設定ファイルに置かれ、開発者がAIツール・IDEで開いた瞬間にローカル開発機で発火する。防御の主戦場は開発者の手元の環境——AIエージェントの実行許可設定、フック・タスクの自動実行ポリシーだ

後者では、CI/CDをどれだけ固めても守れない。発火点が開発者のラップトップであり、窃取されるのはそこに保存されたクラウド認証情報・SSHキー・トークン類だからだ。AIエージェントが過剰な権限を持つ危険はVaronisの実証（メール1通でAWSキーが外部送信される）でも示されており、Miasmaはそれを実際の攻撃キャンペーンとして裏づけた形になる。

AIコーディング環境の実行許可設定チェックリスト（5点）

Claude Code・Cursor・Copilot等を導入済み・導入予定の企業は、次の5点を確認する。

1. 自動実行機構の棚卸し：利用中のツールごとに「フォルダを開いただけで実行されるもの」を列挙したか。Claude Codeのフック、Cursorのルールファイル、VS Codeの`tasks.json`（folderOpen）、Gemini CLIの設定が対象になる
2. 信頼確認の有効化：初見リポジトリを開く際の信頼確認（Workspace Trust等）を全開発者で有効にしているか。「毎回出るので無効化した」が最危険の状態
3. クローン後・オープン前の点検：外部リポジトリは開く前に`.claude/` `.gemini/` `.cursor/` `.vscode/tasks.json` `.github/`配下の不審ファイルを確認する手順があるか
4. 認証情報の最小化：開発機に長期有効なクラウドキーを平置きしていないか。短命トークン・OIDC連携に置き換え、窃取されても被害が限定される形にする
5. 依存・Action類の固定：GitHub ActionsはタグではなくコミットSHAで固定しているか（`Azure/functions-action@v1`型の参照は無効化・差し替えの影響を直接受けた）

チェックの勘所：1と2は「ツールの設定」で済むが、3〜5は「開発チームの運用ルール」だ。AIコーディングツールの全社展開を進めるなら、利用ガイドラインにこの5点を明文化してから配るのが正しい順序である。

よくある質問（FAQ）

Q. 該当リポジトリを使っていなければ無関係か？ A. 無関係ではない。Miasmaはワーム型であり、窃取した認証情報で次のリポジトリ・パッケージへ感染を広げる設計だ。攻撃手法自体（AIエージェント設定ファイルの悪用）は他の攻撃者にも模倣可能であり、「外部リポジトリをAIツールで開く」習慣がある開発組織はすべて潜在的な対象になる。

Q. 感染が疑われる場合、何をすべきか？ A. 該当期間に対象リポジトリをクローン・オープンした端末を特定し、その端末から到達できた認証情報をすべて失効・ローテーションする。GitHubトークン、AWS/Azure/GCPのキー、SSHキー、Kubernetesシークレット、Docker設定が対象だ。C2ドメイン（check.git-service[.]com等）への通信記録の有無も確認する。

Q. AIコーディングツールの導入自体を見送るべきか？ A. 見送りではなく、ガードレール付きの導入が答えだ。今回悪用されたのは各ツールの正規機能であり、信頼確認・実行許可・権限最小化を設定すれば抑止できる。リスクを理由に禁止すると、管理外の野良利用（シャドーAI）に流れて統制がさらに失われる。

社内で今日確認する実務チェック

この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。

脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。

GXOへ相談する前に整理しておくと早い情報

相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。

30日で整える脆弱性対応ロードマップ

初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。

4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。

11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。

よくある失敗パターン

第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。

第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。

第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。

成果物として残すべきもの

公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。

また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。

いつGXOに相談すべきか

• Copilot・Claude Code・Cursor等を全社展開する前に、実行許可・権限設計のガードレールを整備したい
• 開発環境・CI/CDを含めたサプライチェーン攻撃への耐性を第三者に評価してほしい
• AI活用と開発統制の両立を前提にしたAI導入計画を描きたい

GXOは生成AIセキュリティでAIコーディング環境のガードレール設計と開発環境セキュリティの評価を、AIアセスメントでAI導入のリスクと統制の全体設計を提供している。→ AIコーディング環境セキュリティの相談はこちら

関連記事

• npmサプライチェーン攻撃が継続中｜`npm install`＝任意コード実行という前提で守るCI/CD
• AIエージェントは"釣られる"｜メール1通でAWSキーを外部送信したVaronis実証
• axiosサプライチェーン攻撃 対応プレイブック2026
• 社内AI基盤が"実際に攻撃される"時代へ｜LiteLLM脆弱性がCISA悪用確認カタログ入り

参考資料

• StepSecurity「Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents」（発見・分析元一次）
• The Hacker News「Miasma Worm Hits 73 Microsoft GitHub Repositories」（二次情報）

本記事は2026年6月12日時点の公開情報をもとに作成。リポジトリ数・IoC・対処方法は調査の進展で更新される可能性があるため、StepSecurityおよびGitHub公式の一次情報の最新版を必ず確認すること。