MCPサーバーを7000台調査したら、36.7%が同じSSRFの穴を持っていた

Posted at 2026-07-04

はじめに

Microsoft製のドキュメント変換ツール「MarkItDown」（GitHub★15万超¹・MCPサーバーとしても提供）に、SSRF（Server-Side Request Forgery）につながる脆弱性が報告されました。セキュリティ企業BlueRockの調査によると、この種の欠陥はMarkItDown固有ではなく、公開されている7,000台以上のMCPサーバーのうち36.7%が同様の穴を持つ ことが分かっています。

この記事で分かること:

MarkItDown MCPサーバーで発見された「MCP fURI」脆弱性の仕組み
URIを1つ渡すだけでAWSの認証情報まで抜ける攻撃チェーン
自作・自運用のMCPサーバーで同じ穴がないかを確認し、塞ぐ具体的な方法

対象読者は、MCPサーバーを自作している、あるいはMarkItDownのような既存MCPサーバーをEC2やクラウド環境にデプロイして使っている開発者です。

TL;DR

MarkItDownのMCPツール convert_to_markdown は、渡されたURIの範囲を一切制限していない。HTTPでもファイルパスでも、任意の宛先に変換リクエストを飛ばせてしまう
EC2上で動かしている場合、このURI引数にインスタンスメタデータサービス（IMDS）のアドレスを渡すと、IAMロールのアクセスキー・シークレットキー・セッショントークンがそのまま返ってくる
BlueRockが公開MCPサーバー7,000台以上を分析した結果、36.7%が同種のSSRF脆弱性を抱えている ことが判明した
対策は「URIの許可リスト化」と「IMDSv2の強制」の2段構え。特にIMDSv2はEC2側の設定だけで有効化でき、SSRF一般への防御効果が大きい

脆弱性の中身（MCP fURI）

BlueRockが「MCP fURI」と名付けたこの脆弱性は、MarkItDownのMCPツール convert_to_markdown に起因します。このツールはURIを受け取ってMarkdownに変換するだけのシンプルな機能ですが、渡されたURIがHTTP/HTTPSなのかローカルファイルなのか、宛先がどこであるかを一切検証していません。

つまり、次のような呼び出しがそのまま通ってしまいます。

convert_to_markdown(uri="http://169.254.169.254/latest/meta-data/iam/security-credentials/")

169.254.169.254 はAWSのインスタンスメタデータサービス（IMDS）の予約IPアドレスです。EC2インスタンス上で動くプロセスなら誰でも到達できる内部エンドポイントで、通常は同一インスタンス内のソフトウェアがIAMロールの一時認証情報を取得するために使います。MarkItDownはこのURIも「変換対象の1つ」として素直にHTTPリクエストを投げてしまうため、レスポンス（IAMロールに紐づくアクセスキー・シークレットキー・セッショントークン）がMarkdownとしてそのままエージェント側に返ってきます。

攻撃者から見た手順は次の3段階です。

MCPクライアント（AIエージェント）経由、あるいは直接ツール呼び出しで convert_to_markdown にIMDSのURIを渡す
レスポンスからIAMロールの一時クレデンシャルを取得する
取得したクレデンシャルをAWS CLI等に設定し、そのロールが持つ権限の範囲でAWSリソースにアクセスする

このロールに広い権限（S3フルアクセスやEC2管理権限など）が割り当てられていた場合、被害はMCPサーバー1台の侵害にとどまらず、AWSアカウント全体の乗っ取りにまで拡大しえます。

「MarkItDownだけの問題」ではない

この脆弱性が興味深いのは、根本原因が「URIの範囲を検証しない」という、MCPサーバー実装によくあるパターンだという点です。BlueRockは公開されている7,000台以上のMCPサーバーを横断的に分析し、36.7%が同種のSSRF脆弱性の可能性を抱えている と報告しています。

MarkItDown自体はMicrosoftが公開しているOSSで、GitHub上で★15万超を集める人気ツールです。人気があり広く使われているツールほど、同じ設計の穴が多くの環境に配布されていることになります。BlueRockはこの問題をMicrosoftとAWSの双方に報告していますが、Microsoft側は「重大なリスクには当たらない」との立場を取っており、本稿執筆時点でMarkItDown自体へのパッチは提供されていません。つまり、利用者側での対策が現実的な防御ラインになります。

対策1: MCPサーバー側でURIを許可リスト化する

自作MCPサーバーで外部URIを受け取るツールを実装している場合、まず疑うべきはURIの検証漏れです。最低限、以下のような防御を入れます。

import ipaddress
from urllib.parse import urlparse

# メタデータサービス・ループバック・プライベートレンジへのアクセスを拒否する
BLOCKED_NETWORKS = [
    ipaddress.ip_network("169.254.169.254/32"),  # AWS/GCP/Azure IMDS
    ipaddress.ip_network("127.0.0.0/8"),          # ループバック
    ipaddress.ip_network("10.0.0.0/8"),           # プライベート
    ipaddress.ip_network("172.16.0.0/12"),        # プライベート
    ipaddress.ip_network("192.168.0.0/16"),       # プライベート
]

def is_safe_uri(uri: str) -> bool:
    parsed = urlparse(uri)
    if parsed.scheme not in ("http", "https"):
        return False  # file:// 等の非HTTPスキームも拒否
    hostname = parsed.hostname
    if not hostname:
        return False  # ホスト名を解析できないURIは拒否
    try:
        addr = ipaddress.ip_address(hostname)
    except ValueError:
        return True  # ホスト名解決前提のドメインは別途DNS解決後に再チェックする
    return not any(addr in net for net in BLOCKED_NETWORKS)

ポイントは、ホスト名の文字列だけを見て判定しないことです。DNSリバインディング（許可判定後に名前解決先を変える攻撃）を防ぐには、実際に接続する直前のIPアドレスで再検証するか、socket レベルで到達先を固定する必要があります。

対策2: IMDSv2を必須化する（EC2側だけで完結する防御）

MCPサーバー自体の実装を直せない場合や、サードパーティ製のMCPサーバーを使っている場合は、EC2インスタンス側でIMDSv2を必須化するのが最も手早い防御です。

IMDSv1はGETリクエストだけで認証情報を取得できてしまいますが、IMDSv2は事前に PUT リクエストでセッショントークンを取得し、そのトークンをヘッダーに付けた場合のみメタデータへのアクセスを許可します。多くのSSRF脆弱性は任意ヘッダー付きのリクエストを送れない（GETしか投げられない）ため、この一手間だけでほとんどのSSRF経由のクレデンシャル窃取を防げます。

既存のEC2インスタンスに対して、稼働中のまま以下のコマンドで切り替えられます。

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

--http-tokens required がIMDSv2の必須化に相当する設定です。新規に起動するインスタンスであれば、起動テンプレート・Launch Configurationの MetadataOptions.HttpTokens を required にしておけば同様の防御がデフォルトで効きます。

著者視点の発見ポイント

本稿を書くにあたり筆者が着目したのは、この脆弱性が「MarkItDownのバグ」というより「MCPというプロトコルの設計思想そのものに内在するリスク」だという点です。MCPツールの多くは「渡された文字列をそのまま処理する」ことが本来の機能であり、URIやファイルパスを受け取るツールは原理的にすべてSSRF・パストラバーサルの潜在的な入口になります。36.7%という数字は、個別実装のミスというより、MCPエコシステム全体が「入力検証はツール開発者任せ」という前提で急速に広がったことの裏返しだと感じました。自作MCPサーバーを書く際は、Webアプリケーションのセキュリティレビューで当たり前だったSSRF対策の知見を、そのままMCPツールにも持ち込む必要があります。

まとめ

MicrosoftのMarkItDown MCPサーバーは、URI検証の欠如によりSSRF攻撃が可能で、EC2環境ではAWS認証情報の窃取につながる（MCP fURI）
BlueRockの調査では公開MCPサーバー7,000台超のうち36.7%が同種の脆弱性を抱える
Microsoftは重大なリスクと認めておらずパッチは未提供。利用者側の対策が現実的な防御ライン
対策は「URIの許可リスト化（プライベートレンジ・メタデータIPの拒否）」と「IMDSv2の必須化」の組み合わせ

参考リンク

Microsoft's MarkItDown Passes 150,000 GitHub Stars（pbxscience.com）（2026年時点） ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up