出典：Jansos / Alamy Stock Photo
現在Web上で最も人気があり信頼されているモデル・コンテキスト・プロトコル（MCP）サーバーには、深刻なサイバーセキュリティ上の脆弱性が含まれている。
私たちの周囲で形成されつつあるAIのインターネットは、日を追うごとに巨大化し、扱いにくくなっている。ほんの数年前まで、AIアプリやサービスは限定され、用途も定められていた。ChatGPTと話すことは、賢い人と密室にいるようなものだった――そこで起きたことは、世界の他の部分には実質的に影響しなかった。
今日では自律エージェントがあらゆるサービスとしてのソフトウェア（SaaS）プラットフォームに入り込み、ユーザーが気づく範囲を超えてデータやサイバー攻撃を拡散させる、ほとんど監視されない行動を実行している。そして、MCPサーバーを使って大規模言語モデル（LLM）が外部データソースに接続できるようになったため、単純なチャットボットの会話でさえ、もはや単純ではなくなっている。
市場投入を急ぐあまり――そしてユーザーを過度に縛ることへの恐れから――MCPサーバーのような接続型AIソリューションは、不十分なガードレールのまま出荷されることが多かった。Anthropicが最初にMCPのオープン標準を作成した際、セキュリティはユーザー側に委ねられていた。そして1年以上が経った今、セキュリティ研究者によれば、最も信頼性が高いはずの有名ブランドのMCPサーバーでさえ、セキュリティホールだらけだという。
1月20日、Cyataが、Anthropic自身のGitおよびファイルシステムMCPサーバーを武器化し、リモートコード実行（RCE）を達成するエクスプロイトチェーンを公開した。一方、BlueRockが公開したのは、MicrosoftのMarkItDown MCPサーバーにおける深刻なサーバーサイド・リクエスト・フォージェリ（SSRF）脆弱性だ。さらに悪いことに、7,000以上のMCPサーバーを分析したところ、同じSSRFの露出が、現在Web上にあるMCPサーバー全体の約36.7%に潜在している可能性があることが分かった。
これらの発見は総じて、過度に従順で、危険なほど過小評価されてきた攻撃ベクトルの姿を浮き彫りにしている。
MCPサーバーはSSRFリスクを抱える
MicrosoftのMarkItDown MCPサーバーは、GitHubで85,000以上のスターと5,000のフォークを獲得していることからも分かるように、最も人気のあるものの一つだ。しかも極めて単純で、大規模言語モデル（LLM）の世界に向けた変換ツールにすぎない。さまざまなファイル形式を受け取り、LLM向けにMarkdownへ変換する。それの何が問題なのか？
まず、ユーザーは変換したいファイルがどこにあるかを指定する必要がある。そこでMarkItDownにURIを与えると、MarkItDownはそこにあるものを取得する。ところが、MarkItDownはこのユーザー入力をいかなる形でも制限していないことが分かった。「内部のファイルでもよいし、そのサーバーからネットワーク経由でアクセス可能な別のファイルでもよいし、[あるいは]実行したい任意の呼び出しの種類でもよいのです」と、BlueRockの最高製品責任者（CPO）であるHarold Byunは説明する。
これを発見したByunとチームは、サーバーサイド・リクエスト・フォージェリ（SSRF）の巨大な可能性に気づいた。例えば、従業員――あるいは従業員のマシンを制御する攻撃者――が、過剰な権限を持つMCPサーバーに情報を取得させるだけで、社内ネットワークで本来触れられないはずのリソースに到達し、権限の制約を逃れられるかもしれない。
BlueRockが特に関心を寄せたのは、MCPサーバーがクラウド、具体的にはAmazon Web Services（AWS）のEC2インスタンス上で動作するシナリオだ。EC2インスタンスには特定のIPに組み込みのメタデータサービスがあり、そこには（とりわけ）そのインスタンスにAWSのIdentity and Access Management（IAM）ロールが付与されている場合、一時的な認証情報が含まれる。ユーザーに公開されるべきものではないが、研究者はMarkItDownにそのIPを与えることで到達し、アクセスキー、シークレットキー、セッショントークンを取得できた。
AWSにはこの問題への回避策がある。新しいメタデータサービスであるInstance Metadata Service version 2（IMDSv2）は、BlueRockが悪用したIMDSv1よりもSSRF悪用に対して堅牢だ。それでも「現実には、Amazon上のインスタンスの大半はInstance Metadata Service v1のままだ」とByunは言う。
Microsoft側の見解として、同社の広報担当者はDark Readingに対し、「調査の結果、報告されたシナリオは当社顧客にとって重大なリスクを生じさせないことが分かりました。これは、ユーザーが意図された設計および通常の利用パターンの範囲外となる方法で、意図的にその機能を用いる必要があるためです」と述べた。
Byunはこれに同意しない。「人々は利用可能なソフトウェアを手に取り、[自分たちが適切だと思う形で]使うものです」と彼は言う。「私たちが見たかった推奨は、『はい、これはMCPの実装方法に潜在的なギャップを露呈します。開発者は呼び出しを境界付け、制約するためのベストプラクティスを用いるべきです』というものでした」
MCPの発明者がバグのあるMCPサーバーを作っていた
BlueRockがMicrosoftのMarkItDownに関する調査結果を公表した同日、Cyataの研究者は、Anthropicが保守する公式Git MCPサーバーにおける中程度の深刻度の脆弱性を3件開示した。
1つ目はCVE-2025-68145（CVSS 6.4）で、単純なパス検証の回避だ。管理者はMCPサーバーを特定のリポジトリパスに制限できる設定を持つが、このルールを強制する仕組みが実際には機能していなかった。
また、このサーバーはユーザーがファイルシステム上の任意の場所に新しいリポジトリを作成できるようになっており、任意のディレクトリをGitリポジトリに変えてしまえた。この問題にはCVE-2025-68143（CVSS 6.5）というラベルが付けられた。
最後の問題であるCVE-2025-68144（CVSS 6.3）は、ファイルのバージョン間の差分を表示するためのコマンド「git_diff」に関するものだった。git_diffは本来読み取り専用の性質を持つはずだが、研究者は、サーバーが到達できる任意のファイルを空にしたり上書きしたりするためにこれを利用する方法を突き止めた。
個別に見れば、これらの問題はいずれも比較的対処可能に見えるかもしれない。Cyataにとって重要だったのは、最初の2つをファイルシステムMCPサーバーと組み合わせて連鎖させ、強力なRCEエクスプロイトを作り出したことだ。
例えば攻撃者が、ユーザーのAIアシスタントが読み取る場所に何らかの悪意あるコンテンツ――不穏なREADMEや改ざんされたWebページ――を仕込むとする。間接プロンプトインジェクション（IPI）を通じて、そのファイルはAIに対し、Git MCPの脆弱性を悪用するよう密かに指示する。まず、被害者マシン上の通常のディレクトリをGitリポジトリに変える。次に、Filesystem MCPの正当なファイル書き込み機能を使い、AIに「.gitattributes」ファイルを書き込ませ、リポジトリのデフォルト設定ファイルを上書きさせる。これにより、Gitが新しい.txtファイルをステージングする際に、攻撃者が定義したシェルコマンドを自動実行するフィルターが実質的に作られる。最後にAIが悪意あるペイロードと、リポジトリに投入されるとペイロードの実行を引き起こす通常のテキストファイルを書き込む。結果は、任意コード実行である。
「単体では、各MCPサーバーは比較的安全でした」とCyataのCEO兼共同創業者であるShahar Talは言う。「しかし組み合わせると、Git MCPサーバーとFilesystem MCPサーバーの相互作用が、私たちの前提を崩しました。これは本当に興味深い。過度に接続されたAIエージェントと、より多くのMCPサーバーは有害な組み合わせで、エージェントを破綻させるのです」
同社は昨年6月に調査結果をAnthropicへ報告した。半年後の12月、AnthropicはGit MCPサーバーの2025.12.18版をリリースし、パス検証の強制を改善し（CVE-2025-68145への対応）、引数処理に対処し（CVE-2025-68144）、git_initツールを完全に削除した（CVE-2025-68143）。
あまりにも明白な皮肉を指摘しつつ、Talはこう語る。「Anthropicが――『良い』とは何かを示す公式MCPリファレンス実装で――間違えるのなら、誰もが[MCPのセキュリティ]を間違え得る。今の私たちは、まさにそこにいるのです」
Dark ReadingはAnthropicにコメントを求めたが、記事掲載時点で同社からの回答はなかった。
翻訳元: https://www.darkreading.com/application-security/microsoft-anthropic-mcp-servers-risk-takeovers
