エージェントスタックが抱える1998年問題

2026年6月の最終週、AIエージェントツールを狙ったCVEが小さくまとまって公表されました。うち2件は同じデスクトップエージェントクライアントに存在するもので、どちらも認可の不備、そのうちの1件はMCPのOAuthコールバックのまさに内部に潜んでいました。個別に見れば、それぞれは保守担当者が週末で修正できる中程度の深刻度のバグにすぎません。しかしまとめて読むと、この一群はひとつのシグナルとなり、そのシグナルは構造的なものです。すなわち、AIエージェントのエコシステムは、それを守るセキュリティ文化を蓄積するよりも速く、攻撃対象領域を蓄積しているのです。これは特定のプロジェクトの倫理的な落ち度ではありません。安全でないデフォルト設定のまま言語が主流となり、認証情報がそこかしこに置かれ、導入台数が誰にも堅牢化しきれない速さで増えていった、1998年頃のウェブがまさに置かれていた状況そのものなのです。あなたの鍵を預かり、あなたのシェルを走らせるツールが、2026年の脅威モデルに対して1998年のセキュリティ成熟度のまま出荷されている——それが現状です。 {.answer-block}

TL;DR

• 人気のデスクトップAIエージェントクライアントであるCherry Studioは、2026年6月29日に2件のCVEを受けました。1件はMCPのOAuthコールバックサーバーにおける不適切な認可の不備（CVE-2026-13524）、もう1件はプリロードAPIにおける認可バイパス（CVE-2026-13534）です。¹²
• このパターンは1つのアプリに限った話ではありません。MCPのリファレンス実装ツール自体が、2025年に深刻なリモートコード実行の脆弱性を出荷していました。CVSS 9.6のmcp-remote（CVE-2025-6514）と、CVSS 9.4のAnthropicのMCP Inspector（CVE-2025-49596）です。³⁴
• エージェントツールは、かつてのどんなウェブアプリよりも構造的に無防備です。認証情報を保持し、設計上コードを実行し、しかもあなたの信頼境界（IDE、シェル、ブラウザ）の背後ではなく、その内側に居座っているからです。
• これらのバグを防ぐための知識はすでに存在します。MCPの仕様書は、混乱した代理人（confused deputy）やOAuthフローに対する攻撃の類型を詳しく記述しています。しかし、それを高速に進化するあらゆる統合機能に適用する文化は、まだ行き渡っていません。⁵
• 1998年のウェブが成熟したのは、ワームによって無防備さが高くつくようになってからのことでした。エージェントのエコシステムには、まだそれに相当する強制力が存在しません。そして、いま現在これらのバグを見つけているのと同じモデルが、その強制力となるワームを書くこともできるのです。

この一群を具体的に

Cherry Studioは、「スマートチャット、自律エージェント、300以上のアシスタントを備えたAI生産性スタジオ」を謳うクロスプラットフォームのデスクトップクライアントで、Model Context Protocolサーバーを明示的にサポートしています。まさに本稿が扱う類のツールです。すなわち、あなたのAPIキーを仲介し、ローカルの統合機能を動かし、あなたの代わりにネットワークへ手を伸ばす、消費者向けのエージェントなのです。

2026年6月29日、VulDBはこれに対して2件のアドバイザリを公開しました。CVE-2026-13524は、MCPのOAuthローカルコールバックサーバー、ファイル src/main/services/mcp/oauth/callback.ts におけるバージョン1.9.0から1.9.6までの不適切な認可の不備（CWE-285）です。記述は明快です。「引数 code の操作が不適切な認可につながる」。CVSS 3.1で5.6、中程度と評価されています。¹ CVE-2026-13534は、CherryINのプリロードAPIにおけるバージョン1.9.7までの認可バイパス（CWE-639）で、評価値は5.0です。² どちらも大見出しになるような話ではありません。いずれも、誰にとっても新しい領域を高速に進むなかでチームがおかす、静かな認可のミスなのです。

1件目が示唆に富んでいます。MCPクライアントにおけるOAuthコールバックは、教科書どおりの信頼境界です。外部の認可サーバーがコードをあなたのマシンへ返し、そのコードを信頼するかどうかをマシン側が判断する、その地点です。これを扱い損ねることは、風変わりな新種のバグではありません。MCPの仕様書に付属するセキュリティ文書が、最も多くの筆を割いているバグそのものなのです。

同じ時期に公表された近接する2件のCVEは、あえて外しました。この一群は本物でなければならないからです。CVE-2026-13533はエージェントフレームワークではなくPHPのコンテンツ管理ツールであるagentejo Cockpit CMSのもので、CVE-2026-13543はそもそも検証できませんでした。確かな例が数件あるほうが、水増しした一覧よりも優れています。

エージェントツールが構造的に不利な理由

1998年頃の典型的なウェブアプリは安全ではありませんでしたが、それでも境界の背後で生きていました。あなたが内側に座っているわけではないサーバー上で動き、被害範囲はデータベースとセッションにとどまり、侵害されても攻撃者が手にするのはそのアプリのデータでした。

エージェントツールは、その配置を逆転させます。あなたのマシン上、あるいはIDEの内側で動き、クラウドやリポジトリへの長期間有効な認証情報を保持し、しかもコードの実行を——攻撃の手口としてではなく——中核機能として行います。背後に控えるべき境界などありません。ツールそのものが境界であり、しかもその境界は設計からして穴だらけなのです。

Simon Willisonは2025年6月、この危険を「致命的な三要素（lethal trifecta）」という言葉で正確に言い当てました。エージェントは、「あなたのプライベートなデータへのアクセス」「信頼できないコンテンツへの露出」「外部と通信する能力」の3つを、そのデータを盗み出しうる形で兼ね備えたときに、悪用可能になるというのです。⁷ 有能なエージェントはいずれも、デフォルトでこの3つをすべて備えています。あなたの秘密を読み、攻撃者の影響を受けたコンテンツを取り込み、外向きのリクエストを送ることは、そのバグではなく機能だからです。この三要素は例外的なケースではありません。標準の構成なのです。

これが構造的な違いです。1998年のウェブアプリは、境界1つ分のデータを漏らすようにだまさなければなりませんでした。2026年のエージェントは、データ持ち出しの連鎖に必要なあらゆる能力をあらかじめ配線した状態で届きます。悪意ある入力とあなたの認証情報とのあいだに立ちはだかるのは、ツールが内部の信頼境界を正しく引けていたかどうか、その一点だけです。Cherry Studioのコールバックのバグは、そうした境界の1つがほんの少し誤って引かれたとき、どう見えるかを示すものなのです。

MCPによる増幅

Model Context Protocolは、2026年のエージェントスタックをつなぐ結合組織であり、ある特有のかたちで攻撃対象領域を増幅します。すなわち、あらゆるMCPサーバーは、たいてい手早く書かれた、モデルが呼び出せる新たな特権的統合機能なのです。1つ追加するのは摩擦なくできます。1つ監査するのはそうではありません。統合機能の導入数は、そのコードを読む人々の数を追い越しつつあります。

リファレンス実装ツールを見れば、これが趣味のプロジェクトに限った問題でないことがわかります。2025年7月、JFrogはCVE-2025-6514を公表しました。Claude Desktop、Cursor、Windsurfが使うコネクタであるmcp-remoteのOSコマンドインジェクションで、悪意あるサーバーがOAuthフローの最中に細工した authorization_endpoint のURLで発動させるもの——深刻、CVSS 9.6です。³ 同じ月、TenableはCVE-2025-49596を公表しました。Anthropic自身のMCP Inspectorにおける9.4のリモートコード実行の脆弱性で、認証チェックの欠落により、悪意あるウェブサイトがローカルポートに到達し、DNSリバインディングを介して任意のコマンドを実行できてしまうものでした。⁴

本稿で扱う4件のCVEのうち2件は、MCPツールにおけるOAuthフローの脆弱性です。1件はコールバックサーバー、もう1件はエンドポイント探索でのものです。これは偶然ではありません。エージェントクライアントにおけるOAuthは、繰り返し扱いを誤られてきた境界であり、仕様書はそのことをはっきりと述べています。2025年6月18日付のMCPのセキュリティベストプラクティス文書は、最も長い節を「混乱した代理人問題（confused deputy problem）」に割き、プロキシサーバーがクライアントごとの同意を実装し、OAuthの state パラメータを検証し、リダイレクトURIを厳密に一致させることを義務づけています。⁵ これはCherry Studioがコールバックのバグを出荷する1年前に公開されていました。足りないのは知識ではありません。仕様書のセキュリティ付録と、先週の火曜日に書かれた平均的な統合機能とのあいだにある隔たりなのです。

プロンプトインジェクションは、この増幅を、かつてのウェブが直面したどんなものよりも質的に悪化させます。Willisonは2022年9月にこの用語を作り、「これに対する明白な名前はプロンプトインジェクションであるべきだと提案する」と書きました。SQLインジェクションになぞらえたもので、信頼された命令と信頼できない入力とが1つの文字列に連結され、それをエンジンが解釈してしまうというのです。⁶ エージェントにとって、データはコードだけでなく攻撃経路そのものです。汚染されたウェブページ、罠を仕込まれたファイル、敵対的なツールの説明文——モデルが読むどのバイトも命令を運びうるのです。MCPの仕様書はこの点を率直に述べ、悪意あるサーバーがクライアントをデータ持ち出しの中継役に変えうると警告しています。⁵ これは入力のエスケープ処理では修正できません。入力が自然言語であり、解釈するのがモデルだからです。

1998年の類推を、正確に

この類推は、事実確認に耐えなければただの雰囲気にすぎません。ですから、その時代を正確に振り返ってみましょう。

PHP 3は1998年6月に出荷され、いまや無謀としか読めないデフォルト設定とともに、動的なウェブ言語を数百万人の手に委ねました。クエリ文字列、クッキー、あるいはサーバー由来の外部入力が、そのままグローバルスコープに登録されていたのです。register_globals は有効で、攻撃者が操る変数が、いつのまにかコードが信頼する変数になりえました。修正には4年かかりました。2002年4月にリリースされたPHP 4.2.0がデフォルトを変更し、リリース告知はそれを端的に述べています。「外部変数（環境、HTTPリクエスト、クッキー、ウェブサーバー由来のもの）は、デフォルトではグローバルスコープに登録されなくなりました」。⁸ もう1つの、時代を象徴する松葉杖だったmagic quotesは、addslashes を走らせてSQLインジェクション対策を実体のないまま装い、register_globalsより何年も長く生き延びたのち、プロジェクトがようやくとどめを刺しました。安全でないデフォルト、安全という幻想、そして文化が追いつくまでの数年の遅れ。それが若きウェブのアプリ層でした。

その文化はひとりでにやって来たのではありません。強いられて生まれたのです。2001年7月19日、Code RedワームはMicrosoftのIISウェブサーバーのバッファオーバーフローを突き、CAIDAの集計によれば「14時間足らずで35万9000台を超えるコンピュータがCode-Red（CRv2）ワームに感染しました」。⁹ 2003年1月25日には、Sapphire／SlammerワームがMicrosoft SQL Serverのバッファオーバーフローを突き、自らを376バイトのパケットに収め、「10分以内に見つけられる脆弱なホストのほとんどに感染」しました。それは当時までで史上最速の拡散を見せたワームでした。¹⁰ これらはPHPのバグではなくインフラを狙ったワームであり、両者を混同するつもりはありません。要点はこの10年の形です。あらゆる層にわたる安全でないデフォルトと、無防備さが生々しく、公然と高くつくものになって初めて成熟したセキュリティ文化。デフォルトで安全（secure-by-default）とは、業界がワームという代償を払って学んだ教訓だったのです。

これを2026年に重ねると、その対応関係は居心地の悪いものです。安全でないデフォルト——コールバックのコードを信頼し、同意チェックを飛ばすエージェントクライアント。安全という幻想——admin:* のスコープを持つトークンにかぶせた、たった1つの許可ダイアログ。爆発的に増える導入数——ワンクリックで追加され、誰にも監査されない、あらゆる用途向けのMCPサーバー。このエコシステムにまだ存在しないのは、ワームです。1998年のデフォルトと2001年の標的像はすでに揃っており、あとはその強制力を待っている状態なのです。

運用者としての構え

文化を待っている余裕はありません。あなたはいま、これらのツールを使っています。だからこそ、エコシステムがまだ引いてくれていない境界を、自分で引くのです。私が用いる枠組みは、あの三要素を運用上のチェックリストとして使うことです。どんなエージェントについても、何を読めるのか、何を実行できるのか、何を持ち出せるのかを問い、それぞれに決定論的なガードを置くのです。

ガードの列は、努力目標ではありません。決定論的であり、その決定論こそが肝心なのです。フックは、モデルが反論できない終了コードとともにライフサイクルのイベントで発火し、許可ルールはツールが動いた後ではなく、動く前に評価されます。「エージェントはXをすべきでない」が「エージェントはXができない」に変わるのが、この層です。そして、プロンプトインジェクションのペイロードが言い抜けできない唯一の層でもあります。入力を信頼できず、しかもその入力についてモデルが自らを取り締まると信頼することもできないなら、モデルが制御しない境界で強制するのです。

2つ目の制御は、生産性のための機能のように読めますが、実際にはセキュリティのための機能です。エージェントが実行前に自らの作業をレビュー可能な計画へとまとめ上げるとき、その計画をレビューすることは、セキュリティレビューにほかなりません。呼び出すすべてのツールと触れるすべてのファイルを名指しした40行のワークフロースクリプトは、1分で読める脅威モデルです。1万件のライブな判断を監査することはできません。しかし、それらを生み出すことになる計画なら、何かを費やす前に監査できるのです。

そして、この非対称性を忘れないでください。これらのCVEを生み出すのと同じ能力が、それらを見つけもするのです。あるAnthropicの研究者は、コーディングエージェントと10行のスクリプトを使って、23年前のLinuxカーネルの脆弱性と22件のFirefoxのCVEを浮かび上がらせました。あなたの机の上のツールは、向ければ、自分自身のスタックに向けた脆弱性スキャナーになります。防御側は、いまや発見を自動化でき、そして現在、その振り分けの層を築きつつあります。それこそ、1998年のウェブが持っていなかった唯一の利点なのです。

私の立場

以下が、私の考える展開です。間違いうるくらいには具体的に述べます。エージェントのエコシステムは、セキュリティ文化を手にする前に、自らのCode Redの瞬間を迎えます。ウェブがそういう順序でたどったからです。その強制力となるのは、共有されたMCPサーバーを介してエージェント間を渡り歩く、自己増殖するプロンプトインジェクションのペイロードか、あるいは1つの人気があり監査の甘い統合機能にたどり着く、大規模な認証情報持ち出しの事件である可能性が最も高いでしょう。それは安上がりに作れます。カーネルのバグを見つけるのと同じモデルがそれを書けるからです。そして「大きな波が来る」という警告は、はじめから防御だけの話ではありませんでした。

それが現実になったあと、デフォルトで安全であることは、もはや選択肢ではなくなります。MCPクライアントは、PHPが最終的に register_globals を無効にして出荷したのと同じように、同意ダイアログをデフォルトで有効にし、トークンの想定利用先（audience）を検証し、一致しないリダイレクトURIを拒むコールバックを備えて出荷されるようになります。許可の層は、オプトインからデフォルト拒否（default-deny）へと移ります。生き残る統合機能は、仕様書のセキュリティ付録を仕様そのものとして扱ったものなのです。

居心地が悪いのは、その時間軸です。ウェブがデフォルトで安全であることを血肉にするには、おおよそ1998年から2005年までを要し、ワームとワームのあいだには考える猶予が何年もありました。エージェントスタックはもっと速く積み重なります。あらゆる開発者のマシン上により価値の高い標的があり、攻撃者のツールチェーンはモデルの世代ごとに改善されるからです。1998年問題は現実です。残された唯一の問いは、ワームが結末を書いてしまう前にこの類推に基づいて動くのか、それとも書かれたあとになるのか、それだけなのです。

重要なポイント

• すべてのエージェントで三要素の監査を実施しましょう。 各ツールが何を読み取り、実行し、持ち出せるのかを書き出し、それぞれの行に決定論的なガードがあることを確認します。ガードのない能力は、あなたの無防備な箇所であり、次のペイロードが着地する場所です。
• MCPサーバーを許可リスト化し、あらゆるコマンドのパラメータを信頼できない実行として扱いましょう。 統合機能の追加はワンクリックでも、その監査はそうではありません。だからこそ、登録をレビュー済みの一覧に通す関門を設けます。本稿の4件のCVEのうち2件は、MCPクライアントにおけるOAuthフローのバグでした。ハンドシェイクは形式手続きではなく、境界なのです。
• 計画の段階を、レビューの関門にしましょう。 エージェントに意図をレビュー可能な計画へまとめさせ、実行前にそれを脅威モデルのように読みます。ツールとファイルを名指しするスクリプトは1分で監査できますが、1万件のライブなツール呼び出しはそうではありません。
• まずスキャナーを自分自身に向けましょう。 これらのCVEを生み出す能力は、それらを見つけもします。誰かがあなたに対して仕掛ける前に、自分のコードと依存関係に対して、エージェントを使ったセキュリティの一斉点検を走らせるのです。

よくある質問

MCPサーバーは安全ですか？

デフォルトでは安全ではなく、一様でもありません。MCPはプロトコルであり、その安全性は各サーバーとクライアントの実装しだいです。mcp-remote（CVSS 9.6）とAnthropicのMCP Inspector（CVSS 9.4）に対する2025年の公表は、リファレンス実装ツールでさえ深刻なRCEの脆弱性を出荷したことを示しています。³⁴ 仕様書は、混乱した代理人、トークンの素通し、SSRF、ローカルサーバーの侵害といった主要な攻撃の類型を記述し、具体的な緩和策を規定しています。⁵ 各サーバーは特権的な統合機能として扱ってください。信頼できるもの、あるいは監査したものだけを動かし、明示的に許可リスト化し、接続するどのサーバーも自分のエージェントに影響を及ぼしうると想定するのです。

プロンプトインジェクションとは何ですか？

プロンプトインジェクションとは、AIシステムが読み取る信頼できない入力に攻撃者が命令を紛れ込ませ、モデルがそれをあなたからの指示であるかのように従ってしまうことです。Simon Willisonは2022年9月、SQLインジェクションになぞらえてこの用語を作りました。信頼された命令と信頼できない入力とが1つのプロンプトに連結され、それをモデルが解釈してしまう——しかもどの部分が攻撃者のものだったのかを確実に見分ける手立てはない、というのです。⁶ エージェントにとっては、データが攻撃経路になるため、とりわけ危険です。しかも解釈するのが言語モデルである以上、エスケープ処理では修正できません。

致命的な三要素とは何ですか？

Simon Willisonが2025年6月に名づけた呼び名で、組み合わさるとエージェントを悪用可能にする3つの能力を指します。すなわち、あなたのプライベートなデータへのアクセス、信頼できないコンテンツへの露出、そして外部と通信する能力です。⁷ この3つをすべて備えたエージェントは、注入されたコンテンツによって、あなたの秘密を読み出して攻撃者へ送り出すよう操られかねません。有能なエージェントのほとんどが、デフォルトでこの3つを備えています。だからこそ、モデルが抵抗してくれることを願うのではなく、それぞれの能力にガードをかけるのが正しい打ち手なのです。

自分のマシンで動くエージェントは、どう守ればよいですか？

モデルが制御しない境界から始めましょう。ツールが動く前に評価される許可ルールとフックを使えば、汚染されたプロンプトが、あなたが禁じた操作へと言い抜けて入り込むことはできません。ツールとMCPサーバーを許可リスト化し、新しいローカルサーバーが実行される前に同意を求め、あらゆる認証情報を最小権限に絞って、盗まれたトークンの被害範囲を小さくします。プライベートおよびリンクローカルのIP範囲への外向きリクエストを遮断し、持ち出しの経路をふさぎます。そのうえで、大きな操作の前にはエージェントの計画をレビューします。そこで、読み取りの境界を生き延びた注入が捕まるのです。

出典