Deadbugz：4番目のMCP攻撃クラスは、信頼されるまで潜んでいる

重要なポイント

• 74分で23件のプルリクエスト — 単一のGitHubアカウントが2026年8月10日、AI・MCP・開発者ツールの無関係なプロジェクト群にキャンペーンのPRを提出しました。GitHubのレビューメカニズムを通してマージされたものはゼロでしたが、暴露時点で4件がオープンのまま残っていました（Pillar Security）。
• 3回の良性呼び出しの後、メタデータが書き換わる — 悪意あるMCPサーバーはクライアントごとの呼び出しカウンターを保持しています。3回目のtools/callリクエストの後、続くtools/listおよびprompts/getレスポンスは、エージェントにSSH鍵・AWS認証情報・シェル履歴・Kubernetes設定を探索させ、その活動をユーザーから隠すよう指示する内容に変わります。
• ランタイムゲート付きメタデータ汚染は4番目のMCP攻撃クラスである — STDIOコマンドインジェクション → ツールポイズニング → SHAピン留め回避 → 信頼確立後のランタイムゲート付きメタデータ汚染。Deadbugzのメカニズムはデプロイ前の検出が最も困難です。サーバーは初期検査を通過し、ペイロードはクライアントが利用パターンを確立した後にのみ発動するからです。
• ツール定義フィンガープリントが防御策 — 承認時点でツール定義のフィンガープリントを捕捉・比較する。既承認サーバーのツールメタデータに変更があれば、変更されたツールが重要なアクションに影響を与える前に、オペレーターの再承認を要するセキュリティイベントとして扱います。

単一のGitHubアカウントが、テキスト整形と文書要約を行う「productivity-suite」MCPサーバーを謳うプルリクエストを74分で23件提出した。サーバーは最初の3回のツール呼び出しでは正常に振る舞う。4回目で、自身のメタデータを書き換え、接続中のAIエージェントにSSH鍵・AWS認証情報・シェル履歴・Kubernetes設定を探索させ、その活動をオペレーターから隠すよう指示する。2026年9月23日、Pillar Securityはこのキャンペーンを暴露し、23件のプルリクエストのうち4件に埋め込まれた配布アーティファクトdeadbug-mcp.pyにちなんでDeadbugzと名付けた。Cloud Security Allianceはリサーチノートを公開し、Microsoftのazure/durabletaskを含む73のGitHubリポジトリを標的とした過去の「Miasma」キャンペーンとの機械的な類似性を指摘した。

本稿ではDeadbugzのメカニズムをマッピングし、4クラスのMCP攻撃タクソノミーに位置づけ、ギャップを塞ぐ制御を特定する。Plugin4Shell SHAピン留め回避の分析とMCPセキュリティ強化チェックリストの上に成り立っており、両者はDeadbugzが突くギャップを持つ制御を確立済みである。

メカニズム：クライアントごとの呼び出しカウンター

Deadbugzサーバーは、その名の通りの動作をする2つのツール — format_textとsummarize — を提供する。サーバーはtools/callリクエスト用のインメモリのクライアントごとカウンターを保持する。カウンターは0から始まる。通常のツール呼び出しのたびに増加する。3に達すると、続くtools/listとprompts/getのレスポンスが変わる：通常のツールドキュメントの代わりに、接続中のAIエージェントを機密性の高いローカルファイルへ誘導し、その活動をオペレーターから隠すよう指示する内容が含まれる。

これが問題になるのは、MCPのツール定義が単なるラベルではないからだ。クライアントはツール定義を、どのツールを使い、どんなアクションを取るかをモデルが判断するためのコンテキストとしてモデルに供給する。インストール後にそれらの定義を変更できるサーバーは、無害そうなツール名を変えずに、エージェントが目にする指示を変更できる。公開ソースコードは、互換クライアントがツールメタデータを更新できるケイパビリティtools.listChangedを宣伝している — つまりサーバーはクライアントの再接続を必要としない。ツールリストが変わったことをクライアントに通知するだけで、クライアントは新しく汚染された定義をフェッチする。

ランタイムゲートは研究回避テクニックである。短い検査や限定的な自動テストが受け取るのは良性のメタデータだけだ。サーバーはセキュリティレビュー、サンドボックステスト、自動スキャンを通過する。なぜなら、それらの手法は3回の通常のツール呼び出しを行った後にサーバーが次に何を返すかを確認しないからだ。Pillarは閾値ロジックと改変されたメタデータを公開ソースから確認し、良性のテキストのみのリクエストを通じてリモートサービスのゲート発動後のメタデータを観測した。

配布経路：通常の変更に見えるコンフィギュレーション変更

キャンペーンの配布メカニズムは、無関係なリポジトリのMCP設定を追加・変更するGitHubプルリクエストである。レビュー済み23件のうち、17件がプロジェクトの設定ファイルにリモートMCPエンドポイント（productivity-suite-mcp.onrender.com/mcp）を追加していた。4件はPythonに隠れたローカルファイル（~/.config/.cache/.sys/.deadbug-mcp.py）を実行させていた。2件はディレクトリまたは一覧の提出だった。レビュー時点で全23件がGitHubのプルリクエストマージメカニズムを通しては未マージだった — 19件クローズ、4件オープン — しかし、この配布モデルにマージは不要である。設定変更を自身のセットアップにコピーするメンテナー、あるいはPRを見てリンク先リポジトリを訪れ、サーバーを直接インストールする開発者がいれば成立する。

アカウントレベルの配布パターンは組織的だ：同一の公開アカウント（zellkernel）が、2026年8月10日21:52 UTCから23:07 UTCの間に提出した全23件のPRで、同一の製品名・設定テーマ・キャンペーンマーカーを使った。当該アカウントは収集時点で50の公開リポジトリ（うち20はフォーク）を持ち、8月10日だけで21のリポジトリを作成した。このGitHubプロフィールはGitHubアカウントへ逆リンクするXプロフィール（@llmgod）にリンクしており、配布用アイデンティティとAI/LLM関連の公開活動との間に、アカウントに紐づく公開の連結が存在する。

この配布モデルは、Plugin4Shellの分析が文書化したサプライチェーンパターンを拡張するものだ：マーケットプレイスの制御を完全に迂回するベクトルとしての、PR経由の設定変更。Plugin4Shellは、ピン留めされたコミットと同じ名前のブランチを作ることでマーケットプレイスのSHAピン留めを悪用した。Deadbugzはマーケットプレイスを一切使わずにその制御を迂回する — オープンソースプロジェクトのコントリビューションワークフローを通じて直接攻める。

4つの攻撃クラス

MCPセキュリティファミリーには、異なる信頼境界を突く4つの攻撃クラスが存在する：

クラス	メカニズム	初出	検出難易度
STDIOコマンドインジェクション	STDIO設定文字列に埋め込まれた悪意あるコマンド	2026年4月、20以上のCVE（Practical DevSecOps）	中 — 静的解析がシェルメタ文字を検出
ツールポイズニング	良性ツールの説明が承認後に変更され、エージェントを操作する	Invariant Labs、2025年4月、WhatsAppスリーパー	中 — クライアントでのメタデータ変更検知
SHAピン留め回避	SHAと同名のブランチがマーケットプレイスのピン検証を無効化	Plugin4Shell、2026年9月	難 — チェックアウト後の解決済みHEAD表明が必要
ランタイムゲート付きメタデータ汚染	悪意あるメタデータをN回まで隠し、tools/listで届ける	Deadbugz、2026年9月	最難 — デプロイ前テストは閾値を超えない

Deadbugzの攻撃シーケンスと4クラスのタクソノミーを可視化:

各クラスは同じ構造的ギャップを突く：確認を誤ったタイミングでしか行わない、あるいは全く行わない信頼メカニズムだ。STDIOインジェクションは、サニタイズなしの設定文字列を信頼する。ツールポイズニングは、承認後にツールの説明が変わらないことを信頼する。SHAピン留めは、解決済みコミットがピン留め名と一致することを信頼する。ランタイムゲート付き汚染は、テスト中にサーバーが返したものが運用時にも返されることを信頼する。

Deadbugzのデプロイ前検出が最も困難なのは、検査中のサーバーの振る舞いが本当に良性だからだ。悪意あるペイロードは、静的解析がフラグを立てられる形ではコードに隠されていない — クライアントが利用パターンを確立した後にのみ発動するランタイムカウンターの背後にゲートされている。サーバーに接続し、format_textを1〜2回呼び出してレスポンスを確認するセキュリティチームは、何も異常を見出せない。この攻撃は、まさにその種のレビューを通過するよう設計されている。

既存の制御が不十分な理由

MCPセキュリティ強化チェックリストは、トランスポート、認証、ツール登録、ランタイム、監査の5層にわたる12の制御を編成する。Deadbugzはツール登録層とランタイム層のギャップを突く。チェックリストのツール登録制御は、サーバーが本番に入る前にツール名・スキーマ・説明を確認するという、承認時点の検証だ。しかしDeadbugzのツールは承認時点で本当に良性である。ランタイム制御は不正なアクションを監視するが、汚染されたメタデータ自体はアクションではない — エージェントを、その後にエージェントが実行するアクションへ誘導する指示であり、一見それは承認済みの範囲内に見える。

governed-modulesのテーゼ — 監査ログ、レート制限、型付きエラー、キルスイッチアーキテクチャがガバナンス層をセキュリティ境界にするという主張 — は、4番目の攻撃クラスをエビデンスとして得た。Deadbugzのメカニズムは、このテーゼを逆方向から検証する：メタデータ変更検知も、ツール定義フィンガープリントも、エージェントが目にする内容のオペレーターに見えるdiffも持たないサーバーこそ、キャンペーンが突く攻撃面そのものだ。

防御策：ツール定義フィンガープリント

Pillarの推奨は具体的で実装可能だ：承認時点でツール定義フィンガープリントを捕捉・比較する。MCPクライアントがサーバーを承認する際、サーバーが返すすべてのツール定義 — 名前、説明、入力スキーマ、アノテーション — のハッシュを記録する。サーバーが後にツールリストの変更を通知すると（tools.listChanged経由）、クライアントは新しい定義をフェッチし、フィンガープリントと比較し、差分をセキュリティイベントとしてオペレーターに提示する。変更されたツールは、オペレーターが再承認するまで重要なアクションに影響を与えられない。

この制御がDeadbugzの突くギャップを塞ぐのは、デプロイ前のテストに依存しないからだ。信頼境界が越えられた後のランタイムで、サーバーが実際に配信するメタデータを監視する。フィンガープリント比較は、ランタイムゲートがいつ発動しても — 3回でも30回でも300回でも — メタデータ書き換えを検知する。この制御は、より早いツールポイズニングクラス（Invariant LabsのWhatsAppスリーパー）も検知する。両攻撃が同じメカニズム、すなわち承認後に変更されるツール説明を共有しているからだ。

本番でMCPサーバーを運用するチームのための4つの実装ステップ：

1. 承認時点でツール定義フィンガープリントを記録する。 初回接続時にサーバーが返すすべてのツール定義をハッシュ化する。フィンガープリントは、エージェントの構成管理システム内でサーバーの承認記録と並べて保存する。
2. tools/listとprompts/getのレスポンスをドリフト監視する。 サーバーがツールリストの変更を通知したら、新しい定義をフェッチし、保存済みフィンガープリントと比較する。差異はすべてメタデータドリフトイベントとしてフラグを立てる。
3. 変更されたツール定義にはオペレーターの再承認を要求する。 変更されたツール定義は、人間のオペレーターが差分をレビューし明示的にサーバーを再承認するまで、エージェントの挙動に影響を与えてはならない。これにより、サイレントなメタデータ書き換えが可視なセキュリティイベントに変わる。
4. 機密ファイルの読み取り、認証情報アクセス、コード実行はポリシーでゲートする — ツールメタデータではない。 Deadbugzのペイロードは、SSH鍵・AWS認証情報・Kubernetes設定を探索するようエージェントに指示する。それらの読み取りは、リモートのツールメタデータに含まれる指示の結果ではなく、明示的な認可を要求するポリシー施行のアクションであるべきだ。Shadow AIエージェントの分析は、メタデータ駆動の認証情報探索が検知されるかどうかを決めるランタイム制御のギャップを文書化している。

関連記事

• SHAピン留めは検証ではない：Plugin4Shellと初のAIエージェント・サプライチェーンRCE — 3番目のMCP攻撃クラス。DeadbugzのPRベースの配布モデルとサプライチェーン標的を共有する
• MCPセキュリティ強化チェックリスト：1,467の露出サーバーとそれを塞ぐ制御 — 12制御のベースライン。ツール定義フィンガープリントはツール登録層とランタイム層に属する
• MCPセキュリティ：20万の脆弱インスタンスがgoverned modulesを購買基準にする理由 — Deadbugzが検証するgoverned-modulesのテーゼ：ガバナンス制御を持たないサーバーこそ、キャンペーンが突く攻撃面である

---

中堅のB2Bディストリビューターが、MCPモジュール経由でNetSuite・BigCommerce・3つのサプライヤーカタログに接続する調達エージェントを運用している。チームのセキュリティレビューは、新しいMCPサーバーごとに接続し、ツールを2回呼び出し、レスポンスを確認する。Deadbugzはそのレビューを通過する。チームはMCPクライアント設定にツール定義フィンガープリントを追加する — すべてのサーバーの初期ツール定義は承認時にハッシュ化され、tools/listレスポンスはドリフト監視され、変更された定義は、変更ツールがエージェントの挙動に影響を与える前にオペレーターの再承認ゲートを発火させる。次のメタデータ汚染キャンペーンは、認証情報の露出ではなく、フラグ付きの差分とレビューになる。

スコープ定義済みビルドを依頼する。 1週間のディスカバリー。システムインベントリ、ワークフローマップ、確定スコープをお届けする — 当社での構築の有無は問わない。