MCPサーバーには、エージェントが渡してきたURLを取りに行く作りのものが多い。そのURLの行き先を確かめないという同じ欠陥が、大手クラウド、銀行、2つの国の政府のサーバーで別々に見つかったと報じられている。The Next Web、Unite.ai、TechTimesによれば、Google、JPMorgan Chase、フランス政府はそれぞれ修正を済ませた。一方で、米連邦政府の5つのMCPサーバーは、報告から約5週間たっても直っていないという。退役軍人の社会保障番号（SSN）が入ったエラー応答を、伏せないまま記録していた例もあると伝えられる。
この記事は報道をもとにしており、各組織の告知や研究者の報告そのものは確認できていない。それを前提に読むと、報道の構図からは1つのことが見えてくる。MCPのセキュリティを決めているのはプロトコルの仕様ではなく、個々のサーバーを作る人の実装の質だということである。
欠陥の中身：行き先を確かめずにURLを取りに行く
報じられている欠陥は、典型的なSSRF（サーバー側リクエストフォージェリ）である。MCPサーバーはエージェントからURLを受け取り、自分の側からそのURLにアクセスする。このとき行き先が内部のネットワークか、クラウドのメタデータのエンドポイントか、許された外部のサイトかを確かめていなかった。エージェントを踏み台にすると、サーバーが置かれた内側のネットワークに要求を届けられてしまう。The Next Web はこの手口を、プロトコルを経由して内側へ渡っていく「ピボット」として扱っている。
見つけにくいのは、どこにも壊れた部品がないからである。Rapid7 で脆弱性インテリジェンスを率いる Douglas McKee は、次のように述べたと伝えられる。
Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch
訳: 連鎖のどの部品も設計どおりに動いている。だからこそ見つけにくい
エージェントは指示どおりにURLを渡し、サーバーは仕様どおりにそれを取りに行き、ネットワークは届いた要求に答える。部品ごとに見れば、どれも正しく動いている。問題は、部品をつないだときに、行き先を確かめる役目をどこも引き受けていなかったことである。
同じ間違いを、3つの組織が別々に直した
報道によれば、ある1人の研究者が同じ型の欠陥を組織ごとに報告していった。Google、JPMorgan Chase、フランス政府（The Next Web の記事は、政府のデジタル部門 DINUM の名を挙げている）は、報告を受けてそれぞれ直したとされる。業種も規模も違う3つの組織が、同じ間違いを独自に作り込み、独自に直したことになる。
欠陥を報告した、Cognivators の創業者でセキュリティ研究者の Syed Anas Mohiuddin は、こう書いたと伝えられる。
Watching the same mistake come back from a hyperscaler, a bank, and a national government, one report at a time, is the moment the May argument stopped being a guess
訳: 大手クラウド、銀行、国の政府から、同じ間違いが報告のたびに一つずつ返ってくるのを見て、5月に立てた主張はもう推測ではなくなった
Mohiuddin は5月に、MCPの危うさは仕様より実装の側にあると論じていた。その主張を、実際の報告の積み重ねが裏付けた形になる。1つの組織のうっかりではなく、MCPサーバーを書く人が繰り返しはまる型だということである。共通の部品の欠陥なら、上流が1か所直せば済む。今回は、作り手がそれぞれ自分の手で直すしかなかった。
米連邦の5サーバーは約5週間未修正、SSNも伏せずに記録
対照的なのが、米連邦政府である。報道によれば、連邦の5つのMCPサーバーは、報告から約5週間たっても修正されていない。TechTimes は見出しで、Google と JPMorgan が直してから6週間たっても米国のサーバーはさらされたままだと書いている。どの機関のサーバーなのかは、確認できた範囲では特定できていない。
見出しにあるもう1つの問題が、ログである。退役軍人のSSNを含むエラー応答が、伏せられないまま記録されていたと報じられている。SSRFは、内側のネットワークに要求を届けられてしまうという入り口の問題である。それに加えて、エラー応答に個人情報がそのまま載り、それがそのままログに残っていた。エラーとログの扱いという出口の側でも、実装の手当てが抜けていたことになる。
同じ欠陥でも、民間の2社と仏政府は直し、米連邦の5サーバーは直していない。プロトコルは同じだから、この差は仕様からは生まれない。生んだのは、サーバーを作って運用する側の体制である。報告を受けて動けたかどうかが、そのまま安全の差になった。
仕様は守ってくれない、守るのは実装
MCPの安全をめぐる最近の既報も、同じ方向を指している。10月3日に報じた公式の Python SDK の OAuth の欠陥は、SDK の更新で直った。ただし、利用者の操作を介さない認証方式では、更新したあとも利用者が自分で設定を足す必要があった。10月4日に報じた MCP Events の下書きの仕様には、購読の権限を確かめ直す決まりがなかった。仕様も SDK も、最後の安全の確認を実装の側に預けている。今回のSSRFは、その預けられた確認を各組織がしなかった場合に何が起きるかを、4つの組織の実例で示したことになる。
MCPサーバーを作る側には、少なくとも次の手当てが要る。受け取ったURLの行き先を許可リストで絞ること。内部のアドレスやメタデータのエンドポイントを拒むこと。リダイレクトのあとの行き先も確かめ直すこと。エラー応答とログから個人情報を取り除くこと。いずれも新しい技術ではなく、昔からあるウェブのセキュリティの基本である。エージェントの出力を信用せず、その手前の層で縛るというハーネスエンジニアリングの考え方を、ツールの側にも当てはめる話でもある。
確かめられていない点も多い。連邦のどの機関のサーバーか、修正の予定はあるか、記録されたSSNが誰かの手に渡ったか。報道は、これらに答えていない。各組織や研究者が一次情報を出すまでは、ここまでの内容は報道ベースの話として扱う必要がある。
