あなたのAIアシスタントが、今夜こっそり会社のAWSにログインしていたとしたら。これは脅かしではなく、現時点で現実に起きうる攻撃経路の話だ。
MCPとは何か——AIに「手」を増やすプラグイン規格
Claude CodeやCursorといったAIコーディングツールは、チャットやコード補完だけでなく、外部ツールとも連携できる。ファイルシステムを読み、データベースに接続し、Webブラウザを操作する。この連携を可能にするのがMCP（Model Context Protocol）だ。Anthropicが2024年11月に策定した標準規格で、AIと外部ツールをつなぐUSBのような仕組みだ。
AIにUSBハブを渡したようなもの、と理解してもらえばいい。接続できるものが一気に増えたが、差し込み口に何でも繋げてしまう。そして現状、その「差し込み口」の多くに施錠がされていない。
セキュリティ企業BlueRockが7,000以上のMCPサーバーを分析した結果、36.7%がSSRF脆弱性を持つことが判明した。エレベーターの3台に1台が、ドアが完全に閉まらないまま動いているような数字だ。
Microsoft MarkItDownで何が起きたか——SSRFの攻撃経路を追う
SSRFとは「Server-Side Request Forgery（サーバー側リクエスト偽造）」の略だ。難しく聞こえるが、平たく言えばこういうことだ。
社員に「この電話番号に電話してメモを取ってきて」と頼んだら、社内の内線番号に電話して金庫の暗証番号を読み上げてきた——これがSSRFだ。外部からは届かない「内部の情報源」に、信頼された内部の存在を経由してアクセスする攻撃だ。
具体的な事例として、Microsoftのオープンソースツール「MarkItDown」がある。GitHubスター90,000以上を持つ人気ツールで、PDFやWord文書をMarkdown形式に変換してくれる。このMCPサーバー版が問題だった。
MCPサーバーが提供する convert_to_markdown というツールは、任意のURIを引数として受け取れる。ここに制限がない。
# ❌ URIを検証せず直接変換する（脆弱な実装）
def convert_to_markdown(uri: str) -> str:
return markitdown.convert(uri) # 169.254.169.254も通ってしまう
AWSのEC2インスタンスでAIコーディングツールを動かしている場合、マシン内部には 169.254.169.254 というIPアドレスにアクセスするだけでIAM認証情報が取得できる特殊なサービスがある。Instance Metadata Service（IMDS）だ。本来はEC2インスタンス自身のための内部サービスで、外部からは到達できない。しかし、AIツール経由で「このURLを変換して」とリクエストされたサーバーは、内部からそのIPに接触できてしまう。
攻撃の流れはこうだ。
IAMロールに管理者権限が付与されていれば、攻撃者はAWSアカウントを完全に掌握できる可能性がある。Microsoftは現時点でMarkItDownにパッチを発行していない。
36.7%という数字の背景——7,000以上のサーバーを調べた結果
BlueRockが分析した7,000以上のMCPサーバーのうち、36.7%がSSRF脆弱性を持つとされた。この数字は、MarkItDownのような「有名なツールの実装ミス」ではなく、MCPエコシステム全体に構造的に広がっている問題であることを示している。
MCP Trust Registry（mcp-trust.com）は、9,000以上の公開MCPサーバーをスキャンし、22のセキュリティルールでコードレベルの分析を実施している。OWASP MCP Top 10やMAESTROフレームワークにマッピングされた分析で、既存のセキュリティ標準との対応を取っている。
vulnerablemcp.infoには50件の脆弱性（うちCritical 13件）がまとめられており、32名の研究者が貢献している。MCPは便利な拡張機能として普及が進んだが、セキュリティ検証が後回しになったまま広まったエコシステムとも言える。
IMDSv2で「なぜ完全には防げないのか」——移行コストの現実
AWSはこのSSRF攻撃への対策として、IMDSv2（Instance Metadata Service Version 2）を導入している。
IMDSv1とIMDSv2を金庫で例えるなら、こうなる。IMDSv1では、金庫の前に警備員を置いたが、警備員に手紙を渡せば中のものを持ってきてくれた。v2では、あらかじめ発行された専用トークンを持っている人しか手紙を渡せなくなった。
IMDSv1はシンプルなGETリクエストだけで認証情報を取得できるため、SSRFに対して脆弱だ。IMDSv2はセッション指向の認証を採用しており、PUTリクエストでトークンを取得してからでないとGETができない。しかも X-Forwarded-For ヘッダーを含むPUTリクエストはブロックされるため、プロキシ経由のSSRFを防げる。
2024年中頃以降、新しいEC2インスタンスタイプはデフォルトでIMDSv2のみを使用するようになった。しかし以前から動いているインスタンスは多くの環境でIMDSv1が残ったままになっている可能性がある。コスト面・移行リスクを考慮して切り替えを後回しにしている組織は少なくない。
IMDSv2への移行は「既存インスタンスでは自動では行われない」。自分の環境がIMDSv2必須になっているか確認が必要だ。
確認と移行の方法は後述する。
連鎖する脆弱性——MarkItDownだけではない
MarkItDownのSSRFは一例にすぎない。類似の脆弱性が複数のMCPサーバーで同時期に発見されている。
mcp-atlassian：2段階の攻撃でRCEが成立（CVE-2026-27825 / 27826）
mcp-atlassianはJiraやConfluenceとAIを連携させるMCPサーバーで、GitHubスター4,400以上、400万以上のダウンロード数を持つ人気パッケージだ。Pluto Securityの研究チームが2種類の脆弱性を発見し、両者を組み合わせると同一ネットワーク上の攻撃者が認証不要でRCE（遠隔コード実行）を達成できることが示された。
CVE-2026-27826（CVSS 8.2）はSSRFだ。X-Atlassian-Jira-Url と X-Atlassian-Confluence-Url という2つのHTTPヘッダーが、検証なしに信頼される。攻撃者はこのヘッダーを偽装することで、MCPサーバーから 169.254.169.254 を含む任意の宛先へのリクエストを発生させられる。
CVE-2026-27825（CVSS 9.1）はパストラバーサルだ。confluence_download_attachment ツールの download_path パラメータに入力検証がなく、攻撃者が指定したパスにファイルを書き込める。~/.bashrc や起動スクリプトに悪意あるコードを書き込めば、シェル初期化時にコードが実行される。
2つのHTTPリクエストを組み合わせると、攻撃者はまずSSRFで認証を回避し、次にパストラバーサルでファイルを書き込む。同じWi-Fiに接続しているだけで攻撃が成立する。修正版は2026年2月24日リリースのv0.17.0だ。
Azure MCP Server：マネージドIDトークンが奪われる（CVE-2026-26118）
CVE-2026-26118はAzure MCP ServerのSSRFによる権限昇格だ（CVSS 8.8）。攻撃者がSSRFを悪用してAzureのマネージドIDトークンを奪取でき、Azureリソースへの不正アクセスが成立する。2026年3月のPatch Tuesdayで修正された。
MarkItDown、mcp-atlassian、Azure MCP——3つは別々のベンダーが開発した別々のツールだ。それぞれに独立したSSRF脆弱性が存在したということは、これが個別の実装ミスではなく、MCPエコシステムに構造的に内在する問題であることを示している。
今すぐできる3つの対策
1. MCPサーバーのコードを確認する
URLや任意のパスを引数に取るツールが、内部IPへのアクセスをブロックしているかを確認する。
# ✅ 内部アドレスをブロックする実装例
BLOCKED_PREFIXES = ["169.254.", "10.", "192.168.", "172.16.", "127."]
def convert_to_markdown(uri: str) -> str:
from urllib.parse import urlparse
parsed = urlparse(uri)
host = parsed.hostname or ""
for blocked in BLOCKED_PREFIXES:
if host.startswith(blocked):
raise ValueError(f"アクセスが拒否されました: {host}")
return markitdown.convert(uri)
自分でMCPサーバーを開発していない場合でも、使用しているMCPサーバーがこうした検証を実装しているかGitHubで確認する価値がある。MCP Trust Registryやvulnerablemcp.infoでスキャン結果を確認することもできる。
2. IMDSv2を必須化する
EC2インスタンスを使っているなら、IMDSv1を無効化してIMDSv2のみを許可する設定に変更する。
# 現在のインスタンスのメタデータオプションを確認する
aws ec2 describe-instances \
--query "Reservations[*].Instances[*].{ID:InstanceId,IMDSOptions:MetadataOptions}"
# IMDSv2を必須化する（インスタンスIDを指定）
aws ec2 modify-instance-metadata-options \
--instance-id i-xxxxxxxxxxxxxxxxx \
--http-tokens required \
--http-endpoint enabled
# IMDSv1がまだ使われているか CloudWatch メトリクスで確認する
# MetadataNoToken の値が 0 になれば IMDSv1 の利用がなくなった
aws cloudwatch get-metric-statistics \
--metric-name MetadataNoToken \
--namespace AWS/EC2 \
--period 3600 \
--statistics Sum \
--start-time 2026-03-01T00:00:00Z \
--end-time 2026-03-11T00:00:00Z
AWSの公式ドキュメントにIMDSv2への移行手順が詳しく記載されている。MetadataNoToken CloudWatchメトリクスがゼロになるまで監視することで、依存関係がないことを確認してから切り替えられる。
3. ネットワークレベルで制限する
アプリケーション層だけでなく、ネットワーク層でも防御を重ねる。EC2のセキュリティグループやAWS WAFで、インスタンスメタデータIPへのアウトバウンドアクセスを制限する。IAMロールの権限を最小化（最小権限の原則）し、万が一トークンが漏洩しても影響範囲を限定する。
MCPの利便性と、その代償
MCPは便利な仕組みだ。AIがブラウザを開き、データベースを読み、Confluenceのドキュメントを参照しながらコードを書いてくれる。開発の生産性は確かに上がる。
ただし、AIに「手」を渡すということは、その「手」を経由した攻撃経路も同時に生まれるということだ。AIツールに接続するMCPサーバーが増えるほど、攻撃面も広がる。
mcp-atlassianを最新版（v0.17.0以降）に更新したか確認する。MarkItDownを使っているなら、EC2インスタンスのメタデータエンドポイントへのアクセスがブロックされているか確認する。Azure MCP Serverは2026年3月のパッチを適用済みか確認する。そしてIMDSv2を必須化する。
MCPを便利に使い続けるための前提条件として、接続するサーバーのセキュリティを確認する習慣を持つことが、今のAIコーディング環境では欠かせない。