Metabaseに緊急脆弱性、認証不要で管理者奪取

BIツール「Metabase」に、認証なしで管理者権限を奪える SQLインジェクション(CVE-2026-72898、CVSS 3.1で10.0)が見つかりました。修正版は2026年8月6日公開ですが、公表時点ですでに悪用されていたゼロデイで、8月7日〜10日にかけて複数の企業が実際の侵害を公表しています。

米CISAは2026年8月11日にKEV(悪用が確認された脆弱性カタログ)へ登録し、対応期限を8月14日——追加から3日——に設定しました。該当バージョンを自社で動かしているなら、盆休みに入る前に手を打つべき案件です。

Metabaseとは何者か

Metabaseとは、社内のデータベースにつないでグラフやダッシュボードを作る、オープンソースのBI(ビジネスインテリジェンス)ツールです。SQLが書けない人でもクリック操作で売上や利用状況を集計できるため、経営企画・営業企画・マーケティング・データ分析チームが自分たちで導入するケースが多いのが特徴です。公式サイトは10万社以上での利用を掲げています。

情シスにとって重要なのは、次の3点です。

  • 導入が異様に簡単:Dockerコマンド1行(docker run -d -p 3000:3000 metabase/metabase)で立ち上がります。情シスに申請せず、事業部門やデータチームが自前のサーバやクラウド上に立てていることが珍しくありません。
  • 50種類以上のDBに接続する「ハブ」である:PostgreSQL、MySQL、Snowflake、BigQuery、MongoDB、Databricksなど、社内のデータ基盤へ次々つながります。つまり接続先すべての認証情報がMetabaseの中に保管されているという構造です。
  • 自社SaaSの中で動いていることもある:Metabaseは「埋め込み分析(Embedded Analytics)」を公式機能として提供しています。自社サービスの分析画面の裏側や、利用中のSaaSの内部で動いている可能性があります。

「うちはBIツールなんて入れていない」と即断せず、まずはTCP 3000番ポートで待ち受けているサーバがないか、Dockerイメージ metabase/metabase が動いていないかを確認してください。

この記事でわかること

  • CVE-2026-72898の中身と、なぜCVSSが最高値の10.0なのか
  • 影響を受けるバージョンと修正版の一覧(0.x系/1.x系の見方)
  • 自社に該当インスタンスがあるかの確認方法と、侵害されていたかの確認方法
  • パッチを当てただけでは終わらない理由(接続先DBの認証情報ローテーション)
  • 同じ8月11日にKEVへ追加された他2件との、対応期限の差が意味するもの

何が起きたのか

脆弱性の入口はパスワードリセット用のエンドポイント POST /api/session/reset_password です。ここは仕様上、パスワードを忘れた人が使うため認証を必要としません

問題は、このリクエストのボディに本来受け付けるはずのない項目(undeclared fields)を混ぜても弾かれなかったことです。混ぜ込まれた値が、ユーザ検索のために組み立てられるSQLへそのまま流れ込み、Metabase自身の設定を保持する「アプリケーションデータベース」に対して任意のSQLを実行できてしまいました(CWE-89)。

CVSSベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hネットワーク越し・低難度・認証不要・ユーザ操作不要で、スコープ変更(S:C)と機密性・完全性・可用性すべてHighが揃い、満点の10.0になっています。

なぜ「管理者奪取」で済まないのか

攻撃者はアプリケーションDBのレコードを書き換えて、Metabaseの管理者としてログインできる状態を作れます。ここまでで止まらないのが本件の怖いところで、管理者になれば以下が連鎖します。

  • 接続先データベースに保存された認証情報の窃取
  • その認証情報を使った、データウェアハウス本体への直接アクセス
  • ダッシュボード経由で参照できるデータの閲覧・エクスポート
  • 設定変更・アプリケーションシークレットの取得

つまり被害は「BIツールが1台乗っ取られた」ではなく、「そのBIツールがつないでいた全データ基盤に波及しうる」と読むのが正しい理解です。SQLインジェクションそのものの仕組みはSQLインジェクションとは?仕組みと情シスの対策を解説で整理しています。

影響を受けるバージョンと修正版

影響範囲は58系から63系までです。Metabaseはオープンソース版が 0.x、有償版(Pro/Enterprise)が 1.x というバージョン体系で、下2桁の系列番号は共通です。つまり 0.62.9 と 1.62.9 は同じ修正が入ります。

系列 修正版(これ以降にアップグレード)
63系 0.63.5 / 1.63.5
62系 0.62.9 / 1.62.9
61系 0.61.11 / 1.61.11
60系 0.60.17 / 1.60.17
59系 0.59.21 / 1.59.21
58系 0.58.24 / 1.58.24

Metabase Cloud(SaaS版)は提供元が自動で修正済みです。対応が必要なのはセルフホスト(自社サーバ・自社クラウド上で動かしている)インスタンスで、手動アップグレードが要ります。すぐに上げられない場合の暫定策として、公式はネットワーク側で該当エンドポイントをブロックすることを挙げています。

すでに悪用されている:公表された被害

本件は公表時点で「悪用済み」でした。セキュリティベンダーWizによると、2026年8月10日正午(UTC)時点で実証コード(PoC)が公開され、誰でも攻撃可能な状態になっています。

8月7日から10日にかけて、Metabase経由の侵害を公表した企業が相次ぎました。ノートPCメーカーのFramework、ワークフロー自動化のn8n、Tally、Anaconda傘下のKilo Code、監視サービスのChecklyHQなどです。n8nは8月8日、氏名とメールアドレスを含む顧客レコード136件が取得されたと公表しています。他社の公表内容では、ユーザ名・メールアドレスのほか、クラウドのパスワード、OpenTelemetryのAPIキーのハッシュ、Slackのアクセストークンなどが対象に含まれたと報じられています。

攻撃者から見た「露出」の規模も示されています。Wizの調査ではクラウド環境の約13%にセルフホストのMetabaseが存在し、そのうち約25%がインターネットから到達可能。Shodanでは約2,500インスタンスが観測されています。

自社に該当するか、どう確認するか

Metabaseは資産管理台帳に載っていないことが多いため、「台帳を見る」だけでは見つかりません。次の順で探すのが現実的です。

  1. ネットワークスキャン:デフォルトのTCP 3000番で待ち受けているホストを洗い出す。リバースプロキシ配下で80/443に出ている場合もあるため、HTTPレスポンスの内容も見る。
  2. コンテナ基盤の確認:Docker/Kubernetes上で metabase/metabase イメージが動いていないか。
  3. バージョン確認:見つかったインスタンスの /api/session/properties を参照すると、稼働中のバージョンが分かります。上の表と突き合わせてください。
  4. 外部公開の有無:社外から到達できるものを最優先。到達できるなら、修正版が当たるまでの間だけでもWAFやリバースプロキシで /api/session/reset_password を遮断します。

すでに侵入されていなかったか、どう確かめるか

Metabaseは、ログ上で確認すべきパターンを公式に示しています。POST /api/session/reset_password が400で失敗し、その直後に GET /api/user/current が200を返している組み合わせです。アプリケーションログ、あるいは前段のリバースプロキシ/イングレスのアクセスログで探してください。

あわせて、管理者アカウントの棚卸し——身に覚えのないアカウント作成、権限昇格、メールアドレス変更、パスワードリセットが無かったか——と、接続先データウェアハウス側のクエリ履歴の確認が推奨されています。侵害痕跡の確認手順の考え方はTeamCity脆弱性が悪用中、侵害痕跡の確認手順も参考になります。

パッチだけでは終わらない

本件で最も見落とされやすいのがここです。アップグレードした時点では、すでに抜かれた認証情報は有効なままです。公式が求めている事後対応は次のとおりです。

  • 有効なセッションをすべて失効させる
  • APIキーを監査し、不審なものを無効化する
  • 管理者アカウントの不正な変更を確認・是正する
  • 接続先データベースの認証情報をローテーションする
  • データウェアハウス側のログとクエリ履歴を確認する

この4番目が曲者です。接続先DBの認証情報変更は情シス単独では完結せず、各DBの管理者・アプリ担当・場合によっては業務部門との調整が必要になります。しかもMetabaseの接続設定を同時に更新しないとダッシュボードが一斉に止まるため、「変えれば終わり」ではありません。

現場目線の課題

正直なところ、この手の脆弱性で一番つらいのは技術的な難しさではなく、「そもそも自社にあるのか分からない」という点です。Metabaseは情シスが選定して導入した製品ではなく、データを見たい部署が自分たちで立てたものであることが多い。稟議も資産登録も通っていないので、脆弱性情報が出ても照合先の台帳に載っていません。

さらに厄介なのが、こうしたツールは「社内向けだから」という理由で認証やネットワーク制限が甘くなりがちなことです。外出先の営業から見たい、業務委託先にも見せたい——といった運用上の要請で、いつの間にかインターネットに面している。Wizが示した「セルフホストの約25%が外部到達可能」という数字は、決して他人事の割合ではないと感じます。

加えて今回はタイミングが悪い。KEVの期限は8月14日で、日本ではちょうど盆休みに入る頃です。担当者が休みに入る前に、せめて「外部公開されているMetabaseがあるかどうか」だけでも確認しておきたいところです。休暇期間の備えは夏季休暇のセキュリティ対策 盆休みと重なるパッチ火曜にまとめています。事業部門が立てた内製ツール基盤が盲点になる構図はAppsmithに保存型XSS、内製ツール基盤の盲点でも扱いました。

同じ日にKEVへ追加された他の2件

CISAは2026年8月11日、本件を含む3件をKEVへ追加しました。期限の差に注目すると、当局のリスク評価が読み取れます。

CVE 対象 内容 対応期限
CVE-2026-72898 Metabase 認証不要のSQLインジェクション 2026-08-14(3日)
CVE-2026-20349 Cisco Secure Firewall ASA/FTD 認証不要で機器を再起動させるDoS(CVSS 8.6) 2026-08-14(3日)
CVE-2026-68820 Windows AFD.sys(WinSock) 解放済みメモリ参照によるローカル権限昇格(CVSS 7.0) 2026-08-25(14日)

前2件が3日、Windowsが14日という差は、CISAの指令BOD 26-04が「インターネット露出/悪用の実態/自動化可能性/技術的影響」の4基準で期限を段階化していることに対応します。MetabaseとCiscoは外部から認証なしで叩けるのに対し、AFD.sysの権限昇格はまず端末上でコードを実行できていることが前提——この違いです。Cisco側は回避策が無く修正ソフトへの更新が必須(下記アドバイザリ参照)、Windows側は2026年8月の月例更新で修正済みで、内訳はMicrosoft月例パッチ751件、実質420件の見極め方で扱っています。

なお、日本の民間企業にKEVの期限を守る法的義務はありません。ただし「認証不要・外部到達可能・悪用中」の3条件が揃った脆弱性に当局が3日しか猶予を見ていないという事実は、自社の優先順位付けの物差しとして使えます。

情シスはどうすべきか

個別の手順を並べるより、公的機関の指針に沿って自社の「基準」を整えるほうが長続きします。

資産の把握からパッチ適用までを回す仕組みそのものについては脆弱性管理とは?プロセスと情シスの進め方を解説を参照してください。

まとめ

  • CVE-2026-72898はCVSS 10.0、認証不要でMetabaseの管理者権限を奪われる。58系〜63系が対象で、修正版は0.63.5/0.62.9/0.61.11/0.60.17/0.59.21/0.58.24(1.x系も同番号)。Metabase Cloudは対応済み、セルフホストは手動対応が必要です。
  • 被害はMetabase単体では止まらない。接続先DBの認証情報が保管されているため、パッチ適用後もセッション失効・APIキー監査・接続先DBの認証情報ローテーションまでやり切る必要があります。
  • まず「自社にあるか」を探すところから。TCP 3000番、metabase/metabase イメージ、/api/session/properties の3点で洗い出し、外部公開されているものから着手してください。CISAの対応期限は8月14日です。

出典

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