情報取得日: 2026/07/31・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-14537 |
|---|---|
| 製品 | Google / MCP Toolbox for Databases(mcp-toolbox)v1.3.0 および v1.4.0 |
| CVSS | 9.8(Critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 種別 (CWE) | CWE-863 不正な認可 |
| 登録/公開日 | 2026/07/31 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-14537 |
Google の MCP Toolbox for Databases(mcp-toolbox)に、認可を回避してツールを呼び出せる欠陥がある。NVD の記述によれば、--enable-api フラグが有効なとき、直接 HTTP API のツール呼び出しエンドポイント(レガシー HTTP エンドポイント)を通すことで、scopeRequired 機能で保護されているツールを未認証の攻撃者が呼び出せる。対象は v1.3.0 と v1.4.0 の2バージョンで、NVD の CPE もこの2つだけをピンポイントで指している。 修正は upstream の googleapis/mcp-toolbox に PR #3435 として入り、2026年6月18日にマージ、同日リリースの v1.5.0 に含まれている。修正の中身は認可処理の穴を塞ぐものではなく、起動時の検証を足すというものである。PR の説明では「MCP Authorization が有効な状態でレガシー HTTP API(--enable-api / EnableAPI)と同時に起動することを防ぐ起動時チェックを導入した」とされ、理由として「レガシーエンドポイントは非推奨で新機能がサポートされないため、クライアントがレガシー HTTP API を使って MCP の認可ポリシーを回避しうる」と書かれている。つまり v1.5.0 以降は、この2つを同時に有効にした構成では起動そのものが失敗する。 深刻度は採番元の Google(cve-coordination@google.com)が CVSS 4.0 で 8.1、NVD が Primary として CVSS 3.1 で 9.8 Critical としている。Google のベクタには E:U(Exploit Maturity: Unreported)が入っており、悪用の報告は無いという評価である。CISA の KEV には本稿の確認時点(2026-08-24・カタログ 2026.08.21)で収載されていない。 この件は、MCP サーバを本番に置く構成で「認可を新しい経路に足したが、古い経路が残っていた」という形の典型である。新旧2つの入口を持つ製品では、認可を新しい入口にだけ実装すると古い入口が素通しになる。修正が起動時チェックという形を取ったのは、この構成自体を作らせないほうが確実だという判断だと読める。
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | 回避策のみ |
EC2 / ECS / EKS / Lambda 上で動かしている mcp-toolbox のバイナリまたはコンテナイメージを v1.5.0 以降へ差し替える。あわせて起動引数から --enable-api を外す。
AWS 側に修正対象は無い。mcp-toolbox は Google の OSS であって AWS のマネージドサービスではないため、更新は利用者側で行う。
参照リンク
|
| GCP | 回避策のみ |
Cloud Run / GKE / GCE 上のイメージを v1.5.0 以降へ更新する。Cloud Run はリビジョンを差し替えて再デプロイする。
mcp-toolbox は Google が公開している OSS だが、実行環境は利用者が用意する。GCP のマネージド機能として自動更新される経路は無いので、イメージのタグを固定している場合は明示的に引き直す。
参照リンク
|
| Azure | 回避策のみ |
同上。Azure VM / AKS / Container Apps 上のイメージを v1.5.0 以降へ更新する。
Azure 側に修正対象は無い。
参照リンク
|
| Linux | パッチあり(アプリ更新) |
mcp-toolbox はディストリの標準パッケージとして配布されていないため、ディストリのセキュリティ更新では直らない。GitHub リリースのバイナリ、または公式コンテナイメージを v1.5.0 以降へ差し替える。
Debian / Ubuntu / RHEL いずれも mcp-toolbox パッケージを持たない。「ディストリが未対応」ではなく配布対象外である。
参照リンク
|
対応は、(1)mcp-toolbox を使っているか、(2)バージョンが v1.3.0 / v1.4.0 か、(3)--enable-api を付けているか、の3点で決まる。3つとも該当したときだけ実害があるので、切り分けは速い。 まずバージョンである。toolbox --version で確認する。v1.5.0 以降であれば、この構成は起動時に弾かれるので該当しない。v1.2.0 以前は NVD の CPE の対象外である(scopeRequired 機能そのものが入っていない時期にあたるため)。 次に起動オプションである。--enable-api はレガシーの HTTP API を有効にするフラグで、既定では無効である。systemd の unit ファイル、Dockerfile の CMD、Kubernetes の Deployment の args、docker-compose の command を実際に見て、このフラグが付いているかを確認する。付いていなければ、該当バージョンであっても攻撃経路は開いていない。 三つ目が保護対象である。scopeRequired を使って特定のツールに認可を掛けている場合、その保護がレガシー経路では効いていない。tools.yaml(設定ファイル)で scopeRequired を指定しているツールを列挙し、それらが何をするツールかを見る。データベースへの書き込みや削除を行うツールが含まれているなら、優先度は高い。参照だけのツールしか無いなら、影響は情報漏えいにとどまる。 更新は v1.5.0 以降へ上げる。上げた後、--enable-api と MCP Authorization を両方有効にしている構成では起動が失敗するので、レガシー API を切るか、認可を切るかの判断が要る。切るべきはレガシー API のほうである。すぐに上げられない場合の当面の措置は --enable-api を外すことで、これは成立条件そのものを消すので確実である。ただし公式の workaround として提示されたものではない。 完了条件は、(1)全インスタンスが v1.5.0 以降であること、かつ(2)--enable-api を必要としていないことを起動設定の実測で確認済みであることの2点である。
Critical(CVSS 9.8)に分類されるGoogle MCP Toolbox for Databases(mcp-toolbox)v1.3.0 および v1.4.0の脆弱性です。Google の MCP Toolbox for Databases(mcp-toolbox)に、認可を回避してツールを呼び出せる欠陥がある。NVD の記述によれば、--enable-api フラグが有効なとき、直接 HTTP API のツール呼び出しエンドポイント(レガシー HTTP エンドポイント)を通すことで、scopeRequired 機能で保護されているツールを未認証の攻撃者が呼び出せる。対象は v1.3.0 と v1.4.0 の2バージョンで、NVD の CPE もこの2つだけをピンポイントで指している。 修正は upstream の googleapis/mcp-toolbox に PR #3435 として入り、2026年6月18日にマージ、同日リリースの v1.5.0 に含まれている。修正の中身は認可処理の穴を塞ぐものではなく、起動時の検証を足すというものである。PR の説明では「MCP Authorization が有効な状態でレガシー HTTP API(--enable-api / EnableAPI)と同時に起動することを防ぐ起動時チェックを導入した」とされ、理由として「レガシーエンドポイントは非推奨で新機能がサポートされないため、クライアントがレガシー HTTP API を使って MCP の認可ポリシーを回避しうる」と書かれている。つまり v1.5.0 以降は、この2つを同時に有効にした構成では起動そのものが失敗する。 深刻度は採番元の Google(cve-coordination@google.com)が CVSS 4.0 で 8.1、NVD が Primary として CVSS 3.1 で 9.8 Critical としている。Google のベクタには E:U(Exploit Maturity: Unreported)が入っており、悪用の報告は無いという評価である。CISA の KEV には本稿の確認時点(2026-08-24・カタログ 2026.08.21)で収載されていない。 この件は、MCP サーバを本番に置く構成で「認可を新しい経路に足したが、古い経路が残っていた」という形の典型である。新旧2つの入口を持つ製品では、認可を新しい入口にだけ実装すると古い入口が素通しになる。修正が起動時チェックという形を取ったのは、この構成自体を作らせないほうが確実だという判断だと読める。
対応は、(1)mcp-toolbox を使っているか、(2)バージョンが v1.3.0 / v1.4.0 か、(3)--enable-api を付けているか、の3点で決まる。3つとも該当したときだけ実害があるので、切り分けは速い。 まずバージョンである。toolbox --version で確認する。v1.5.0 以降であれば、この構成は起動時に弾かれるので該当しない。v1.2.0 以前は NVD の CPE の対象外である(scopeRequired 機能そのものが入っていない時期にあたるため)。 次に起動オプションである。--enable-api はレガシーの HTTP API を有効にするフラグで、既定では無効である。systemd の unit ファイル、Dockerfile の CMD、Kubernetes の Deployment の args、docker-compose の command を実際に見て、このフラグが付いているかを確認する。付いていなければ、該当バージョンであっても攻撃経路は開いていない。 三つ目が保護対象である。scopeRequired を使って特定のツールに認可を掛けている場合、その保護がレガシー経路では効いていない。tools.yaml(設定ファイル)で scopeRequired を指定しているツールを列挙し、それらが何をするツールかを見る。データベースへの書き込みや削除を行うツールが含まれているなら、優先度は高い。参照だけのツールしか無いなら、影響は情報漏えいにとどまる。 更新は v1.5.0 以降へ上げる。上げた後、--enable-api と MCP Authorization を両方有効にしている構成では起動が失敗するので、レガシー API を切るか、認可を切るかの判断が要る。切るべきはレガシー API のほうである。すぐに上げられない場合の当面の措置は --enable-api を外すことで、これは成立条件そのものを消すので確実である。ただし公式の workaround として提示されたものではない。 完了条件は、(1)全インスタンスが v1.5.0 以降であること、かつ(2)--enable-api を必要としていないことを起動設定の実測で確認済みであることの2点である。
Google MCP Toolbox for Databases(mcp-toolbox)v1.3.0 および v1.4.0 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://nvd.nist.gov/vuln/detail/CVE-2026-14537)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください。