CVE-2026-72898｜Metabase の影響判定と侵害確認の手順

はじめに

2026 年 8 月 6 日、Metabase が自社のセキュリティインシデントを公表しました。未知の脆弱性を利用した攻撃を Metabase Cloud で確認し、攻撃に使われたエンドポイントを遮断したうえで、脆弱性を特定して修正したという内容です。この脆弱性には CVE-2026-72898 が採番され、8 月 11 日には米国 CISA の Known Exploited Vulnerabilities（KEV）カタログにも登録されました。

Metabase Cloud はベンダー側で対応済みですが、セルフホストで運用している環境は利用者側での対応が必要になります。社内向けの BI ツールという位置づけから、脆弱性スキャナーの検出結果や取引先からの照会を受けて、自環境が対象かどうかの切り分けを求められている方も多いと思われます。

結論から述べます。CVE-2026-72898 は認証を必要としない SQL インジェクションで、実際の悪用が確認されています。影響を受けるのは Metabase 58 系から 63 系のうち、各系列について 8 月 6 日時点で公開された初期修正版より前のバージョンです。58 未満のバージョンは影響を受けません。 そして本件で重要なのは、修正版への更新だけでは対応が完結しない場合があるという点です。攻撃が成功した場合、攻撃者は Metabase に保存された接続先データベースの認証情報にも到達しうるため、該当エンドポイントがインターネットから到達可能だった環境では、更新に加えて侵害の有無の確認と認証情報の対応まで含めて検討することが求められます。

CVE-2026-72898 の概要と影響

本脆弱性は、認証前に呼び出せるパスワードリセット用のエンドポイントを経由して、Metabase 自身の Application Database に対して任意の SQL を注入できるというものです。ここでは、脆弱性の性質と、悪用された場合に想定される影響の範囲を整理します。

項目	内容
CVE ID	CVE-2026-72898
GitHub Security Advisory	GHSA-vwf4-m7j8-wcjf
対象製品	Metabase（セルフホスト、OSS 版および Enterprise 版）
脆弱性種別	CWE-89（SQL インジェクション）
CVSS v3.1	10.0（Critical）AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS v4.0	10.0（Critical）
影響するバージョン	58 系から 63 系のうち、各系列の初期修正版（8 月 6 日公開）より前のバージョン
影響しないバージョン	58 未満
公表日	2026 年 8 月 6 日
悪用状況	Metabase が実際の悪用を確認済み
CISA KEV 登録日	2026 年 8 月 11 日（Due Date: 2026 年 8 月 14 日）

CVSS v3.1 のベクターでは、PR:N と UI:N により、認証も利用者の操作も必要としないことが示されています。攻撃条件の面でのハードルが低いことが、この採点に表れています。

認証前の処理から Application Database へ到達した経緯

SQL インジェクションの一般論には立ち入らず、なぜ認証前の処理からアプリケーションのデータベースへ不正な入力が届いたのかに絞って整理します。

セキュリティ企業 Bishop Fox が公開した技術分析によると、根本原因はパスワードリセット要求のリクエストボディにおいて、本来想定していないフィールドが制限されていなかった点にあります。

参考: Critical SQL Injection in Metabase via Password Reset: CVE-2026-72898（Bishop Fox）
“a failure to restrict undeclared fields in the password-reset request body”
（パスワードリセット要求のボディにおいて、宣言されていないフィールドを制限できていなかったこと）
https://bishopfox.com/blog/critical-sql-injection-in-metabase-via-password-reset-cve-2026-72898

同分析によれば、影響を受けるバージョンでは、この想定外の値が、検証済みの識別子としてではなく構造を持った入力として Application Database のユーザー検索処理へ渡されていました。Metabase のクエリー構築の仕組みがその入力を SQL の式として解釈しうるため、パスワードリセット処理が発行するクエリーに SQL が混入する余地が生じたと説明されています。修正は、パスワードリセット処理が受け付ける入力を想定されたものだけに厳密に限定し、宣言されていないフィールドがクエリーに影響しないようにするものです。

なお、本記事では攻撃に使用される具体的なリクエスト内容や実証コードは扱いません。目的は防御と影響確認、およびインシデント対応に置いています。

管理者権限取得後に想定される影響

Metabase 公式ブログは、攻撃者がインスタンスへアクセスしたあとに想定される影響として、Application Database に対する任意の SQL の注入と、それによるインスタンスの管理者アクセスの取得を挙げています。そのうえで、管理者アクセスを取得した攻撃者に想定される行為として、次の内容を示しています。

• アプリケーション設定の変更
• 接続先データベース向けに保存された認証情報の窃取
• それらの接続を通じて参照できるデータの読み取り
• データのエクスポート

参照元: https://www.metabase.com/blog/security-update

この 4 点目までを含む点が、本脆弱性を Metabase 単体の問題として扱えない理由です。 Metabase は BI ツールという性質上、分析対象となるデータウェアハウスや業務データベースへの接続情報を保持しています。管理者権限を取得されると、影響は Metabase のインスタンス内に閉じず、接続先として登録しているデータストア側へ波及しうることになります。

したがって、対応を検討する際は「Metabase を更新したか」だけでなく、「その Metabase が何に接続しているか」を同時に棚卸ししておくことを推奨します。接続先の一覧は、後の工程で認証情報のローテーション対象を洗い出す際にそのまま使えます。

CISA KEV への登録と SSVC 判定

米国 CISA は、2026 年 8 月 11 日付で本脆弱性を KEV カタログへ追加しました。登録名は「Metabase SQL Injection Vulnerability」で、対応期限（Due Date）は 2026 年 8 月 14 日、追加から 3 日間という設定です。

KEV エントリの Required action には、ベンダーの指示に従った緩和策の適用に加えて、BOD 26-04 への準拠、緩和策が利用できない場合の製品使用の停止が挙げられています。さらに、次の記述が含まれています。

参考: CISA Known Exploited Vulnerabilities Catalog（CVE-2026-72898 エントリ）
“Stakeholders are responsible for evaluating each asset’s internet exposure”
（関係者は各資産のインターネットへの露出を評価する責任を負う）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-72898

この Due Date は、米国の連邦文民行政機関（FCEB）を対象とする BOD 26-04 上の期限であり、日本国内の民間企業に直接の拘束力を持つものではありません。 ただし、追加日から 3 日という設定は、CISA が即時の対応を要する状況と判断したことを示す材料として参考になります。

判断材料をもう 1 つ挙げると、CVE レコードの CISA-ADP コンテナに記録された SSVC の評価があります。本脆弱性では次の 3 項目が確定しています。

• Exploitation: active（実環境での悪用が進行中）
• Automatable: yes（攻撃工程を自動化しうる）
• Technical Impact: total（対象システムの制御を全面的に奪いうる）

Automatable: yes は、探索から攻撃までの工程を自動化しうると評価されたことを示します。インターネットに公開していた環境では、自組織が特定の標的であったかどうかにかかわらず、到達されていた可能性を前提に確認を進めることを推奨します。

自環境が影響を受けるかを判定する

対応の要否は、次の 3 点を順に確認することで判定できます。実行環境の種別、稼働しているバージョン、そして該当エンドポイントが外部から到達可能な状態だったかどうかです。3 点目は更新の要否そのものには影響しませんが、更新後に追加の対応が必要になるかどうかを分ける基準になります。

Metabase Cloud とセルフホストの切り分け

最初に確認すべきは、Metabase Cloud を利用しているか、自組織でホストしているかです。Metabase 公式ブログによれば、Metabase Cloud のインスタンスはベンダー側ですでにアップグレードとパッチ適用が完了しています。Cloud 利用者が自ら更新作業を行う必要はありません。

一方、セルフホストの環境は利用者側での対応が必要です。ここでいうセルフホストには、次のような形態が含まれます。

• JAR ファイルを直接実行している環境
• 公式 Docker イメージ（metabase/metabase、metabase/metabase-enterprise）で稼働している環境
• クラウドのコンテナサービスやマネージドな実行基盤上で公式イメージを動かしている環境
• 社内の検証用途で一時的に起動したまま残っている環境

注意したいのは 4 点目です。BI ツールは検証目的で立ち上げられたまま台帳に載っていないことがあり、資産管理の対象から漏れやすい傾向があります。本脆弱性への対応にあたっては、正式に運用しているインスタンスだけでなく、コンテナ基盤上に残っているイメージの稼働状況もあわせて確認することを推奨します。

CVE-2026-72898 の初期修正版によるバージョン判定

判定の基準は、各系列について 8 月 6 日に公開された初期修正版です。稼働中のバージョンがこれより前であれば、CVE-2026-72898 の影響を受けます。 そして 58 未満のバージョンは、本脆弱性の影響を受けません。

系列	初期修正版（2026 年 8 月 6 日公開）	判定
63 系	0.63.5	0.63.5 より前は影響あり
62 系	0.62.9	0.62.9 より前は影響あり
61 系	0.61.11	0.61.11 より前は影響あり
60 系	0.60.17	0.60.17 より前は影響あり
59 系	0.59.21	0.59.21 より前は影響あり
58 系	0.58.24	0.58.24 より前は影響あり
58 未満	—	影響なし

この一覧は CISA が公開している CSAF 形式のアドバイザリでも同じ値が示されています。

参考: Metabase SQL injection（CISA Vulnerability Advisory VA-26-222-01）
“Fixed in v58.24, v59.21, v60.17, v61.11, v62.9 and v63.5.”
（v58.24、v59.21、v60.17、v61.11、v62.9、v63.5 で修正済み）
https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-222-01.json

稼働中のバージョンは、画面右上の歯車アイコンまたはグリッドアイコンから「About Metabase」を選択することで確認できます。バージョンによっては「Help」の配下に配置されています。Docker で運用している場合は、実行中のコンテナのイメージタグを確認する方法もあります。ただし latest タグで運用している環境では、タグの表記から実際のポイントリリース番号を判別できないため、画面上の表示で確認することを推奨します。

判定にあたっての注意点

GitHub Security Advisory（GHSA-vwf4-m7j8-wcjf）の「Affected versions」欄には、x.58.0 以上 x.58.23 未満、x.63.0 以上 x.63.3 未満といった範囲が記載されています。一方で同じアドバイザリの「Patched versions」欄には x.58.24、x.63.5 が示されており、影響範囲の上限と修正版の間に連続しない部分があります。

この表記を文字どおりに読むと、たとえば 0.63.4 が影響範囲から外れているように見えます。しかし CVE レコード（CNA は CISA）に記録されている affected は x.63.0 <= v < x.63.5 のように修正版と連続した範囲であり、CISA の CSAF アドバイザリおよび Metabase 公式ブログの案内とも整合します。

OSS 版と Enterprise 版のバージョン表記

Metabase のバージョン番号は、先頭の数字がエディションを表します。

• 0.x: OSS 版（Metabase Open Source）
• 1.x: Enterprise 版（Metabase Enterprise Edition、Pro および Enterprise プラン）

GitHub Security Advisory では、この先頭の数字を x に置き換えた x.58.0 のような表記が使われており、修正版のダウンロードリンクは OSS 版（0.63.5 等）と Enterprise 版（1.63.5 等）に分けて提供されています。

つまり、メジャー番号とポイントリリース番号は両エディションで共通であり、判定の際は先頭の 0. または 1. を除いた部分を上表と照合すれば足ります。 Enterprise 版で 1.62.5 が稼働している場合は、62 系の初期修正版 0.62.9 に対応する 1.62.9 に達していないため、影響対象と判定します。

自環境のエディションが判別しにくい場合は、バージョン表示の先頭が 0 か 1 かを確認するほか、Docker イメージ名が metabase/metabase か metabase/metabase-enterprise かでも切り分けられます。

/api/session/reset_password が外部から到達可能だったか

3 つ目の確認項目は、影響するエンドポイントがインターネットから到達可能な状態だったかどうかです。これは更新の要否を左右するものではなく、更新後に侵害確認と認証情報の対応まで行うかどうかを判断するための基準になります。

確認にあたって、稼働中のインスタンスに対して該当エンドポイントへリクエストを送るテストは推奨しません。 未更新の環境では、そのリクエスト自体が脆弱な処理を通過することになります。また、テストの結果として発生したログが、後の侵害確認において攻撃の痕跡と区別しにくくなる可能性もあります。判定は、稼働中のシステムに手を加えず、次の 3 つの材料から行うことを推奨します。

1. 経路上の設定を確認する

Metabase の前段に置いている構成要素の設定から、当該パスが外部に開いていたかを判断します。

• Kubernetes の Ingress: ホスト名とパスのルーティング規則、/api 配下を含む転送設定の有無
• リバースプロキシ: バーチャルホストの設定と location の定義、パス単位の制限の有無
• ロードバランサー: リスナーとターゲットグループ、パスベースのルーティング規則
• WAF: 特定パスに対する遮断ルールの有無と、その適用開始日

2. ネットワーク境界の設定を確認する

経路上のアプリケーション層の設定に加えて、そもそも外部から到達しうる構成だったかを確認します。

• セキュリティグループやファイアウォールポリシーで、Metabase の待ち受けポートに対する送信元の制限があったか
• VPN や ZTNA、IP 許可リストによるアクセス制限が有効だったか

なお、公開 DNS レコードの有無や、証明書の発行対象に該当ホスト名が含まれているかは、外部から到達可能だったことを直接証明するものではありません。名前解決ができても経路上で遮断されている構成はあり得ます。これらは、記録が残っていない過去の期間について外部公開の可能性を調べるための補助材料として扱うことを推奨します。

3. 既存のアクセスログを確認する

設定上の判断を、実際の通信記録で裏付けます。リバースプロキシや Ingress のアクセスログに、社内ネットワーク以外の送信元から /api/ 配下へのリクエストが記録されているかを確認します。この段階では攻撃の痕跡を探すのではなく、外部からの到達実績があったかどうかだけを見ます。具体的な攻撃パターンの確認は、後述する侵害確認のセクションで扱います。

どの期間の設定を確認するか

ここで重要なのは、現在の設定だけでなく、過去に外部から到達可能だった期間があったかを確認するという点です。Metabase は本脆弱性が 0-day として悪用されていたことを公表していますが、悪用がいつ始まったかについては公表していません。したがって、確認の起点となる日付を特定することはできません。

実務上は、次のように整理することを推奨します。

• 確認は、アクセスログや構成管理の記録が残っている保持期間まで遡って行う
• 少なくとも公表（8 月 6 日）より前に外部から到達可能だった環境は、過去の到達可能性を考慮に入れる
• 公表後に遮断した場合は、その遮断が有効になった日時を記録しておく
• 保持期間の制約で確認しきれない期間がある場合は、その期間を「不明」として扱い、公開されていた前提で確認を進める

該当エンドポイントが外部から到達可能だった環境では、更新の完了後に侵害の有無の確認と、接続先データベースの認証情報を含む対応まで検討することが求められます。 その具体的な内容は記事後半で扱います。

Metabase 公式が案内している更新後の追加対応は、/api/session/reset_password エンドポイントが publicly accessible だった環境を対象としたものです。外部からの到達経路が確認できない環境では、この追加対応が公式の案内する適用条件には該当しないことになります。

ただし、本脆弱性は認証を必要としないため、社内ネットワーク内の端末が侵害されていた場合や、VPN 経由で到達しうる範囲に攻撃者が存在した場合には、別経路での悪用が成立する可能性が残ります。非公開環境であっても、内部からの到達経路と、そこに至るリスクの有無を踏まえて、追加の確認を行うかどうかを検討することを推奨します。 判断がつかない場合は、後述する侵害確認のログ点検までは実施しておくと、後から状況を説明する際の材料になります。

更新先の基準と、更新できない場合の暫定回避策

CVE-2026-72898 への対応で注意したいのは、Metabase が 8 月 6 日以降にもう一度リリースを行っている点です。影響判定に使う基準と、実際の更新先とする基準は別のものになります。

8 月 6 日の初期修正版と 8 月 12 日の最低安全リリース

2026 年 8 月 12 日、Metabase は「Security-focused Metabase Release Announcement」として、新たなリリース群を公開しました。

参考: Security-focused Metabase Release Announcement（Metabase 公式ブログ）
“hardening our api and fixing issues that are derivatives of the vulnerability”
（API のハードニングと、当該脆弱性から派生する問題の修正）
https://www.metabase.com/blog/security-focused-release-announcement-2026-08-12

同ブログでは、このリリースが複数のセキュリティ改善を含むものであり、直ちにアップグレードすることを強く推奨するとしています。また、この更新の大部分が Metabase 自身のセキュリティリサーチの成果によるものであることも示されています。あわせて、次期リリースを見送り、当面はセキュリティと可観測性を中心とした週次のマイナーリリースに注力する方針も表明されています。

8 月 12 日時点で示されている最低安全リリースは次のとおりです。

系列	初期修正版（8 月 6 日）	最低安全リリース（8 月 12 日）
63 系	0.63.5	0.63.10
62 系	0.62.9	0.62.13
61 系	0.61.11	0.61.15
60 系	0.60.17	0.60.21
59 系	0.59.21	0.59.25
58 系	0.58.24	0.58.28

なお、8 月 12 日のリリース告知で一覧に挙げられているのは OSS 版（0.x）のバージョンです。Enterprise 版（1.x）を利用している場合は、対応するポイントリリース番号の提供状況を Metabase のリリース情報で確認することを推奨します。

実務上の更新先をどちらに置くか

2 つの基準は、次のように使い分けます。

• 影響判定: 8 月 6 日の初期修正版を基準とする。これより前のバージョンが CVE-2026-72898 の影響対象
• 更新先: 8 月 12 日の最低安全リリース、またはそれ以降のポイントリリースを基準とする

すでに 8 月 6 日の初期修正版へ更新済みの環境も、更新対象から外れるわけではありません。 8 月 12 日のリリースは追加のセキュリティ改善と、当該脆弱性から派生する問題の修正を含むものであり、Metabase は最新のポイントリリースへ更新することを強く推奨しています。初期修正版で対応を完了したと整理している場合は、更新計画を見直すことを推奨します。

また、Metabase が当面は週次でセキュリティ中心のマイナーリリースを行う方針を示している以上、本記事に記載した 8 月 12 日時点のバージョン番号は、時間の経過とともに最新ではなくなります。 実際の作業にあたっては、Metabase 公式のリリース情報で、稼働している系列の最新ポイントリリースを確認したうえで更新先を決めることを推奨します。

更新作業そのものの手順は、JAR 実行、Docker、コンテナ基盤といった運用形態によって異なります。いずれの形態でも、更新前に Application Database のバックアップを取得しておくことを推奨します。本脆弱性への対応では、更新後に core_session テーブルの操作を伴う場合があるため、バックアップの取得は後続の作業を進めるうえでも意味を持ちます。

/api/session/reset_password の一時的な遮断

更新の実施が難しい場合の暫定的な対応として、Metabase は該当エンドポイントの遮断を案内しています。直ちにアップグレードできない場合の一時的な回避策として、/api/session/reset_password エンドポイントを遮断するという内容です。

参照元: https://www.metabase.com/blog/security-update

Metabase が公開している情報は、この「該当エンドポイントを遮断する」という方針までです。リバースプロキシや WAF、ロードバランサーに対する具体的な設定例は、公式からは提供されていません。 本記事でも、公式で確認できない設定例は記載しません。遮断ルールを実装する場合は、自環境の構成に合わせて設計し、検証環境で挙動を確認したうえで適用することを推奨します。

実装にあたっては、次の点を考慮する必要があります。

遮断は更新の代替ではありません

公式の案内はあくまで直ちに更新できない場合の一時的な措置であり、更新までの猶予を作るためのものです

パスワードリセット機能が利用できなくなります

該当エンドポイントを遮断すると、利用者によるパスワードの再設定が行えなくなります。適用にあたっては、管理者による代替手段を用意しておくことを推奨します

遮断を適用した日時を記録しておきます

後の侵害確認において、遮断が有効になる前の期間をどう扱うかの判断材料になります

オリジンへの直接接続経路が残っていないか確認します

前段で遮断していても、コンテナやインスタンスへ直接到達できる経路が開いていれば、遮断を経由しない到達が成立します

遮断を適用した場合も、対応が完了したとは扱わず、更新の計画を並行して進めることを推奨します。

すでに悪用されていないかを確認する

更新と暫定対応が整理できたら、次は悪用の痕跡の確認です。この工程は、更新作業とは目的が異なります。 更新は今後の悪用を防ぐためのものであり、ここで扱うのは、更新より前の時点ですでに悪用されていなかったかを確認するためのものです。実際の悪用が確認されている脆弱性である以上、両者は分けて扱う必要があります。

ログに現れる攻撃パターン

Metabase 公式ブログは、確認すべき攻撃のパターンとして、次の 2 つのリクエストが連続して記録されるという特徴を示しています。

1. POST /api/session/reset_password へのリクエストで、ステータスコードが 400
2. これに続く GET /api/user/current へのリクエストで、ステータスコードが 200

このパターンがアプリケーションログまたは Metabase サーバーの ingress ログに存在する場合について、公式は次のように述べています。

参考: Security update available for Metabase – Please upgrade now（Metabase 公式ブログ）
“it is likely that your instance has been compromised”
（そのインスタンスは侵害されている可能性が高い）
https://www.metabase.com/blog/security-update

パターンの構造を補足すると、1 つ目のリクエストはエラー応答（400）を返していながら、直後の 2 つ目のリクエストでは認証済みの利用者情報を取得する API が成功応答（200）を返しています。ステータスコード 400 だけを見て「失敗したリクエスト」として読み飛ばさないことが、この確認における要点になります。 アクセスログの点検では 4xx や 5xx を除外して 2xx のみを追うこともありますが、本件ではこの組み合わせ自体が指標となります。

公式が示している判定の軸は、POST /api/session/reset_password の 400 に続いて GET /api/user/current の 200 が記録されているという連続そのものです。送信元 IP アドレスや時刻は、該当する記録を見つけたあとに前後の通信を追う際の補助材料として扱うことを推奨します。

確認対象となるログの種類と保持期間

公式が挙げているのは、アプリケーションログと Metabase サーバーの ingress ログです。実際の環境では、次のような箇所に記録が残っている可能性があります。

• Metabase 自身が出力するアプリケーションログ
• Kubernetes 環境の Ingress Controller のアクセスログ
• リバースプロキシのアクセスログ
• ロードバランサーのアクセスログ（有効化している場合）
• WAF のログ
• CDN のログ（前段に配置している場合）

確認を始める前に、それぞれの保持期間を把握しておくことを推奨します。 前述のとおり、悪用がいつ始まったかは公表されていないため、確認できる範囲はログの保持期間によって決まります。ロードバランサーのアクセスログは既定では無効になっている構成もあり、その場合はその経路での確認自体が成立しません。

また、確認作業に着手する前に、対象期間のログを別の場所へ退避しておくことを推奨します。ローテーションによって、確認の途中で対象期間の記録が失われる可能性があるためです。

パターンが見つからなかった場合の解釈

ここが、本件の確認において判断を要する部分です。

パターンが記録されていないことは、侵害されていないことの証明にはなりません。 理由は 3 つあります。

1. 確認できるのはログの保持期間内に限られます

悪用の開始時期が公表されていない以上、保持期間より前に何が起きていたかは、記録がない限り判断できません

2. 確認対象の経路にログが残っていない可能性があります

アクセスログを有効化していない構成要素が経路上に存在する場合、その経路を通った通信は記録されません

3. 示されているパターンは、Metabase が確認した攻撃の特徴として公開されたものです

公式は、これがすべての悪用を網羅する検知条件であるとは説明していません。不検出という結果だけで侵害を否定することはできません

実務上は、次のように整理すると扱いやすくなります。

パターンが見つかった

侵害された可能性が高いものとして扱う。更新後の追加対応を実施し、インシデント対応の手順に移行する

パターンが見つからず、ログの保持期間が十分に長い

確認した期間内にこの経路での悪用の痕跡はなかったものとして扱う。ただし、確認できた期間を明記しておく

パターンが見つからず、ログの保持期間が短い、または経路上に記録のない箇所がある

判断材料が不足している状態として扱う。外部から到達可能だった環境では、侵害の可能性を否定できないものとして、更新後の追加対応を実施することを検討する

そもそも該当するログが存在しない

上記と同様に、判断材料が不足している状態として扱う

確認の結果を記録する際は、「侵害の痕跡は確認されなかった」ではなく、「どの経路のログを、どの期間について確認し、痕跡が見つからなかった」という形で残すことを推奨します。 確認した範囲を明示しておくことで、後から報告を求められた際に、判断の根拠と限界を示せます。

なお、ここまでの整理のうち、公式が示しているのは攻撃パターンとその解釈（パターンが存在する場合は侵害された可能性が高い）までです。パターンが見つからなかった場合の扱いについては公式の言及がないため、本記事における整理として提示しています。

公開されていた環境で更新後に行うこと

ここまでの工程で、更新と悪用痕跡の確認までが整理できました。最後に扱うのは、/api/session/reset_password が外部から到達可能だった環境における、更新後の対応です。

対応の前提と実施の順序

Metabase 公式が案内している 6 項目は、該当エンドポイントが publicly accessible だった環境を対象とし、更新を完了したあとに実施するものとして示されています。更新前に認証情報のローテーションだけを行っても、脆弱性が残っている以上、再度取得される可能性があります。更新が先、認証情報の対応が後という順序を守ることを推奨します。

対応の全体像は次のとおりです。

1. 有効な利用者セッションの失効
2. API キーの確認と、認識できないキーの削除
3. 管理者アカウントに想定外の変更がないかの確認
4. 接続先データベースの認証情報のローテーション
5. Data Warehouse のログにおける不正アクセスの兆候の確認
6. Metabase の操作履歴とクエリー履歴の確認

このうち 1 から 4 は、攻撃者が取得した可能性のあるアクセス手段を無効化するための作業です。5 と 6 は、実際に何が行われたかを確認するための作業です。先に 1 から 4 を実施してアクセス経路を塞ぎ、そのうえで 5 と 6 の確認を進める順序を推奨します。

セッションの失効と API キーの確認

第 1 の項目は、有効な利用者セッションの失効です。Metabase 公式は、Application Database にアクセスして core_session テーブルの全行を削除する方法を案内しています。攻撃者がセッションを保持していた場合、それを無効化することが目的です。

実施にあたっては、次の点に留意します。

• 全利用者が強制的にログアウトされます。業務時間帯を避けるなど、実施のタイミングを調整することを推奨します
• 作業前に Application Database のバックアップを取得しておくことを推奨します
• SSO を利用している環境では、Metabase 側のセッション失効と、ID プロバイダー側のセッションの扱いが別になります。必要に応じて ID プロバイダー側の対応も検討します

第 2 の項目は API キーの確認です。管理画面から発行済みの API キーを一覧し、発行の経緯を説明できないキーがないかを確認します。認識できないキーが存在する場合、それは削除の対象になります。 併せて、正規に発行したキーについても、この機会にローテーションを検討する価値があります。

管理者アカウントの変更確認

第 3 の項目は、管理者アカウントに想定外の変更がないかの確認です。SQL インジェクションによって Application Database を直接操作された場合、利用者テーブルの内容が変更されている可能性があります。

確認する観点は次のとおりです。

• 管理者権限を持つアカウントの一覧に、把握していないアカウントが含まれていないか
• 既存の利用者アカウントのうち、管理者権限が付与された覚えのないものがないか
• 無効化したはずのアカウントが有効な状態に戻っていないか
• アカウントに紐づくメールアドレスが変更されていないか

メールアドレスの変更は見落としやすい項目です。パスワードリセットの通知先が変更されていると、正規の手順で認証情報を再取得される余地が残ります。

接続先データベース認証情報のローテーション

第 4 の項目が、本脆弱性への対応において負荷の大きい部分です。Metabase 公式は、接続先データベース向けの認証情報をローテーションすることを案内しています。

前述のとおり、管理者アクセスを取得された場合、Metabase に保存された接続先データベースの認証情報が窃取される可能性があります。対象となるのは、Metabase の管理画面に登録しているデータベース接続のすべてです。 対応にあたっては、次の手順で進めることを推奨します。

1. Metabase の管理画面から、登録されているデータベース接続を一覧化する
2. 各接続で使用しているアカウントを特定する
3. 接続先ごとに認証情報を再発行する
4. Metabase の接続設定を新しい認証情報へ更新し、接続テストを行う
5. 旧認証情報を無効化する

ここで注意したいのは、同じアカウントを Metabase 以外のシステムからも使用している場合です。バッチ処理や他の分析ツールが同一のアカウントを共有していると、ローテーションの影響がそれらにも及びます。作業前に、対象アカウントの利用箇所を確認することを推奨します。

また、データベース接続以外にも、Metabase が保持している認証情報が存在する場合があります。SMTP の設定、LDAP や SAML の連携設定などが該当します。公式が挙げているのは接続先データベースの認証情報ですが、インスタンスの設定に保存されている認証情報については、その範囲を自環境で棚卸ししたうえで対応方針を決めることを推奨します。

Data Warehouse ログと Metabase の操作履歴の確認

第 5 と第 6 の項目は、実際にデータへアクセスされた形跡がないかの確認です。

Data Warehouse 側では、Metabase の接続に使用しているアカウントによるクエリーの実行履歴を確認します。着眼点は次のとおりです。

• Metabase 経由の通常の利用では発生しないパターンのクエリーがないか
• 業務時間外や、ダッシュボードの更新スケジュールと無関係な時間帯の実行がないか
• 大量のレコードを取得するクエリーや、エクスポートを伴う操作がないか
• 通常は参照していないテーブルやスキーマへのアクセスがないか

Metabase 側では、管理画面から確認できる操作履歴とクエリー履歴を対象とします。ダウンロードやエクスポートの実行記録、権限設定の変更、ダッシュボードやコレクションへの想定外の操作が含まれていないかを確認します。

これらの確認においても、ログの保持期間が判断できる範囲を規定します。 前章と同様に、確認した対象と期間を記録として残しておくことを推奨します。個人情報を含むデータへのアクセスが確認された場合は、社内の報告体制および関係法令に基づく対応の要否を、法務や個人情報保護の担当部門と検討することになります。

なお、これら 6 項目の実施状況と結果は、時系列で記録しておくことを推奨します。実悪用が確認されている脆弱性であるため、後日、取引先や監査で説明を求められる可能性があります。「どの作業をいつ完了したか」「どの範囲を確認して何が見つからなかったか」を残しておくことで、対応の内容を客観的に示せます。

まとめ

CVE-2026-72898 は、認証を必要とせずに Metabase の Application Database へ SQL を注入できる脆弱性で、実際の悪用が確認されています。影響を受けるのはセルフホスト環境であり、Metabase Cloud はベンダー側で対応済みです。修正版への更新で今後の悪用は防げますが、該当エンドポイントが外部から到達可能だった環境では、侵害の有無の確認と、接続先データベースを含む認証情報の対応まで検討することが求められます。

• 58 未満は影響なし、58 から 63 系は各系列の初期修正版を基準に判定
• 影響判定は 8 月 6 日版、更新先は 8 月 12 日以降の最新ポイントリリース
• OSS 版と Enterprise 版はポイントリリース番号が共通
• 外部到達性は設定・ネットワーク境界・既存ログの 3 方向から判断
• 侵害確認は 400 の直後に 200 が続く連続を軸にログを点検
• 不検出は侵害の否定にならず、確認した経路と期間の記録が要点
• 公開環境では更新後にセッション失効と接続先認証情報のローテーション

以上、最後までお読みいただきありがとうございました。