Metabase の未認証SQLインジェクション CVE-2026-72898 - CVSS 10.0、ベンダー自身のCloudがゼロデイで攻撃された

社内のBIツールは、性質上本番データベースへの接続情報が集まる場所です。そのMetabaseに、認証不要でアプリケーションDBに任意のSQLを注入し、管理者権限を奪える脆弱性が見つかりました。CVE-2026-72898、CVSSは3.1でも4.0でも満点の10.0です。

しかもこの脆弱性は、研究者からの報告ではありません。Metabase Cloud 自身が未知のゼロデイとして攻撃を受け、その解析から発見されたものです。CISAは公表翌週にKEV（悪用が確認された脆弱性カタログ）へ追加し、是正期限をわずか3日後に設定しました。

この記事では、GitHub Security Advisory、Metabase公式ブログ、NVD、CISA KEVのJSONフィード、そして公式リポジトリのコミット差分という一次情報をもとに、何が起きたのか、自ホスト運用者は何をすべきかを整理します。

何が起きたのか - タイムライン

Metabase公式ブログ（2026年8月6日、CEOのSameer Al-Sakran名義）は、発見の経緯をこう書いています。

We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ("0-day") security vulnerability in versions 1.58 and above. We immediately blocked the endpoints used for the attack, then quickly identified and patched the vulnerability.

Metabase Cloud が未知の脆弱性で攻撃され、攻撃に使われたエンドポイントを即座にブロックしたうえで、脆弱性を特定・修正した、という順序です。Cloud顧客はすでに修正済みだが、自ホスト運用者は自分でアップグレードせよ、というのがこのアナウンスの主旨でした。

一次情報から確認できる時系列は次のとおりです。

注目すべきは、初回修正版を出したあとも2回リリースが重なっていることです。8月6日に「0.63.5 以上へ」と案内されたのに、8月14日時点の推奨最低版は 0.63.13 になっています。8月6日の案内だけを見て 0.63.5 に上げて安心していると、その後の派生的な問題が残ったままになります。

CVE-2026-72898 の中身

GitHub Security Advisory（GHSA-vwf4-m7j8-wcjf、2026年8月6日公開）のSummaryは次のとおりです。

This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance. From there, the attacker could change the application configuration, steal stored credentials for the connected databases, read any data accessible through those connections, and export data. Metabase has confirmed active exploitation of this vulnerability.

未認証のリモート攻撃者がアプリケーションDBに任意のSQLを注入し、管理者権限を得られる。そこから設定変更、接続先DBの保存済み認証情報の窃取、それらの接続を通じて到達できるデータの読み取りとエクスポートまで可能、という内容です。末尾で悪用の実確認も明言されています。

ここで重要なのが「アプリケーションDB」と「データウェアハウス」の区別です。Metabase公式ドキュメントはこう説明しています。

The application database is where Metabase stores information about user accounts, questions, dashboards, and any other data needed to run the Metabase application. This app DB is distinct from the database where you store your data, also known as your data warehouse.

つまり、SQLが注入されるのは分析対象のデータ本体ではなく、Metabase自身の設定DBです。しかしそこには接続先DBの認証情報が保存されているため、結果的にデータウェアハウス側も全面的に危険にさらされます。これがCVSSで最高値が付いた理由に直結します。

CVSS 10.0 の内訳

CVSS 3.1 で 9.8 ではなく 10.0 になっているのは S:C（Scope Changed） だからです。脆弱なコンポーネント（Metabase）の権限境界を越えて、別のコンポーネント（接続先データベース）に影響が及ぶ、という評価です。参考までに、2023年に話題になったMetabaseの未認証RCE CVE-2023-38646 は S:U で 9.8 でした。リモートコード実行より高いスコアが付いたSQLインジェクションという、珍しい構図になっています。

なお、CWE-89（SQLインジェクション）を付与しているのはCISAとNVDで、GHSA本体のWeaknessesは「No CWEs」です。細かい点ですが、出典を明示するなら区別しておくべきところです。

根本原因 - 公式は未公表、コード差分から読み取れること

Metabaseは執筆時点で根本原因の技術的な解説を公表していません。8月12日のブログにも「as our internal and external investigations proceed」とあり、調査継続中の姿勢です。

ただし、公式リポジトリには 2026年8月17日にマージされた Backend hardening (#80003) という300ファイル規模のコミットがあり、そこから攻撃連鎖を高い精度で推定できます。以下は公式の説明ではなく、公開されているコード差分からの推定である点に注意してください。

1. JSONボディのキーがすべてキーワード化されていた。MetabaseはClojure製で、リクエストボディのJSONをキーワードキーのマップに変換します。{"raw": "..."} は {:raw "..."} になりますが、これは Metabase が使うSQL生成ライブラリ HoneySQL における「生SQLを埋め込む」記法そのものです。
2. エンドポイントのスキーマが開いていた。/api/session/reset_password のリクエストボディ検証は、token と password だけを宣言しつつ、それ以外の未申告フィールドを拒否しない「開いたマップ」でした。修正では {:closed true} が付き、select-keys で必要な2つだけに絞られています。
3. ボディ全体が認証レイヤーへ渡り、内部状態にマージされていた。修正コミットでは、認証プロバイダ側が管理すべきキーの拒否リストが新設されています。:user-id :success? :session :claims :tenant-attributes といった、本来サーバー側だけが決める値が並びます。
4. 注入された値がアプリDBのクエリに到達した。ユーザーIDでレコードを引く箇所に {:raw "..."} が渡ると、HoneySQL がそれを生SQLとして展開してしまいます。修正では「正の整数でなければユーザー解決を拒否する」検証が追加されました。
5. success? を偽装するとセッションが発行された。修正では (true? (:success? $)) という明示的なチェックが加わっています。

つまり、これは古典的な文字列連結によるSQLインジェクションではありません。クエリをデータ構造で表現する設計に対して、外から構造そのものを注入するタイプです。OWASPの用語で言えばマスアサインメント（CWE-915）の変種が、そのままSQLインジェクションに化けた形になります。

Metabase自身も、この類型を一般論として認めています。同時期の別アドバイザリ（後述のGHSA-r495-55cx-fjh7）の項目7にこうあります。

Previously, many API endpoints accepted loosely structured request bodies and acted on fields they didn't expect. We now apply strict schema verification in two places: at the API boundary, where each endpoint accepts only the fields it is meant to, and at the query-compilation layer, where query fragments are turned into SQL.

APIの境界とクエリコンパイル層の2箇所で厳格なスキーマ検証を行うようにした、という記述です。実際、修正コミットにはアプリDB向けのHoneySQLガード（生SQLやインライン展開がコンパイル直前に来たら拒否する仕組み）が新規ファイルとして追加されています。多層防御の教科書的な対応と言えます。

侵害の痕跡 - ログで確認できるパターン

公式ブログは、具体的な攻撃パターンを明示しています。

The pattern of attack looks like the following:

• call to POST /api/session/reset_password with a 400 status code followed by
• call to GET /api/user/current with a 200 status code If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised.

ポイントはステータスコードの組み合わせです。POST /api/session/reset_password が 400（リセットトークンが無効なので失敗）を返しているのに、直後の GET /api/user/current が 200 を返している。本来なら失敗しているはずのリクエストで、なぜかセッションが成立している、という矛盾が痕跡になります。前節の推定で言えば、success? の偽装によってセッションだけが発行された結果です。

nginxやApacheのアクセスログが残っているなら、次のような雑な抽出で当たりを付けられます。

# 該当エンドポイントへのアクセスを時系列で抽出（ログ形式に応じて調整）
grep -E '/api/(session/reset_password|user/current)' access.log \
  | awk '{print $4, $7, $9}' \
  | sort

400 の reset_password の直後に、同一IPから 200 の user/current が来ていないかを目視で追います。ログを長期保存していない場合は「痕跡がない」ではなく「確認できない」であり、侵害されていない証拠にはなりません。

なお、POST /api/session/reset_password は本来、メールで送られたリセットトークンを使って新しいパスワードを設定するためのエンドポイントで、受け取るパラメータは token と password の2つだけです（公式リポジトリのソースで確認）。これ以外のフィールドが飛んでくること自体が異常でした。

回避策だけでは塞げない - 同時公表の兄弟CVE

公式が案内する暫定回避策は「/api/session/reset_password をブロックする」です。しかしこれだけでは不十分です。同じ2026年8月6日に、もう2本のアドバイザリが同時公表されているためです。

CVE-2026-72899 - 公開共有ダッシュボード経由の未認証SQLi

GHSA-r8h2-qpfx-mx59 のSummaryはこうです。

An unauthenticated attacker can inject arbitrary SQL into the Metabase application database using a publicly shared card or dashboard that exposes a field-filter (dimension) parameter. With only the public link UUID, which is part of the shared URL by design, the attacker could change the application configuration, steal stored credentials for the connected databases, read any data accessible through those connections, and export data. Public sharing is enabled by default, so publishing a link is the only setup required.

到達点はCVE-2026-72898とまったく同じ（アプリケーションDBへの任意SQL、認証情報の窃取）ですが、入口が公開共有リンクです。しかも公開共有はデフォルトで有効なので、フィールドフィルタを持つ質問やダッシュボードを1つ公開しているだけで成立します。必要なのは共有URLに含まれるUUIDだけです。

回避策も別で、「公開共有を無効化するか、フィールドフィルタを露出している公開リンクを取り下げる」ことになります。NVDとCISAはこのCVEにも 10.0 を付けています（GHSA側の記載は UI:R を含む 9.6 で、ベンダーとCNAでスコアが食い違っている点は留意してください）。

CVE-2026-72900 - 低権限ユーザーによるアプリDBの読み取り

GHSA-8hmm-hrhg-ppqp は深刻度Moderate（GHSA記載 6.5、NVD 4.0で7.1）ですが、運用への示唆が大きい内容です。

The user can read the entire Metabase application database this way which contains user session records and bcrypt password hashes, amongst other sensitive information. On any instance without MB_ENCRYPTION_SECRET_KEY set (the default), the same read returns the stored credentials for every connected database in cleartext.

特別な権限を持たない認証済みユーザーが、監査用データベースを対象とするネイティブクエリを作って公開共有すれば、アプリケーションDB全体を読めた、という話です。そしてMB_ENCRYPTION_SECRET_KEY を設定していない（デフォルト）インスタンスでは、接続先DBの認証情報が平文で返ると明記されています。

これは今回の対応方針に直結します。「アップグレードしたから大丈夫」ではなく、接続先DBの認証情報ローテーションは選択肢ではなく必須だという根拠がここにあります。環境変数による機密の扱いについては環境変数と.envによる機密管理も参考にしてください。

CISA KEV - 是正期限わずか3日

CISAのKnown Exploited Vulnerabilities カタログ（catalogVersion 2026.08.18、収録1670件）の該当エントリは次のとおりです。

追加から是正期限までわずか3日という異例の短さです。requiredAction も従来の定型文ではなく、BOD 26-04（リスクベースのセキュリティ更新優先順位付けに関する指令）への準拠と、CISAの「Forensics Triage Requirements」への参照を含む新しい書式になっています。比較として、同じカタログに載っているMetabaseのもう1件 CVE-2021-41277（GeoJSON APIのローカルファイル読み取り）は、2024年11月12日追加・期限12月3日と3週間の猶予でした。

CISAが発行したCSAFアドバイザリ VA-26-222-01 では、SSVCの評価が E:A（Exploitation: Active）となっています。KEV掲載の対象は米国の連邦機関ですが、悪用が現実に確認されている脆弱性の一覧として、民間でも優先度判断の基準として使えます。KEVの位置づけについてはSharePoint Server の RCE 脆弱性でも触れました。

8月11日の追加ハードニング - CVEが振られていない10項目

8月11日には、GHSA-r495-55cx-fjh7「Multiple vulnerabilities across query validation, permissions, and network exposure」というアドバイザリが出ています。CVE IDは振られていません（GHSA上の表記は「No known CVE」）。しかしCritical扱いで、内容は10項目に及びます。主なものを挙げます。

• クエリ入力の検証強化。「a crafted value could reach the database as raw SQL rather than being treated as data」として、クエリパラメータ、cast オプション、metric/segment定義、BigQuery/SQL Serverのスキーマ生成、ClickHouseの識別子エスケープなど広範囲を修正
• HoneySQL の更新。SQL生成ライブラリ側の脆弱性 CVE-2026-61620 を修正したバージョンへ引き上げ
• 参照コンテンツの権限チェックの網羅化。深くネストした保存済み質問への権限チェックなど
• ログイン・パスワードリセットのレート制限の穴。「a gap where varying a request header could reset the per-client rate limits」
• ネットワーク露出の修正。レガシーHTTPアクションの無効化、DBのSSHトンネルをループバック限定にバインド
• 管理系エンドポイントのアクセス制御。「a deactivated administrator no longer silently regains admin rights on their next single sign-on login」

最後の項目はSSOを使っている組織にとって見逃せない内容です。無効化したはずの管理者アカウントが、次回のシングルサインオンで管理者権限ごと復活していた、という挙動が修正されています。SSO運用中なら、無効化済み管理者アカウントの棚卸しも合わせて行うべきです。

運用上の罠 - 修正版がGitHubに存在しない

この件でもう1つ厄介なのが、修正版が普段の確認先に出てこないことです。一次情報を追った結果、次の状況が確認できました。

• GitHub Releases の最新は v0.63.2（2026年7月29日）。8月以降のセキュリティリリースは1件もRelease化されていない
• Gitタグも未公開。v0.63.5 や v0.63.13 のタグ参照はAPIで404を返す
• 公式changelogも 63.2 までしか掲載されていない
• GHSA-vwf4-m7j8-wcjf は GitHub Global Advisory Database と OSV.dev に未登録

最後の点は実務上かなり重要です。Dependabot や Trivy、Grype のような依存スキャナは、公開アドバイザリDBに載っていない脆弱性を検知できません。Metabaseをコンテナで動かしていてイメージスキャンを回している組織でも、今回のCVEは引っかからない可能性があります。

一方、公式ドキュメントのアップグレード手順は「Check out a list of Metabase releases: github.com/metabase/metabase/releases」と案内し続けています。案内先を見に行っても修正版は見つかりません。実際の入手経路は次の2つだけです。

• JAR: https://downloads.metabase.com/v0.63.13/metabase.jar
• Docker: metabase/metabase:v0.63.13（Enterpriseは metabase/metabase-enterprise:v1.63.13）

バージョンの正しい一覧は、公式のバージョン情報フィードで取れます。

# OSS の最新版と各メジャーのサポート期限
curl -s https://static.metabase.com/version-info.json | jq '.latest.version'
 
# Enterprise 版
curl -s https://static.metabase.com/version-info-ee.json | jq '.latest.version'

いま何をすべきか

1. 自分のバージョンを確認する

UIからは、右上の歯車またはグリッドのアイコンから「About Metabase」（バージョンによっては「Help」の下）で確認できます。APIでも取れます。

# 認証なしで取得できる（= 攻撃者からも版数が見える点に注意）
curl -s https://metabase.example.com/api/session/properties | jq -r '.version.tag'

/api/session/properties は未ログインでも公開設定を返す設計です。裏を返せば、インターネットに露出しているMetabaseは、外部から脆弱なバージョンかどうかを判別できてしまうということです。この情報自体を隠すのは難しいので、露出しているなら急ぐ理由が1つ増える、と捉えるのが現実的です。

x.57以下を使っている場合、今回のCVEの影響は受けません（ただしそれはそれで別のサポート問題があります。後述）。

2. アップグレードする

推奨最低版は、8月14日更新時点で次のとおりです。Enterprise版は先頭の 0. を 1. に読み替えます。

手順は公式ドキュメントどおり、アプリケーションDBをバックアップしてからイメージまたはJARを差し替えるだけです。起動時にスキーママイグレーションが自動で走ります。

# Docker の例
docker stop metabase
docker pull metabase/metabase:v0.63.13
docker run -d --name metabase-new -p 3000:3000 \
  -e MB_DB_TYPE=postgres -e MB_DB_HOST=... \
  metabase/metabase:v0.63.13

すぐにアップグレードできない場合の暫定回避策は2つあり、両方必要です。

• リバースプロキシで /api/session/reset_password をブロックする（CVE-2026-72898向け）
• 公開共有を無効化するか、フィールドフィルタを露出している公開リンクを取り下げる（CVE-2026-72899向け）

3. アップグレード後の事後対応（露出していたなら必須）

公式は、/api/session/reset_password が外部から到達可能だったインスタンスに対し、アップグレード後に次を行うよう指示しています。

1. アプリケーションDBの core_session テーブルを空にして、全ユーザーの有効セッションを失効させる（公式は TRUNCATE TABLE core_session と明記）
2. APIキーを棚卸しし、心当たりのないキーを削除する
3. 管理者アカウントに予期しない変更がないか確認する
4. 接続先データベースの認証情報をすべてローテーションする
5. データウェアハウス側のログに不正アクセスの形跡がないか確認する
6. Metabaseのアクティビティとクエリ履歴に不審な操作がないか確認する

4番目は面倒ですが省略できません。CVE-2026-72900 の記述どおり、MB_ENCRYPTION_SECRET_KEY を設定していないインスタンスでは接続情報が平文で保存されているためです。設定している場合でも、暗号化キー自体がアプリDBの外にあるとは限らない構成もあるので、露出していたなら回すのが安全側の判断です。

APIキーの棚卸しには落とし穴があります。公式ドキュメントによれば、グループを削除してもそのグループに紐づいていたAPIキーは All users グループへ移されるため、グループごと消したつもりでキーが生き残ります。管理画面の Settings から Authentication、API Keys の Manage で一覧を確認してください。

4. サポート期限も同時に確認する

見落とされがちですが、公式のバージョン情報フィードにはメジャー版のEOLが含まれています。

59から62系は2026年9月1日にEOLを迎えます。今回パッチを当てても、2週間ほどでサポート切れです。腰を据えて運用するなら、LTSである58系か、最新の63系へ寄せる判断が必要になります。x.57以下を使っていて今回のCVEの影響外だった環境も、すでにEOLを過ぎている点は認識しておくべきです。

2023年との対比 - 情報開示の姿勢が変わった

Metabaseには2023年にも未認証RCE CVE-2023-38646 がありました。当時の公式ブログと今回を並べると、状況の違いがはっきりします。

2023年は「まだ悪用されていないので、利用者に猶予を与えるため詳細公開を遅らせる」という余裕のある対応でした。2026年は「すでに攻撃されている」ところから始まっています。8月12日のブログでMetabaseは、新機能のリリースを止めてセキュリティとオブザーバビリティ中心の週次マイナーリリース体制へ移行すると宣言しました。この判断の重さが、今回の深刻度を物語っています。

なお、CVE-2023-38646 は執筆時点のKEVカタログには収録されていません。悪用が広く報じられた脆弱性でも、KEVに載るとは限らない点は押さえておくべきです。

開発者としての教訓

Metabaseを使っていない読者にとっても、今回の構図には一般化できる学びがあります。

1. 「宣言していないフィールドを黙って受け取る」APIは危ない。 OWASPのMass Assignment Cheat Sheet が警告するとおり、リクエストパラメータを自動でオブジェクトへ束縛するフレームワークは便利な反面、開発者が意図しないフィールドの作成・上書きを許します。今回の修正の中心も、スキーマを「閉じる」ことと、必要なキーだけを select-keys で抜き出すことでした。

2. クエリをデータ構造で組み立てる設計では、マスアサインメントがSQLインジェクションに化ける。 文字列連結をしていないから安全、とは言えません。HoneySQLのようなライブラリでは {:raw "..."} というマップ自体が生SQLの指示になるため、外部からマップを注入できれば、それはそのままSQLインジェクションです。JSONのキーがそのまま内部表現のキーになる言語・フレームワークでは特に注意が必要です。

3. エスケープに頼る防御は最後の手段。 OWASPのSQL Injection Prevention Cheat Sheet は、対策を「プリペアドステートメント」「適切に構成されたストアドプロシージャ」「許可リストによる入力検証」「（強く非推奨）すべての入力のエスケープ」の順に挙げています。今回の修正コミットには、クォートのエスケープを行う正規表現にバイパスがあり単純な全置換に直された箇所が含まれています。「STRONGLY DISCOURAGED」の実例そのものです。

4. 認証の成否をリクエスト由来の値で判断しない。 success? や user-id のような「サーバーが決めるべき値」は、リクエストから来た値と同じ名前空間に置かない設計が安全です。修正で追加された拒否リストは、まさにその境界を明文化したものです。似た構図はLangflow の未認証RCEでも見られました。

まとめ

• CVE-2026-72898 はMetabaseの未認証SQLインジェクションで、CVSSは3.1・4.0とも10.0。S:C により、2023年の未認証RCE（9.8）を上回るスコアが付いた
• Metabase Cloud 自身がゼロデイとして攻撃を受け、そこから発見された。悪用は公式が確認済みで、CISA KEVには2026年8月11日に追加、是正期限は3日後の8月14日
• 影響は x.58 以降。x.57 以下は影響外だが、すでにEOLを過ぎている
• 回避策は2つ必要。/api/session/reset_password のブロックに加え、公開共有リンク経由の CVE-2026-72899 に対して公開共有の見直しも要る
• アップグレードだけでは終わらない。露出していたなら core_session の全削除、APIキー棚卸し、管理者アカウント監査、そして接続先DB認証情報のローテーションまでが公式指示
• 8月14日時点の推奨最低版は 0.63.13 / 0.62.16 / 0.61.18 / 0.60.24 / 0.59.28 / 0.58.31。59〜62系は2026年9月1日にEOLなので、パッチ適用と並行してメジャーアップグレードの計画が必要
• 修正版はGitHubのReleasesにもタグにも存在せず、GHSAは公開アドバイザリDBにも未登録。依存スキャナやリリース監視に頼った運用では検知できない
• 根本原因は公式未公表。本記事の推定は公開されたハードニングコミットの差分に基づくもので、公式の説明ではない

BIツールは「社内向けだから」という理由で優先度が下がりがちですが、接続情報が集約されている以上、侵害された時の被害はデータ基盤全体に及びます。まずは自分の環境のバージョンと、/api/session/reset_password および公開共有リンクの外部到達性を確認するところから始めてください。国内のインシデント動向は2026年 日本のセキュリティインシデントまとめでも追っています。

参考資料

• GitHub Security Advisory: GHSA-vwf4-m7j8-wcjf（CVE-2026-72898）
• GitHub Security Advisory: GHSA-r8h2-qpfx-mx59（CVE-2026-72899）
• GitHub Security Advisory: GHSA-8hmm-hrhg-ppqp（CVE-2026-72900）
• GitHub Security Advisory: GHSA-r495-55cx-fjh7（8月11日のハードニング）
• Metabase Blog: Security Update（2026-08-06）
• Metabase Blog: Security-focused release announcement（2026-08-12）
• NVD: CVE-2026-72898
• NVD: CVE-2023-38646（2023年の未認証RCE）
• CISA: Known Exploited Vulnerabilities Catalog
• Metabase Docs: Upgrading Metabase
• Metabase Docs: Configuring the application database
• Metabase Docs: API keys
• Metabase: Backend hardening (#80003) コミット
• OWASP Cheat Sheet: Mass Assignment
• OWASP Cheat Sheet: SQL Injection Prevention
• Langflow の未認証リモートコード実行 CVE-2026-9198（当ブログ）
• SharePoint Server の RCE 脆弱性 CVE-2026-45659（当ブログ）
• 環境変数と.envによる機密管理（当ブログ）
• 2026年 日本のセキュリティインシデントまとめ（当ブログ）