Deadbugz：3回目のツール呼び出しで敵対行動に転じるMCPサーバー、74分で23のリポジトリにプッシュ

2026年8月10日、あるGitHubアカウント、zellkernelが、23件のプルリクエストを74分間で、無関係なAI、MCP、開発ツール関連のリポジトリに対して開きました。各プルリクエストは、productivity-suiteという名前のMCPサーバーを追加し、そのサーバーは2つのありふれたツール、format_textとsummarizeを宣伝していました。Pillar Securityによると、同社はこのキャンペーンをDeadbugzと名付け、その分析記事を8月12日に公開しました。サーバーは最初の3回の呼び出しでは正直な結果を返し、その後、エージェントに渡すメタデータを書き換えました。ツールの説明とプロンプトの内容は、モデルを次のものへと誘導し始めました：SSHキー、AWS認証情報、シェルの履歴、Kubernetes設定へと向かわせ、その活動をユーザーから隠すよう指示しました。23件のプルリクエストのうち19件はクローズされ、4件は依然としてオープンで、Pillarがレビューした時点ではマージされたものは1件もありませんでした。被害者は確認されていません。これは1件の記録であり、他者によって報告され、ここではその他者を出典として引用しています。文書化された他のエージェント事案は、それぞれ独自の情報源、深刻度、信頼度評価、異議フラグを持ち、AIインシデントアーカイブに収録されています — したがって、エージェント向けツールを狙うサプライチェーン・キャンペーンを、実際に起きた他の出来事と並べて読むことができます。

アーカイブはこの記録を高い重大度・信頼度Aと評価している——十分に文書化されており、一次資料も一致している——一方で、確認された実際の被害はないと別途記録している。両者は同時に真であり、その隔たりこそがこの記録の主題だ。誰も名前を挙げられる被害者を生み出す前に、その設計が異例なほど詳細に文書化されていたキャンペーンなのである。重要な二つの日付は二日違いだ。プルリクエストは8月10日に送信され、Pillar SecurityのAriel Fogelは8月12日に分析を公開した。そしてその投稿には、検証済みの情報が入り次第更新するという常設の注記が付されている。

3回呼び出すと、メタデータが変わります

MCPサーバーは、エージェントの動作を変えるためにマシン上でコードを実行する必要はない。ツール定義は毎セッション、コンテキストとしてモデルに渡される。つまり、それを提供するサーバーは、ツールの名前、そのリポジトリ、そのマニフェストをそのままにした状態で、エージェントが読む指示を書き換えられる。Deadbugz はこの非対称性を前提に構築されており、Pillar はこれを「runtime-gated MCP metadata poisoning」と呼んでいる。

仕組みは一文で述べられるほど小さい。サーバーはクライアントごとのカウンターをメモリ内に保持し、tools/call リクエストを数える。最初の3回は正常に動作する。カウンターが作動すると、その後の tools/list および prompts/get の応答は改変されて返る — ツールの説明が異なり、プロンプトの内容も異なる — エージェントを SSH 鍵、AWS 認証情報、シェル履歴、Kubernetes 設定へと向け、その活動をユーザーから隠すよう指示する。汚染されたプロンプト文にはマーカー deadbugz とビットコインアドレスが含まれている。

ゲートがあることも、通常の防御ではこれを検知できない理由だ。ペイロードは最初のリクエストからソース内に存在しており、切り替えの瞬間にコードや設定が変わるわけではない。静的スキャン、SBOMエントリ、インストール時のツールマニフェストの一度きりの読み取りでは、フォーマット用ユーティリティしか見えない。カウンターが動くまで、そのユーティリティが返すのはそれだからだ。Pillarは遅延切り替えを研究回避手法と表現し、同社の研究者は、稼働中のリモートサービスにテキストのみのリクエストを送り、応答を公開ソースと照合することで、しきい値と改変されたメタデータの両方を確認したと述べている。

ある細部によって、この罠は単一のセッションを超えて広がります。サーバーが通知するのはtools.listChanged、クライアントにツール一覧が改訂されたことを伝えるMCP機能です。その信号に従うクライアントは、セッションの途中で定義を再読み取りし、運用者の操作なしに汚染されたバージョンを取得します。承認時に定義をキャッシュするクライアントはそうしません。特定のエージェントがどちらの挙動を取るかは、サーバーではなくクライアントの特性であり、Pillarの記事はクライアントを名前で列挙していません。

デリバリー：74分で23件のプルリクエスト

その配布物は、レジストリ上のパッケージでも、ロックファイルに埋め込まれた汚染された依存関係でもなかった。それは、そのサーバーが本来果たすはずの機能とは何の関係もないプロジェクトに対するプルリクエストのスパムであり、これは攻撃者がメンテナーアカウントを取得できないときに低コストのサプライチェーン攻撃が取る形である。十分な数の設定変更を提出し、そのうちの一つがマージされるか、ローカルで適用されるのを待つのである。

Pillarによる23件の内訳は3種類に分かれる。17件はリモートMCPエンドポイント（productivity-suite-mcp[.]onrender[.]com/mcp）を追加する。これはRender上でホストされている。4件は隠されたローカルPythonファイル、~/.config/.cache/.sys/.deadbug-mcp.pyを呼び出す。2件はディレクトリまたはリストへの投稿で、記事ではこれを配信ではなく偵察や穴埋めとみなしている。時間枠は2026年8月10日のUTC午後9:52から午後11:07とされており、開示の枠組みでは74分だが、2つのタイムスタンプ自体は75分にまたがり、記録上その1分が意味を持つことはない。個別に名前が挙げられている対象リポジトリは1つだけである: getsentry/sentry-mcp、プルリクエスト#1239。これはローカル成果物による配信の例として挙げられている。

その背後にあるアカウントは、その年齢にしてはかなりの規模だった。Pillarの収集時点で、zellkernelは50の公開リポジトリを持ち、そのうち20がフォークで、50のうち21はキャンペーンと同じ日の8月10日に作成されていた。プロフィールはXアカウント@llmgodと相互リンクしており、そのXアカウントはGitHubアカウントへとリンクし返していた。これは、乗っ取られたものではなく目的をもって作られた身元を裏付ける種類の相互リンクだ。

クローズ19件、オープン4件、マージ0件は、この記録の中で最も多く繰り返される数字であり、同時に最も頻繁に「問題なし」と解釈される数字でもあるが、完全にそうとは言えない。GitHubのマージボタンはホスト側の実行記録ではない。メンテナーはブランチをプルして実行でき、設定を手作業で適用できる。またCIジョブは、誰かがコメントする前にPRのheadを取得することもできる。ローカルスクリプトのパスを呼び出す設定を書き込む4件のプルリクエストこそ、そのギャップが最も重大となるケースだ。なぜなら、そのスクリプトはGitHubのマージ集計の完全な外側で取得され、実行されるからだ。Cloud Security Alliance Labsも9月2日の注記で同じ点を指摘している。クローズ済みおよび未マージの件数は、何も実行されなかったことを証明しない。

何が確立されており、何が確立されていないのか

開示によって裏付けられている。Pillar が自ら読んだ成果物から、そして1件については自ら問い合わせたサービスから報告したという意味において。すなわち、サーバーとそのソースリポジトリ、宣伝されていた2つのツール、カウンターと3回呼び出しのしきい値、4つの認証情報ターゲット、レビュー時点での PR 件数とそのマージ状況、そして GitHub アカウントと X ハンドルの結びつきである。Pillar 自身がライブエンドポイントに対して行ったテストが、このリストの中で最も強い項目である。なぜならそれはソースコードを読むことではなく、再現だからである。

被害者については、立証されておらず、記録もその点に慎重だ。アーカイブの real_harm フィールドは false であり、これは意図ではなく証拠に関する記述である。このキャンペーンに結びつくホスト、ログ、盗まれた資格情報を誰も提示していない。zellkernel と @llmgod の背後にいる人物やグループも特定されていない。Pillar はこの作戦をアカウントに帰属させ、そこで止めている。金銭的動機はペイロードに埋め込まれた Bitcoin アドレスに基づいているが、これは指標からの推論であって、行為者に関する調査結果ではない。そして防御側が最も答えを知りたい問い——このキャンペーンがまだ進行中かどうか——に、記録は答えていない。投稿は更新される予定のものとして記されていたが、GitHub や Render からの後続の改訂や削除通知は確認できない。

裏付けは、信頼度評価が示唆するよりも薄く、このことは率直に言っておく価値がある。2件のCloud Security Alliance Labsの調査ノートは、2026年8月30日付と9月2日付で、このキャンペーンを再説明している。後者のノートは、発見、PR の詳細、サーバーの挙動、アカウントの帰属について Pillar の功績だと明言しており、独自の独立検証については何も述べていない。また、Armor の2026年9月22日付ブログ記事は防御ガイダンスを提供し、Pillar がサーバーを分解調査したと述べているが、独自のフォレンジック証拠は示していない。CVE は割り当てられておらず、CSA はこれは MCP 仕様の脆弱性ではないと述べている。2026年10月29日時点で、検索しても GitHub や Render からのアドバイザリは見つからず、主流のセキュリティ業界媒体でも報道がない — BleepingComputer、The Register、SecurityWeek、Hackread のいずれの記事もない — これはこの形のサプライチェーン攻撃としては異例であり、それ自体が記録が示すことの一部である。ここで「一次資料は一致している」とは、起点となる一次資料が1つと、そこから派生した一連の二次資料があることを意味する。

小さな曖昧さが2つあり、ならして済ませるのではなく指摘する価値がある。二次要約は、3回目と4回目のどちらの呼び出しが最初に汚染されたメタデータを受け取るかで異なっており、これはカウンタが3回目のリクエストで作動すると説明されていることから来ている。記録と開示はいずれも3を用いている。また、配信ウィンドウは、75分にまたがるタイムスタンプに対して74分と説明されている。

再確認できなかった検証が1件ある。2026年10月29日時点で、GitHubアカウントzellkernelとリポジトリzellkernel/productivity-suite-mcpはいずれも404を返し、個別に名前が挙げられていたプルリクエスト getsentry/sentry-mcp #1239 も解決しなくなっている——当のリポジトリは現在 getsentry/toolkit にリダイレクトされている。したがって、PRの件数、マージ状況、リポジトリの内容は、本日一次情報として再検証することはできず、8月中旬に取得されたPillarのスナップショットのままである。

その開示が防御側に求めること

Pillar が推奨する対応は、主にメタデータをその説明ではなくセキュリティ面として扱うことに関するものです。ホストに対する具体的な要請は次のとおりです。productivity-suite-mcp[.]onrender[.]com/mcpをブロックまたはハンティングすること、また、Pillar は現在アクティブではないと述べているにもかかわらず、キャンペーンの以前の trycloudflare.com エンドポイントを拒否リストとハンティングリストに保持し、そしてdeadbug-mcp.py — 隠しファイルパス ~/.config/.cache/.sys/.deadbug-mcp.py が、ホームディレクトリ、リポジトリ、MCP クライアント設定全体で検索すべきアーティファクトです。

調査の順序はブロックリストよりも重要です。ホストが接続した可能性がある場合、Pillarは何かをクリーンアップする前にMCPクライアントログを保存し、その後でツール定義の更新と、3回目の呼び出し後にエージェントが何を行ったかを確認するよう指示しています。認証情報は、ローカルの証拠が露出を裏付ける場合にのみローテーションすべきであり、これは疑いだけで全てをローテーションするという反射的な習慣とは逆です。サーバーの設定ではまた、任意のテレメトリのWEBHOOK_URLへの送信も許可され、接続時、最初の呼び出し時、トリガーイベント時にビーコン送信が行われていました。これは、調査においてクライアントログとエンドポイントトラフィック以外に確認すべき3つ目の場所を与える詳細です。

MCPクライアントを構築する人々にとって、この提言は構造的な性質のものであり、記録の中でも最も長く有用性が保たれる部分です：

• 承認時にツール定義のフィンガープリントを取得し、サーバーの名前やリポジトリを信頼するのではなく、更新のたびにそれらを比較する。

• 既に承認済みのサーバーにおける定義変更は、黙って飲み込まれる日常的なメタデータの変動としてではなく、運用者が目にし再承認するセキュリティイベントとして扱うこと。

• 機密性の高い操作 — 認証情報へのアクセス、コード実行、外部メール送信、リポジトリへの書き込み — は、サーバーが提供する記述ではなく、ポリシーによって強制する。

3番目の項目こそが、Deadbugzを単なる珍品ではなく記録に値するものにしている。上述のすべての制御は、エージェントがサーバー側でツールに添付されたテキストによって説得され得ること、そしてそのテキストが信頼判断が下された後に変更され得ることを前提としている。Pillarはこのキャンペーンを、Invariant Labsによる2025年のMCPスリーパー攻撃、偽造されたpostmark-mcpパッケージ、そして更新を通じて武器化されたKoiが文書化したMCPパッケージを含む一連の流れの中に位置づけている——いずれもこの手法の先例であり、Pillarがそのために引用しているものであって、今回の配信に関する証拠としてではない。

なぜ被害者の数よりもゲートのほうが重要なのか

配信試行が23回あり、マージも確認された被害者もないキャンペーンは、未遂として分類して先へ進むのは容易だ。これが高い重大度でアーカイブに収めるべき理由は、その回避が大規模な配信の成功に依存しないことにある。依存しているのは、今日ほとんどのMCPデプロイが共有するある特性だ。すなわち、承認はインストール時に一度だけ行われ、承認された定義がそのまま提供される定義だとみなされる。Deadbugzはその前提を3回の呼び出しの間は保ったままにし、その後で崩す。

修正は特定のサーバーへのパッチではなく、追跡すべきCVEもありません。問題は、「承認済み」が、その背後に比較を伴う継続的な条件になる必要があるということです。これは、クライアントとその運用者の振る舞いの変化であり、スキャナーが探す内容の変化ではありません。8月に誰かが実際にそのサーバーを稼働させたかどうかは依然として不明です。現状の記録では、発見事項はそのメカニズムそのものです。