Grafanaの脆弱性4件 先に見るのはAzure Monitorの権限と匿名アクセス

Grafanaの修正版が、2週間でまた出ました。Grafana Labsは10月27日、脆弱性4件を公表し、12.4から13.2までの各系に修正版を出しました。10月13日の前回の修正から、ちょうど2週間後です。同じ日に出た新しい系の13.3.0にも、4件のうち3件の修正が入りました。

ドイツのBSIは、この4件をまとめた注意情報の深刻度を「kritisch」（重大）としました。ただ、1件ずつ条件を読むと、急ぐべき会社とそうでない会社ははっきり分かれます。

4件の中身と修正版

修正版は系ごとに次のとおりです。13.3.0の変更履歴には、SSOの件を除く3件の修正が載っています。SSOの件の勧告は、13.2だけを対象としています。

編集部が見落とされやすいと考えるのは、表の最後の行です。Azure Monitorの件は10.0.0から、式の件は7.4.0から当たるのに、修正版は12.4以降の系にしか出ていません。11系や12.0〜12.3で止めているGrafanaは、今回の更新では直せず、修正版のある系へ移る必要があります。

数字が最も高いSSOの件は、当たる会社が少ない

CVE-2026-103506では、ログインできる利用者が、SSOのクライアントシークレットを読んだり、インスタンス全体のSSOの設定を変えたりできます。ただし、勧告は対象を、実験的な機能の切り替え「kubernetesSsoSettingsApi」を有効にした13.2に限っています。この切り替えは既定で無効です。

自社運用のGrafanaで切り替えを入れているかは、設定ファイルの[feature_toggles]の節に「kubernetesSsoSettingsApi = true」の行があるか（古い書き方のenableの一覧も含めて）と、環境変数で同じ切り替えを入れていないかで分かります。環境変数の名前は、手引きの例では「GF_FEATURE_TOGGLES_newNavigation=true」のように、GF_FEATURE_TOGGLES_のあとに切り替えの名前を付けた形です。Grafana Cloudでは、手引きによると、実験的な機能の切り替えはサポートに頼んで有効にする形です。頼んだ覚えがなければ当たらないと読めます。

8.9という数字は、この件だけCVSS 4.0で付けられています。ほかの3件はCVSS 3.1の値で、物差しが違います。BSIの「kritisch」も4件をまとめた評価です。編集部は、更新の順番を数字の大きさではなく、切り替えを入れているか、Azure Monitorを使っているか、という条件で決めるのがよいと考えます。

Azure Monitorは2週間で2件目 被害はAzureの権限の広さで決まる

CVE-2026-88967では、Azure Monitorのデータソースに問い合わせできる人が、Grafanaのサーバーから攻撃者の用意した宛先へ要求を送らせられます。その要求で、データソースが使うAzureのアクセストークンが漏れます。

Azure Monitorのデータソースの件は、10月13日にもありました。CVE-2026-93294では、同じデータソースの中継の仕組みを使い、Grafanaに必要な範囲を超えてAzure Resource ManagerのAPIを呼べました。その勧告は、影響が「その識別子に与えたAzureの役割の範囲に限られる」と書いています。10月27日の勧告にこの書き方はありませんが、今回のトークンの漏えいでも、漏れたトークンで何ができるかは、データソースに付けた役割で決まると考えられます。

編集部は、2件のどちらでも、Grafanaの更新と同じくらい効くのは、データソースのAzureの識別子（マネージドIDやアプリの登録）の役割を絞ることだとみています。監視のために読むだけなら、閲覧に足りる役割で十分なはずです。サブスクリプション全体に広い役割を付けたままの会社は、今日のうちに見直す価値があります。

アラートの通知先を書き換えられると、監視が黙る

CVE-2026-100105では、連絡先を編集できても保護された項目は変えられないはずの利用者が、通知の連携を古い形式に切り替え、送り先のURLなどを書き換えられます。保存した資格情報が見えるおそれもあります。

情報が漏れる以上に気になるのは、アラートの行き先を、気づかれずに変えられる点です。侵入した者が通知を自分の宛先に向ければ、監視は鳴っているのに、担当者には届きません。更新のあとは、連絡先の送り先と連携の設定を一度見て、知らない宛先が無いかを確かめておくと安心です。

Viewerで止められる式の件は、匿名のアクセスを開けているかで急ぎ度が変わる

CVE-2026-88858では、Viewerの役割の利用者が、細工した式でサーバーを止められます。アラートのルールを登録できる人なら、再起動のあとも止まった状態を続けられます。

Viewerは、多くの社内で広く配られる役割です。さらに、Grafanaの匿名のアクセスを有効にしていると、ログインしない人にも設定した役割が付きます。手引きの設定の例はViewerです。社外から開けるGrafanaで匿名のアクセスを有効にしているなら、この件は「ログインできる人だけの問題」ではなくなります。

影響する会社と急ぎ度

9〜10月の11件はGrafanaの脆弱性11件（9〜10月）、系列ごとの修正版と認証の確認点に、9月のプラグインの件はGrafanaにコード実行の脆弱性13.2.2等で修正にまとめています。10月は13日と27日の2回、修正版が出ました。Grafanaの更新を、月に2回の決まった作業として予定に入れておくのも手です。

上げる手順と、上げたあとに見ること

1. 使っているGrafanaの版を確認し、上の表で急ぎ度を決めます。社内に複数のGrafanaがあることも多いので、部署ごとに立てたものも数に入れます。
2. Azure Monitorのデータソースがあれば、使っている認証の方式と、Azureの識別子に付いた役割を一覧にします。広すぎる役割は、閲覧に足りる範囲に絞ります。アプリの登録で動かしているなら、クライアントシークレットの作り直しも考えます。
3. 系ごとの修正版に上げます。11系や12.0〜12.3は、修正版のある系へ移る日を決めます。
4. 上げたあと、連絡先の送り先と連携の設定を見て、知らない宛先が無いかを確かめます。
5. 設定ファイルの[feature_toggles]と、匿名のアクセスの設定を見ます。SSOの切り替えを入れていた場合は、SSOのクライアントシークレットを作り直し、SSOの設定が変わっていないかを確かめます。