CVE-2026-125926｜AWSのmcp-gateway-registryにSSRF、1.35.0で修正・更新後に要る確認

CVE-2026-125926 は、MCP サーバーの登録簿とゲートウェイを兼ねる OSS mcp-gateway-registry の SSRF（サーバーサイドリクエストフォージェリ）だ。サーバーの登録権限を持つユーザーが転送先を細工すると、ゲートウェイから内部ネットワークのサービスへリクエストを送れた。対象は 1.0.3〜1.34.0、修正版は 1.35.0。AWS は 2026-11-11 にセキュリティ速報を出した。本記事は速報とリポジトリを読んで整理した。

まずやること

・自分で運用している人：1.35.0 以降へ更新する。そのあと、登録済みサーバーの転送先アドレスを一覧で見直す
・すぐ更新できない人：登録・変更の権限を信頼できるアカウントに絞り、レジストリと認証サーバーから外へ出る通信を必要な宛先だけにする
・EC2 で動かしている人：IMDSv2 を必須にし、付けているロールの権限を必要な分だけにする

依存する OSS の脆弱性が自分のシステムに及ぶ構図はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

CVE-2026-125926 の時系列

修正版は、公表の13日前に出ていた。1.35.0 のリリースノートに、この CVE の番号や SSRF という語は出てこない。リリースノートだけを追っていた運用者は、11月11日の速報で初めて、1.35.0 がセキュリティ上の区切りだったと知ることになる。

同じ日に、AWS は同じ製品の別の速報（2026-179-AWS）も出している。こちらは CVE-2026-100307 で、外部管理 API の認可の欠落を扱う。対象は 1.0.9〜1.24.7、修正は 1.25.0 だ。

何が起きたか：登録した転送先がそのまま使われた

mcp-gateway-registry は、MCP サーバーの発見、アクセス制御、ツールの中継を1か所にまとめる OSS だ。ライセンスは Apache-2.0。利用者はサーバーを登録するとき、中継先になる上流のアドレスを渡す。

AWS の速報は、問題を「登録されたサーバーの上流アドレスを、レジストリがどう検査するか」にあるとしている。登録や変更の権限を持つ認証済みのユーザーが上流アドレスを設定すると、ゲートウェイがデプロイ先の内部ネットワークのサービスへリクエストを送った。場合によっては、その応答がユーザーに返った。

危険なのは、リクエストの出どころがゲートウェイになる点だ。ユーザー自身は届かない相手にも、ゲートウェイのネットワーク上の位置からなら届く。速報の要約は、届きうる先として内部のサービスと、クラウドのインスタンスメタデータのエンドポイントを挙げている。

どんなアドレスで成立するかといった手順は公開されていない。本記事も推測しない。SSRF の一般的な仕組みは SSRFとは｜サーバーに内側を叩かせる攻撃の仕組みと、素朴なブロックリストが破られる理由・正しいSSRF対策 に書いた。

CVE-2026-125926 への対策：更新と、そのあとの3つの確認

まず 1.35.0 以降へ更新する。フォークや派生したコードを使っている場合は、そちらにも修正を取り込む必要がある。

版の読み違えに注意したい。

1.25.0 で「セキュリティ修正を入れた」と記憶しているチームは、この SSRF については未対応のままだ。

更新だけでは終わらない。1.35.0 は、サーバーを登録・変更するときに上流アドレスを検査する。更新より前に保存された設定には手を付けない。

AWS が求める更新後の作業は3つだ。

・登録済みサーバーの上流アドレスを見直し、意図していないものは直すか消す
・対象の版を動かしていた期間のアプリケーションログから、想定外の登録と変更を探す
・レジストリにクラウドのロールが付いていて、ログで想定外の動きを否定できなければ、ロールの活動を確かめて認証情報を入れ替える

すぐに更新できない場合の緩和策も示されている。AWS は、これらが更新後の作業の代わりにはならないと断っている。

自分のリポジトリで mcp-gateway-registry の利用を確認するコマンド

自分のチームが使っているかどうかは、デプロイの定義から探せる。配布されている compose ファイルは、イメージを public.ecr.aws/p3v1o3c6 から取り、版を REGISTRY_VERSION などの変数で指定する。この文字列を探す。

git fetch --all --prune
grep -rnIE 'public\.ecr\.aws/p3v1o3c6|REGISTRY_VERSION|AUTH_SERVER_VERSION|MCPGW_VERSION' . --exclude-dir=.git --exclude-dir=node_modules

1.34.0 の docker-compose.prebuilt.yml を置いたディレクトリでは、次のように出た。関係するファイルが無いディレクトリでは何も出ず、終了コードは 1 だった。

./docker-compose.prebuilt.yml:52:    image: ${ECR_REGISTRY:-public.ecr.aws/p3v1o3c6}/registry:${REGISTRY_VERSION:-latest}
./docker-compose.prebuilt.yml:462:    image: ${ECR_REGISTRY:-public.ecr.aws/p3v1o3c6}/auth-server:${AUTH_SERVER_VERSION:-latest}
./docker-compose.prebuilt.yml:674:    image: ${ECR_REGISTRY:-public.ecr.aws/p3v1o3c6}/mcpgw:${MCPGW_VERSION:-latest}

これは利用の有無の確認で、脆弱性の判定ではない。この結果だけでは、対象とも対象外とも言えない。出力のとおり、版の既定値は latest だ。変数を指定していなければ、ファイルからは動いている版がわからない。その場合は、動いているコンテナのイメージがいつ取得されたものかを確かめる。行が出なくても、Helm や Terraform で入れている構成、イメージを自前のレジストリに複製している構成は拾えない。

影響範囲と、まだわかっていないこと

影響の大きさは、ゲートウェイからどこへ届くかで決まる。同じネットワークに管理用の API やデータベースがあれば、それが届く先になる。EC2 でロールを付けて動かし、IMDSv1 が有効なら、メタデータ経由で一時的な認証情報に届きうる。逆に、外へ出る通信を絞り、IMDSv2 を必須にしていれば、届く範囲は狭い。

攻撃の前提は「登録・変更の権限を持つ認証済みユーザー」だ。社内の誰でも MCP サーバーを登録できる運用にしていると、前提を満たす人が増える。登録を管理者だけに絞っている環境では、条件は厳しくなる。

わかっていない点もある。

・悪用の有無：AWS の速報に、悪用や認証情報の窃取が起きたという記載は無い
・攻撃の具体的な条件：どのアドレスの形で成立するかは公開されていない
・深刻度の数値：速報の種別は「Important」。CVSS の値は速報の本文に書かれていない

MCP のゲートウェイは、多くのツールへの入口を1か所に集める。便利な反面、そこが内部ネットワークへの踏み台になると影響が広い。利用者が指定した URL へサーバーがつなぐ機能で同じ型の問題が起きた例は、Next.js CVE-2026-44578｜WebSocket SSRF（CVSS 8.6）の仕組みと緊急対策 でも扱った。

参照ソース

・CVE-2026-125926 - Server-side request forgery in the server registration and update API in mcp-gateway-registry（AWS Security Bulletin 2026-180-AWS）
・agentic-community/mcp-gateway-registry（GitHub）
・1.35.0 のリリースノート
・AWS MCP Gateway Security Flaw Allowing Access to Internal Networks and Cloud Credentials（Cyber Security News）