Metabaseの脆弱性CVE-2026-72898とは？更新すべき版と侵害調査のSQL・ログ確認手順

Metabaseが2026年8月6日に公表したCVE-2026-72898は、認証なしで /api/session/reset_password に細工したリクエストを送るだけで、アプリケーションDBへ任意のSQLを注入し、管理者権限まで奪える脆弱性です。CVSSは10.0で、Metabase自身がゼロデイでの悪用を確認しました。この記事では、セルフホスト版の管理者に向けて、どの版まで上げればよいか、同じ日に出たもう1件の脆弱性と5日後の後続アドバイザリの扱い、Docker版の更新コマンド、アクセスログとアプリケーションDBから侵害の痕跡を探すSQLまでを順に示します。記載は2026年10月23日時点の公開情報にもとづきます。

まとめ：CVE-2026-72898は修正版でなく8月11日の強化版まで上げて痕跡を確認

CVE-2026-72898を塞ぐ最低限の版は、58系なら x.58.24、63系なら x.63.5 です。ただしMetabaseは8月11日に後続のアドバイザリを出し、SQLインジェクション対策の強化やパスワードリセットのレート制限の抜け道を塞いだ版（58系なら x.58.28）を案内しています。いま更新するなら、この強化版を目標にしてください。

更新だけでは終わりません。reset_password がインターネットから届く状態で運用していたなら、更新後にセッションの失効、APIキーと管理者アカウントの確認、接続先DBの認証情報の入れ替えまでが対応範囲です。JPCERT/CCは10月の注意喚起で、国内でこの脆弱性が悪用された事案と送信元IPアドレスを公表しています。

もう1つの注意点は、reset_password の遮断が回避策になるのはCVE-2026-72898だけ、という点です。同日公表のCVE-2026-72899は公開共有したダッシュボードから攻撃でき、遮断では防げません。

CVE-2026-72898とreset_passwordの管理者権限奪取経路

Metabaseは社内のDBにつないでSQLやGUIで集計・可視化するオープンソースのBIツールで、構成やエディションの違いはMetabaseの構成とエディション差で解説しています。今回の欠陥は、そのMetabase自身の設定を保存するアプリケーションDBに向けたSQLインジェクションです。

CVSS 10.0・CWE-89の評価と認証不要でアプリケーションDBに届く条件

NVDのCVE-2026-72898には、CVSS v3.1で10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）、CVSS v4.0でも10.0が登録されています。弱点の分類はCWE-89（SQLインジェクション）です。スコープが「変更あり（S:C）」になっているのは、Metabaseが乗っ取られると、その先につながる分析対象のDBまで影響が及ぶためです。スコアの各項目の読み方はCVSSv3の評価基準と計算式にまとめています。

Metabaseのアドバイザリ GHSA-vwf4-m7j8-wcjfによれば、管理者になった攻撃者は設定の変更、接続先DBの保存済み認証情報の窃取、その接続で読めるデータの読み出しと書き出しができます。条件はパスワードリセットのエンドポイントに到達できることだけで、ログインもユーザー操作も要りません。

merge・JSONキーワード化・HoneySQLの:rawが重なった根本原因

Metabaseは修正をリリース版でのみ配布し、詳細を公表していません。原因を具体的に示しているのは、修正前後のJARを比較して逆解析したWizの解析記事です。それによると、3つの挙動が重なっていました。

1. リクエストと認証結果をClojureの merge で結合しており、認証に失敗すると結果に user-id が含まれず、リクエスト側に入れた値がそのまま残る。
2. JSONのキーがClojureのキーワードに変換されるため、本文に入れた入れ子のオブジェクトがそのままマップとして渡る。
3. SQL生成ライブラリHoneySQLの :raw 指定は文字列をパラメータ化せずSQLへ埋め込む機能で、そのマップが利用者検索のクエリに届くとSQLとして解釈される。

本来 reset_password が受け取るのは token と password だけで、user-id は想定外のキーでした。修正版では user-id が正の整数かを確かめてから問い合わせる形になっています。Wizは、58系で認証まわりのモジュールを作り直した際に入り込んだと分析しています。SQLインジェクション一般の仕組みはSQLインジェクションの攻撃例と対策で扱っていますが、今回は「文字列連結を避けていても、ライブラリの生SQL機能に外部の値が届けば同じことが起きる」という例です。

2026年8月の公表からKEV登録・JPCERT/CC注意喚起2本までの時系列

公表から国内の悪用報告までは、約2か月でした。

Metabaseの公式ブログでは、最初に狙われたのはMetabase Cloudで、未知の脆弱性として使われたと説明しています。CISAのKEVカタログへの登録は8月11日、対応期限は8月14日でした。Wizは8月10日の時点で攻撃コードが公開されていると報告しており、攻撃コードが出回った後の脆弱性がどう扱われるかはexploitの仕組みと防御で整理しています。

Metabaseの影響版と同日公表のCVE-2026-72899・後続修正版

Metabaseの版は先頭の数字がエディションを表し、0.x がオープンソース版、1.x がEnterprise版です。下の表の「x」にはどちらかが入ります。

58〜63系の修正版一覧とGHSA表記のずれをNVD・JPCERT/CCで補う読み方

影響を受けるのは58系以降で、57系以前は対象外とMetabaseは説明しています。系ごとの版番号は次のとおりです。

1つ注意があります。GitHub APIで取得できるGHSAの影響範囲は「x.58.23未満」のように修正版の1つ手前までと読める書き方で、63系は「x.63.3未満」とさらに離れています。NVDの登録内容とJPCERT/CCの注意喚起AT-2026-0023はいずれも「修正版より前はすべて対象」としているため、x.58.23やx.63.4も影響ありとして扱ってください。

reset_password遮断では防げない公開共有経由のCVE-2026-72899

Metabaseは同じ8月6日に、CVE-2026-72899（GHSA-r8h2-qpfx-mx59）も公表しました。公開共有したカードやダッシュボードにフィールドフィルタのパラメータがあると、共有URLに含まれるUUIDだけでアプリケーションDBへSQLを注入できるというもので、CVSS v3.1は9.6です。

入口が別なので、reset_password を遮断しても防げません。しかもMetabaseのドキュメントにあるとおり、公開共有は既定で有効です。暫定策は公開共有の無効化か、フィールドフィルタを持つ公開リンクの取り下げです。管理画面の Settings から Public sharing を開くと、公開中の質問とダッシュボードが一覧で出ます。

同日には、一般ユーザーが監査用DBに向けたネイティブクエリと公開共有を組み合わせてアプリケーションDBを読めるCVE-2026-72900（CVSS 6.5）も出ています。修正版は3件とも同じです。

8月11日のGHSA-r495で推奨版が上がった理由と目指す版の決め方

8月11日のアドバイザリ GHSA-r495-55cx-fjh7は、Metabaseが自主的に洗い出した複数の問題をまとめて直したもので、深刻度はcriticalです。主な中身は、ユーザーが操作できるクエリ部品から生のSQLへ値が届く経路の封鎖、HoneySQL自体の脆弱性（CVE-2026-61620）を直した版への更新、参照先コンテンツの権限確認の徹底、そしてログインとパスワードリセットのレート制限をヘッダの書き換えで回避できた抜け道の修正です。

目指す版は、使っている系の強化版以上です。72898の修正版で止めると、同じ種類の穴が別の経路に残った状態になります。

Docker版Metabaseを強化版へ上げるアプリケーションDB退避と固定タグの更新手順

稼働中の版を確かめる手順とスクリプトは、LEAN BODYの事案とMetabaseの点検手順で示しています。ここでは、要更新と分かった後の入れ替え作業を扱います。

pg_dumpで退避してから固定タグのイメージへ入れ替えるコマンド例

Metabaseの更新手順は、まずアプリケーションDBをバックアップし、次に新しい版へ入れ替える2段階です。起動時にスキーマの移行が自動で走るため、戻すにはバックアップが必要になります。アプリケーションDBがPostgreSQLで、OSS版の58系を強化版へ上げる場合の例です。

# 1. アプリケーションDBを退避する（カスタム形式。接続情報は環境に合わせて置き換える）
pg_dump -h DBHOST -U metabase -Fc -f metabase_appdb_$(date +%Y%m%d%H%M).dump metabase

# 2. latest ではなく固定タグで取得する（Enterprise版は metabase/metabase-enterprise:v1.58.28）
docker pull metabase/metabase:v0.58.28

# 3. 旧コンテナを止めて削除し、同じ環境変数で起動し直す
docker stop metabase
docker rm metabase
docker run -d -p 3000:3000 --env-file metabase.env --name metabase metabase/metabase:v0.58.28

# 4. 起動ログで移行の完了を確かめ、版を表示する
docker logs -f metabase
curl -s http://localhost:3000/api/session/properties | jq -r '.version.tag'

接続文字列 MB_DB_CONNECTION_URI などはコマンドに直書きせず、--env-file で渡す形にしています。pg_dumpのオプションはPostgreSQLのpg_dumpの説明どおりで、-Fc を付けると pg_restore で戻せる形式になります。最後の行で v0.58.28 が返れば入れ替えは完了です。

アプリケーションDBがH2のままなら、更新前にH2のファイルをコピーで退避します。H2は本番向けではないとMetabase自身が案内しており、今回のような緊急更新を繰り返す前提なら、PostgreSQLへの移行も同時に計画してください。

サポート外の59〜62系を使い続けるか58系LTSか新しい系へ移るかの判断

2026年10月23日時点のMetabaseドキュメントの版一覧では、58系にLTS、59〜62系に「unsupported」の表示が付いています。強化版が出たのは今回の緊急対応だからで、59〜62系に今後も修正が届くとは読めません。

判断は次のとおりです。59〜62系を使っていて、ダッシュボードの改修が少ないなら、今回は同じ系の強化版へ上げて止血し、次の保守で58系LTSか63系以降へ移します。系をまたぐ更新はスキーマ移行を伴うため、緊急対応と同時に行わず、次の保守での移行として分けて扱う方針です。逆に、すでに63系なら x.63.10 以上へ上げるだけで済みます。系をまたいで上げる場合は、移った先の系の最新の点版を使うようMetabaseは案内しています。

侵害有無を調べるログとアプリケーションDBの照合手順とJPCERT/CC送信元の突合

Metabaseが示した痕跡は、POST /api/session/reset_password が400で返った直後に GET /api/user/current が200で返る組み合わせです。この組み合わせを抽出するコマンドは18168の記事に載せているので、ここでは送信元での照合と、アプリケーションDB側の確認を加えます。

JPCERT/CCが公表した送信元IPとUser-Agentでアクセスログを洗う手順

JPCERT/CCの注意喚起AT-2026-0030は、国内組織で相次ぐ不正アクセスの「ケースC」としてこの脆弱性を挙げ、8月上旬から9月上旬に悪用された送信元IPアドレス3件とUser-Agentの例2件を公表しました。BIツールのように不特定多数のアクセスを想定していないシステムも被害に遭っていると明記しています。nginxのアクセスログ（combined形式）を前提にした照合の例です。

# JPCERT/CC AT-2026-0030 ケースCの送信元IPアドレス
zgrep -hE '^(213\.163\.202\.171|221\.216\.140\.49|221\.216\.140\.129) ' /var/log/nginx/access.log* \
  | awk '{print $1, $4, $6, $7, $9}' | sort | uniq -c | sort -rn

# 同じくUser-Agentの例（送信元IPが変わっていても拾える）
zgrep -hE 'Metabase-GHSA-vwf4|python-requests/2\.33\.1' /var/log/nginx/access.log* \
  | awk '{print $1, $4, $7, $9}' | sort | uniq -c | sort -rn

# reset_password への到達を送信元IPごとに数える（遮断の前後の比較に使う）
zgrep -h 'POST /api/session/reset_password' /var/log/nginx/access.log* \
  | awk '{print $1, $9}' | sort | uniq -c | sort -rn | head -20

JPCERT/CCは、これらのIPアドレスが調査時点では正規の利用に使われている可能性もあると注記しています。一致しただけで侵害と決めず、同じ時刻帯に /api/user/current の200や管理系APIへのアクセスが続いているかで判断します。逆に、一致しないことも安全の証明にはなりません。User-Agentは自由に変えられるからです。

core_user・api_key・login_historyで追う管理者とキー

攻撃者が管理者権限を得た後に残しやすいのは、新しい管理者アカウントとAPIキーです。アプリケーションDB（PostgreSQL）に読み取り専用でつなぎ、公表日の少し前からの変化を見ます。テーブル名と列名はMetabaseのマイグレーション定義で確認したものです。

-- 1. 8月以降に作成・更新された管理者アカウント
SELECT id, email, is_active, date_joined, updated_at, last_login
FROM core_user
WHERE is_superuser = true
  AND (date_joined >= '2026-08-01' OR updated_at >= '2026-08-01')
ORDER BY updated_at DESC NULLS LAST;

-- 2. 8月以降に作られたAPIキーと作成者
SELECT k.id, k.name, k.key_prefix, k.created_at, u.email AS creator
FROM api_key k
LEFT JOIN core_user u ON u.id = k.creator_id
WHERE k.created_at >= '2026-08-01'
ORDER BY k.created_at;

-- 3. ログインの送信元IPアドレス（JPCERT/CCの送信元や社外IPと照合する）
SELECT ip_address, count(*) AS logins, min("timestamp") AS first_seen, max("timestamp") AS last_seen
FROM login_history
WHERE "timestamp" >= '2026-08-01'
GROUP BY ip_address
ORDER BY logins DESC;

1で、作った覚えのない管理者や、最近になって管理者へ昇格した既存ユーザーが出たら侵害を前提に進めます。2のAPIキーは管理画面の Admin settings から一覧でき、APIキーのドキュメントにあるとおり、削除したキーは戻せません。削除の前に名前と作成日時を記録しておきます。3は通常のログインの記録で、SQLインジェクションでセッションを直接作られた場合は残らない可能性があります。3に何も出ないことを根拠に安全と判断しないでください。

痕跡が出たときのセッション失効と接続先DB認証情報の入れ替え順序

GHSAが更新後の作業として挙げている6項目を、実際に回す順番に並べると次のようになります。

1. アプリケーションDBのバックアップとアクセスログを、調査用に別の場所へ複製する。
2. 強化版へ更新した後、core_session の全行を削除して全セッションを失効させる。
3. 不明なAPIキーを削除し、管理者アカウントの変更を元に戻す。
4. Metabaseに登録した接続先DBのパスワードを、DB側で変更してからMetabaseの設定を更新する。
5. 接続先DB（データウェアハウス）側のログと、Metabaseのクエリ履歴で不審な読み出しを探す。

4は痕跡の有無にかかわらず強く勧めます。CVE-2026-72900のアドバイザリによれば、MB_ENCRYPTION_SECRET_KEY を設定していない既定の構成では、アプリケーションDBを読まれると接続先DBの認証情報が平文で取れてしまいます。接続情報の暗号化の手順に沿って、入れ替えと同時にこの鍵も設定してください。痕跡が見つかった段階で、自社だけで調べ続けるより証拠の保全を優先する判断は、デジタルフォレンジックの流れを参考にしてください。

自社開発のAPIで同じ穴を作らないためのリクエスト本文の受け取り方と検証

CVE-2026-72898の原因は、Metabase固有というより、Web APIの実装でよく起きる型です。OWASPのMass Assignment Cheat Sheetが扱う「想定外のキーを受け取ってしまう」問題に、生SQLを組み立てる機能が重なりました。APIの認可や入力検証の全体像はAPIセキュリティの主要リスクと実装対策で整理しています。

想定外のキーを拒否するpydanticのextra=’forbid’による入力モデル

PythonでAPIを書いているなら、リクエスト本文をpydanticのモデルで受け、定義していないキーを拒否する設定にします。pydanticのドキュメントでは、extra を 'forbid' にすると余分なデータが許可されなくなると説明しています。

from pydantic import BaseModel, ConfigDict, ValidationError


class ResetPasswordBody(BaseModel):
    # 定義していないキー（user_id など）が来たら検証エラーにする
    model_config = ConfigDict(extra='forbid')
    token: str
    password: str


try:
    ResetPasswordBody.model_validate({'token': 'x', 'password': 'y', 'user_id': {'raw': '1'}})
except ValidationError as e:
    print(e.errors()[0]['type'])  # extra_forbidden

実行すると extra_forbidden が表示され、user_id を混ぜた本文は処理の手前で弾かれます。TypeScriptならzodの strict()、Javaなら未知のプロパティで失敗する設定のように、どの言語にも同じ考え方の仕組みがあります。

認証結果とリクエストを混ぜない実装と社内BIツールを外部診断に含める判断

もう1つの教訓は、認証の結果とリクエストの値を1つの入れ物に混ぜないことです。誰として処理するかを決める際の根拠は、認証処理が返した値だけです。リクエストを先に入れて認証結果で上書きする書き方は、認証が失敗した経路で攻撃者の値が残ります。コードレビューでは、merge やスプレッド構文でリクエスト本文を丸ごと広げている箇所を重点的に見ます。

運用面では、MetabaseのようなOSSのBIツールを「社内向けだから」と診断の範囲から外さないことです。JPCERT/CCの注意喚起でも、被害に遭っているシステムとして名指しされているのは、BIツールや従業員向け管理システムです。外部から届くBIツールが1台でもあるなら、自社開発のWebシステムと一緒に脆弱性診断・セキュリティ診断の対象へ入れ、公開範囲と版の管理状況を棚卸しするところから始めると漏れが出にくくなります。一方、VPNの内側だけで動き、接続先が集計済みのテーブルに限られる構成なら、診断よりも更新の通知を受けて数日以内に当てる運用づくりを先にするほうが費用に見合います。

Metabase CVE-2026-72898の対応でよく出る質問と一次情報に基づく回答

CVE-2026-72898への対応を進めるなかで出やすい疑問に、公開されている一次情報の範囲で答えます。

Metabase Cloudを使っている場合も対応は必要ですか？

更新作業は不要です。Metabaseの公式ブログとJPCERT/CCの注意喚起によれば、Metabase Cloudはすでに修正済みです。ただし最初に攻撃を受けたのはCloudだったと公式ブログ自身が説明しています。8月上旬の時点でCloudのインスタンスを使っていたなら、APIキーと管理者アカウントの確認、接続先DBのログ確認はセルフホストと同じように行う価値があります。

57系以前のMetabaseなら影響はありませんか？

CVE-2026-72898の影響はありません。Metabaseは58系より前は対象外と説明しています。ただし57系以前は、2026年5月以降に公表された別の重大な脆弱性の修正対象から外れている系もあり、ドキュメントの版一覧でもunsupportedの扱いです。今回が対象外であることは、使い続けてよい理由になりません。

reset_passwordを遮断すれば更新を後回しにできますか？

一時的な回避策にはなりますが、後回しにはできません。遮断が効くのはCVE-2026-72898だけで、公開共有を入口にするCVE-2026-72899や、8月11日のアドバイザリで直された問題は残ります。遮断はあくまで更新までの数時間から数日をつなぐ手段として使い、その間に公開共有も無効にしておきます。

更新後に全ユーザーが再ログインになるのは避けられますか？

reset_passwordがインターネットから届く状態だったなら、避けないほうが安全です。攻撃者が作ったセッションは、正規のものと見分けられないためです。GHSAも core_session の全行削除を求めています。利用者への影響は再ログイン1回で済むので、事前に告知したうえで実施します。

社内ネットワークだけで動かしているMetabaseも急ぐべきですか？

急ぐべきです。社外から直接届かなくても、社内の端末が1台乗っ取られればそこから同じリクエストを送れます。攻撃に認証は要らず、攻撃コードも出回っています。外部公開しているものより数日の猶予はありますが、次の定例保守まで待つ判断はしないでください。

関連記事

• LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用：版を判定するスクリプト、nginxでの遮断、400直後の200を拾うログ抽出をコードで示しています。
• Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】：アプリケーションDBをH2から本番向けDBへ移す構成を確認できます。
• APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説：想定外の入力や認可の抜けを自社APIで防ぐ実装を整理しています。
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：脆弱性の公表から修正に至る流れの基礎です。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：BIツールを含めて診断範囲を決める際の進め方です。