AIに監視ツールGrafanaを操作させる連携ツール『mcp-grafana』に脆弱性、認証情報が盗まれる恐れ CVE-2026-15583、v0.17.2へ即更新を

監視ツール「Grafana（グラファナ）」をAIアシスタントから操作するための連携プログラム「mcp-grafana」に、保存された認証情報を丸ごと盗まれる恐れのある深刻な脆弱性（プログラムの弱点）が見つかりました。2026年7月15日に米国の脆弱性データベース（NVD）が公表したもので、管理番号はCVE-2026-15583、危険度は10点満点で8.6（重要）と評価されています。

怖いのは、特別なログインもいらず、インターネット越しに誰でも突ける点です。攻撃者が細工したリクエストを1回送るだけで、サーバーに保存されている監視システムの認証情報（サービスアカウントの鍵）が攻撃者の手元へ送り出されてしまう可能性があります。さらに、この穴を使って社内ネットワークの内部サービスや、クラウド上の秘密情報を抜き取る足がかりにもできます。

Grafanaは、サーバーやアプリの状態をグラフで見える化する、世界中の企業で使われている監視ツールです。mcp-grafanaは、そのGrafanaにChatGPTやClaudeといったAIアシスタントを接続し、「今サーバーは重くないか」「エラーは増えていないか」を人間の言葉で問い合わせられるようにする橋渡し役です。対策はすでに用意されていて、修正版のv0.17.2（2026年7月13日公開）以降に更新するだけです。何が起きるのか、自分の使い方は危ないのか、順番に見ていきます。

脆弱性の概要

CVE-2026-15583: 送信先を偽装され、鍵を持ち逃げされる弱点

今回の弱点は、専門的には「取り違えられた代理人（confused deputy、コンフューズド・デピュティ）」と呼ばれる問題です。権限を持った正規のプログラムが、外から言われるがままに自分の権限を使ってしまい、結果として攻撃者に加担させられてしまう、という古典的な落とし穴です。mcp-grafanaには、AIからの問い合わせをどのGrafanaに取り次ぐかを、リクエストのX-Grafana-URLという項目で切り替えられる複数組織向けの正規機能があります。ところが、攻撃者がこの送信先を自分のサーバーのアドレスに書き換えると、mcp-grafanaは本来Grafanaに渡すはずの認証情報をそのまま攻撃者のサーバーへ送ってしまう設計になっていました。

「認証情報（サービスアカウントの鍵）」とは、mcp-grafanaがGrafanaにアクセスするために持たされている合鍵のことです。この鍵を奪われると、攻撃者はあなたのGrafanaに正規の権限でアクセスできてしまいます。監視ダッシュボードには、サーバーの構成、内部のIPアドレス、アラートの設定、場合によっては連携先の認証情報まで集まっているため、鍵1本の流出が組織全体の内情の露見につながりかねません。危険度8.6は、GrafanaやAI連携ツールで報告されるものとしては上位の重さです。

修正までの流れ

mcp-grafanaの開発チームは、CVEが公表される前から少しずつ守りを固めていました。7月7日の版でネットワーク経由の別の攻撃手法を塞ぎ、7月13日の版で今回の核心である認証情報の送信先固定を実装しています。CVEとして正式に番号が振られ広く公表されたのが7月15日です。

← スワイプで移動

自分の使い方は危ないのか（早見表）

全員が同じ危険度にさらされるわけではありません。mcp-grafanaは動かし方（通信方式）がいくつかあり、危ないのはネットワークに開いた形で動かしている場合です。自分のパソコンの中だけで動かす「stdio方式」（AIアプリと直接つなぐローカル起動）では、外部からリクエストを送り込めないため、今回の攻撃は直接は成立しません。下の表で自分の状況を確認してください。

使っている版は、mcp-grafanaのリリース一覧と手元の起動設定で確認できます。Grafana本体をAIアシスタントにつなぐ機能は公式ドキュメントでも案内されており、社内で誰かが検証目的に立ち上げたまま放置しているケースが盲点になりがちです。自分では使っていなくても、チームの誰かが動かしていないか一度確認しておくと安心です。

誰が、どう悪用するのか

この弱点が刺さるのは、mcp-grafanaをネットワーク越しにアクセスできる形で動かしている組織です。AIアシスタントを社内の複数チームで共有しようとして、mcp-grafanaをHTTPで待ち受けさせている構成が、まさに標的になります。

狙うのは、そのサーバーの受付口に届く場所にいて、ログインもせずに細工したリクエストを送れる相手です。インターネットに直接さらされていれば世界中の誰でもが該当し、社内限定でも、別のマルウェアで社内に入り込んだ攻撃者や、アクセス権のある内部の人物が候補になります。難しい前提はほとんど要らず、「送信先を書き換えたリクエストを1回投げる」だけで成立してしまうのが厄介な点です。

攻撃者がやることは単純です。リクエストの送信先を自分の用意したサーバーに書き換えて投げると、mcp-grafanaが握っているGrafanaの合鍵を、そっくりそのまま攻撃者のサーバーへ届けさせることができます。加えて、送信先を「社内の別のシステム」や「クラウドが内部で持つ設定情報の取り出し口」に向ければ、本来外から触れないはずの内部サービスをmcp-grafana経由で覗く踏み台にもできます。これはサーバー側リクエスト偽造（SSRF）と呼ばれる手口で、クラウド上の一時的な認証情報が抜かれると被害が一気に広がります。

被害の広がり方は二段構えです。まず監視システムの合鍵が渡れば、攻撃者はあなたのGrafanaに正規ユーザーの顔で入り込み、サーバー構成・内部アドレス・アラート設定といった内情を読み取れます。次に、そこで得た情報とSSRFを組み合わせれば、監視対象のインフラそのものへ手を伸ばす起点になります。AIに監視を任せる利便性の裏で、その連携役が組織のインフラ全体への入口になりかねない、というのが今回の本質です。仕組みとしては、認証情報が盗まれるAIにサーバー群を操作させる連携ツール「mcp-server-kubernetes」の脆弱性や、送信先を偽装されるSNSサーバーMastodonのクラウド認証情報窃取の事例と同じ系統に位置づけられます。

技術的に見るとどういう仕組みか

mcp-grafanaは、複数の組織やテナントを1台でさばけるように、接続先GrafanaのURLや認証トークンをリクエストのヘッダーから受け取れる設計になっています。X-Grafana-URLやX-Grafana-Service-Account-Tokenといったヘッダーが用意され、指定がなければ環境変数（サーバー起動時に設定した値）にフォールバックする仕組みです。これ自体は正規の複数組織サポート機能で、便利さのために用意されたものでした。

問題は、「送信先URLは外から自由に指定できる」のに、「その送信先へ渡す認証情報は、サーバー側が握っている強い鍵のまま」だった点です。攻撃者がX-Grafana-URLに自分のサーバーを指定すると、mcp-grafanaは環境変数に設定されたサービスアカウントトークン（さらに旧式のAPIキー、ベーシック認証、追加ヘッダーまで）を、その攻撃者のサーバー宛に律儀に送り出してしまいます。正規の権限を持つプログラムが、外部の指示のままにその権限を行使してしまう。これが「取り違えられた代理人」と呼ばれるゆえんです。送信先を内部アドレスやクラウドのメタデータ取得口に向けるSSRF（CWE-918）にも同じ穴が使えます。

修正版のv0.17.2では、この設計を改め、「環境変数で設定した認証情報は、環境変数で設定したGrafana URLにしか送らない」よう縛りを入れました。ヘッダーで別のURLを指定しても、サーバーが握る強い鍵はもう付いていきません。前の版のv0.17.1でもDNS再バインド攻撃（通信の途中で送信先をすり替える手口）への対策が入っており、ネットワークに開いたMCPサーバーの守りが立て続けに強化された形です。AIとツールをつなぐMCPという仕組みは、ここ1年ほどで一気に使われ始めています。こうした「連携役に強い権限を持たせたまま外に開く」構図は、認証なしで侵入できたmcp-pinotの事例をはじめ、他のMCPサーバーでも繰り返し問題になっています。導入時に依存する部品の安全性を点検する視点は、OSSサプライチェーンの安全確認の観点からも欠かせません。

今やっておくべき対策

対応の芯は明快です。順にやれば十分に塞げます。

まず、mcp-grafanaをv0.17.2以降に更新すること。これが根本対策です。公式リリースから最新版を取得してください。次に、MCPサーバーを不特定多数から触れる場所に置かないこと。インターネットに直接さらす構成は避け、必要な相手だけがアクセスできるよう接続元を絞ります。3つ目に、外向きの通信を制限すること。ファイアウォールで、クラウドの設定情報取得口（内部向けの特別なアドレス）への通信や、想定外の外部宛通信を遮断しておけば、万一穴が残っていても情報の持ち出しを止められます。

加えて、すでに鍵が漏れた前提で動くことも検討してください。更新前にネットワークへ開いた状態で運用していた期間があるなら、Grafanaのサービスアカウントトークンを新しいものに作り直す（ローテーションする）のが安全です。攻撃はログの残りにくい単発リクエストで済むため、「攻撃された形跡がない＝安全」とは言い切れません。監視を任せる連携役ほど強い権限を持ちがちで、そこが抜かれた時の被害は大きくなります。AIにインフラを触らせる構成を組むときは、連携役に渡す権限を必要最小限に絞る設計を、今回を機に見直しておくとよいでしょう。

参照元

• ▸ NVD - CVE-2026-15583 Detail（2026年7月15日公開、CVSS 8.6）
• ▸ mcp-grafana v0.17.2 リリースノート（今回の修正版）
• ▸ grafana/mcp-grafana - GitHubリポジトリ
• ▸ Grafana公式 - 複数組織とヘッダーの設定（X-Grafana-URLの解説）
• ▸ Grafana公式 - MCPサーバーの概要
• ▸ CWE-918: Server-Side Request Forgery (SSRF)