MCP Toolboxに認証回避3件｜AIのDB接続が危険

【更新 2026-08-20】本記事を見直し、修正しました。主な修正点：2026年6月18日を「届け出られた」日としていた記載を、JVNDB／NVD上の「公表日」に訂正。あわせて「周知されたのは8月」という記述を、CVE公表は6月18日・日本語（JVNDB）での周知が8月19日と区別する形に改めました。

Googleが公開するオープンソースのMCPサーバ「MCP Toolbox for Databases」に、認証・認可を回避される脆弱性3件（CVE-2026-11717／11718／11719）が公表されました。最大深刻度はCVSS v3.1で9.1（緊急）。細工したトークンやHTTPヘッダで認証をすり抜け、AIエージェント経由で社内データベースに触れられる恐れがあります。

修正版はv1.4.0（2026年6月4日公開）です。CVEとしての公表は2026年6月18日、JVNDBへの登録（日本語での周知）は2026年8月19日で、「直ったのは6月上旬、日本語で周知されたのは8月中旬」という2か月以上のギャップがあります。6月より前に導入してそのまま動かしているToolboxが、いま最も危険です。

この記事でわかること

  • MCP Toolbox for Databasesとは何をするもので、社内のどこで動いているのか
  • 3件の脆弱性がそれぞれ何を許してしまうのか（CVE番号・CVSS・影響バージョン）
  • 自社に該当するかを確認する具体的な手順（プロセス名・ポート・設定ファイルのキー）
  • 「情シスの資産台帳に載らないサーバ」をどう扱うべきか

MCP Toolbox for Databasesとは何者か

MCP Toolbox for Databasesとは、AIエージェントやAIコーディングツールを企業のデータベースに直接つなぐための、Google製のオープンソースMCPサーバです。MCP（Model Context Protocol）は、AIモデルが外部のツールやデータにアクセスするための共通規格です。

用途はシンプルで、「AIに社内DBを触らせる」ことです。公式ドキュメントによれば、接続先としてBigQuery、Cloud SQL（PostgreSQL／MySQL／SQL Server）、AlloyDB、Spanner、FirestoreといったGoogle Cloudのサービスに加え、PostgreSQL、MySQL、MariaDB、SQL Server、Oracle、MongoDB、Redis、Elasticsearch、Snowflakeなど、オンプレミスでもよく使われるデータベースが幅広くサポートされています。

そして情シスにとって重要なのは、これを「誰が立てるか」です。Toolboxは公式に、Gemini CLI、Claude Code、Codex、LangChain、LangGraph、LlamaIndex、ADK、Genkitといったクライアント／フレームワークから利用できるとされています。つまり、導入するのは情シスではなく、データ分析部門や開発チームであることが多いということです。「AIにデータを分析させたい」という現場の要望から、単体バイナリ1つで手軽に立ち上がります。

「うちはGoogle Cloudを使っていないから関係ない」と即断できないのはこのためです。Toolboxは特定クラウドの専用製品ではなく、オンプレのPostgreSQLやOracleにも接続できる汎用のサーバです。まずは後述の確認手順で、社内で動いていないかを見てください。

何が起きたのか：認証・認可の回避3件

2026年8月19日、JVNDBに3件の脆弱性が登録されました。いずれもCVEとしての公表日（JVNDBの「公表日」欄）は2026年6月18日で、NVDでの公開も同日です。

CVE番号 種別 CVSS v3.1 影響バージョン
CVE-2026-11717 認証バイパス（不透明トークン検証） 9.1（緊急） 1.0.0〜1.3.0
CVE-2026-11718 認証バイパス（発行者検証の欠落） 9.1（緊急） 1.0.0〜1.3.0
CVE-2026-11719 認可バイパス（スコープ未適用） 8.1（重要） 1.3.0

※CVE-2026-11717は、NVDではCVSS v4.0で9.3（Critical）と評価されています。

CVE-2026-11717：「active」が無いトークンが通ってしまう

Toolboxが外部のOAuth 2.0イントロスペクションエンドポイント（RFC 7662）に問い合わせてトークンの有効性を確認する処理（validateOpaqueToken）の不備です。

RFC 7662のレスポンスには、トークンが有効かどうかを示すactiveというフィールドが必ず含まれるはずです。ところがToolboxの実装では、この値をブール値へのポインタ（*bool）として受け取り、「activeが存在し、かつfalseのとき」だけ拒否するという条件になっていました。レスポンスにactiveキーそのものが無ければ条件が成立せず、トークンは拒否されないまま通ってしまいます。

CVE-2026-11718：発行者（iss）の検証が黙ってスキップされる

同じくイントロスペクションのレスポンス処理です。クレーム検証（validateClaims）で発行者を照合する条件が a.issuer != "" && iss != "" と書かれていたため、レスポンスに省略可能なissフィールドが含まれていない場合、issが空文字列となり、条件ブロックごと静かに読み飛ばされます。結果として、意図しない第三者のIDプロバイダが発行したトークンでも受け入れられてしまいます。

CVE-2026-11719：古いプロトコルバージョンを名乗るとスコープ制限が消える

これは認証済みのユーザーによる権限昇格です。ToolboxはツールごとにscopesRequiredで必要な権限を定義できますが、この制限を適用していたのは新しいプロトコルバージョン（2025-11-25）のハンドラーだけでした。

攻撃者（＝読み取り権限しか持たない正規ユーザーでも成立します）は、リクエストのMCP-Protocol-Versionヘッダに古いバージョン（2025-06-18、2025-03-26、2024-11-05）を指定するか、ヘッダ自体を省略するだけで済みます。ヘッダが無い場合、サーバは最も古い2024-11-05のハンドラーをデフォルトで使うため、スコープ検査を通らずに管理者向けツールを実行できてしまいます。

なぜ起きたのか：3件に共通する「省略されたときの挙動」

技術的な原因は3件とも異なりますが、根っこは同じです。「相手が何かを省略してきたとき、安全側ではなく通す側に倒れていた」という点です。

  • activeキーが無い → 拒否されない（CVE-2026-11717）
  • issフィールドが無い → 検証されない（CVE-2026-11718）
  • プロトコルバージョンヘッダが無い → 最も緩い古い実装が使われる（CVE-2026-11719）

認証は「有効なものを通す」より「不明なものを弾く」設計のほうが難しく、実装で足をすくわれやすい領域です。認証まわりの実装ミスが連鎖的に影響を広げる例としては、Better Auth脆弱性がSSO/SCIM連携に及んだ件や、OAuth認証の落とし穴──なりすましを生む実装ミスとはも併せて参考になります。

自社は影響を受けるか：確認手順

情シスがまず知りたいのは「うちで動いているのか」です。Toolboxは資産管理台帳に載りにくいため、次の観点で探してください。

  • プロセス／実行ファイル名：toolbox。公式READMEでは ./toolbox --config "tools.yaml" の形で起動します。単体バイナリまたはコンテナで動きます。
  • 待ち受けポート：既定は 127.0.0.1:5000、MCPのエンドポイントは /mcp（公式READMEの接続例より）。ポート5000でLISTENしているプロセスを洗い出すのが早道です。
  • 設定ファイル：tools.yaml。この中に kind: authService の定義があるか、type が generic（汎用OIDC）か、mcpEnabled: true でサーバ全体を保護しているか、scopesRequired でツール単位の権限を切っているかを確認します。
  • バージョン：1.3.0以前なら該当します。v1.4.0以降へ更新してください（最新は2026年8月14日公開のv1.9.0）。

なお、CVE-2026-11717と11718は汎用（generic）のOAuthプロバイダを使ったMCP Authorizationの経路の問題です。Google Sign-Inを使う経路とは実装が分かれており、v1.4.0では両者を分離する修正（PR #3341）が入っています。とはいえ、設定を1つずつ突き合わせて「うちは条件に当たらないから大丈夫」と判断するより、バージョンを上げてしまうほうが確実で速いと考えます。

現場目線の課題：台帳に載らないサーバと、2か月以上の時差

この件でやりきれないのは、脆弱性そのものより「気づけない構造」のほうです。

Toolboxは、情シスの調達プロセスも承認フローも通らずに、開発者のPCやクラウド上のVMで立ち上がります。脆弱性管理ツールが対象にしているのはOSとミドルウェア、良くて主要なパッケージまでで、「誰かがGitHubから落としてきた単体バイナリ」は視界の外です。しかもそれが向いている先は、社内で最も守るべき本番データベースです。AIエージェント基盤そのものが攻撃対象になっている流れは、Ray脆弱性が悪用中、開発者端末がRCE標的にとも重なります。

もうひとつは時差です。修正版のv1.4.0が出たのは6月4日、CVEが公表されたのは6月18日、そして日本語のJVNDBに載ったのは8月19日。英語のリリースノートやNVDを自分で追っていない環境では、更新の動機を持たないまま2か月半ほど放置されたことになります。OSSを自前で運用するとは、こういうことでもあります。ベンダー製品なら届くはずの「お知らせメール」は、GitHubのリリースノートを自分で見に行かないと存在しません。

さらに言えば、MCPサーバの認証がそもそも弱いという指摘は以前からありました。MCPサーバ91.8%が認証なしという調査結果も出ています。今回のように「認証を実装していたが、その実装に穴があった」ケースは、まだ良いほうかもしれません。それだけに、「認証を設定したから安心」で止まらないことが要点だと感じます。

情シスはどうすべきか

個別の対策手順を長々と並べるより、まず優先順位を3つに絞るのが現実的です。

  1. 探す：ポート5000／プロセス名toolbox／tools.yamlを手がかりに、社内で稼働していないか棚卸しする。見つかったらバージョンを確認する。
  2. 上げる：1.3.0以前ならv1.4.0以降へ更新する。可能なら最新版に追随する。
  3. 囲う：AIエージェントからDBに接続する経路は、接続先アカウントの権限を最小化する（読み取り専用ユーザーを使う、本番DBに直結させない）。認証の実装バグが出ても被害範囲を限定できるのは、結局この層です。

組織としての土台づくりには、公的機関の指針を出発点にするのが早道です。「AIツールの持ち込みをどう管理するか」は突き詰めればシャドーIT・資産管理の問題であり、IPAの中小企業の情報セキュリティ対策ガイドラインが、規模を問わず使える基本の型を示しています。あわせて、現場の利用者向けには対策のしおりのような平易な啓発資料が役に立ちます。

技術的な統制以上に効くのは、「AIに社内データをつなぐときは一声かけてください」と言える関係を作っておくことだと考えます。禁止しても止まらない類のツールだからこそ、地道な周知と、相談しやすさの確保が最後の砦になります。

中長期の視点：MCPサーバは「新しい特権システム」として扱う

MCPサーバは、AIと社内データの間に立つ中継点です。役割としては、かつてのAPIゲートウェイや踏み台サーバに近い位置づけになりつつあります。であれば、扱いも同格にすべきです。

具体的には、資産台帳への登録対象に含める、認証設定を構成管理の対象にする、バージョン更新をパッチ適用のサイクルに乗せる、といった当たり前のことです。「新しくて面白いツール」から「守るべきインフラ」へ分類を変えるタイミングが、まさに今だと思います。

まとめ

  1. Google製のMCPサーバ「MCP Toolbox for Databases」に認証・認可の回避3件（CVE-2026-11717／11718／11719、最大CVSS v3.1で9.1）。影響は1.0.0〜1.3.0で、修正はv1.4.0。
  2. 原因は3件とも「相手がフィールドやヘッダを省略したときに、弾かずに通してしまう」実装。特にCVE-2026-11719はMCP-Protocol-Versionヘッダを省くだけでスコープ制限を回避できる。
  3. Toolboxは開発・データ部門が単体バイナリで立てるため台帳に載らない。ポート5000・プロセス名toolbox・tools.yamlを手がかりに棚卸しし、接続先DBの権限も最小化しておくこと。

出典

タイトルとURLをコピーしました