Metabaseの未認証SQLインジェクションCVE-2026-72898。パスワードリセット経路から管理者権限が奪われる機構

BIツールのMetabaseに、認証を経ずにSQLを注入できる脆弱性CVE-2026-72898が見つかりました。修正が公開される前に実際の攻撃で使われたゼロデイで、Metabaseを使っていた複数の企業が顧客データへの不正アクセスを相次いで公表しています。CISAは2026年8月11日にこの脆弱性をKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。

Metabaseは社内の各種データベースへ接続し、集計と可視化をまとめて引き受ける製品です。裏を返せば、Metabaseの管理者権限を取られた時点で、接続先データベースの資格情報が一箇所にそろった状態で攻撃者の手が届くところに置かれます。CISAのKEVカタログも、想定される結末として接続先データベースの資格情報の窃取とデータのエクスポートを挙げています。この事案が重く扱われる理由は、注入そのものの巧妙さではなく、注入の先に何が置かれているかにあります。

この記事は、Metabaseを運用する情報システム担当とデータ基盤の担当者に向けて、GitHub Security Advisory、Metabase公式のセキュリティ告知、CVEレコードとCISAのKEVカタログおよびCSAFという一次情報を軸に、Wiz Researchの解析と被害を公表した各社の告知を補って、事実関係と実務の対応を整理します。攻撃を再現する手順や動作するリクエストは扱いません。記述は執筆時点(2026年8月12日)に確認できた範囲に限ります。確認作業は自組織が管理するMetabaseに対してのみ行ってください。第三者のインスタンスへ試す行為は不正アクセス禁止法に触れるおそれがあります。

修正より先に攻撃が来た時系列#

一次情報から確認できた日付を並べます。日付はいずれも2026年です。

Metabaseのブログは2026年8月6日付で、CEOのSameer Al-Sakran氏の署名で公開されています。冒頭には「Metabase Cloud was attacked by someone utilizing an unknown ("0-day") security vulnerability in versions 1.58 and above」と書かれており、攻撃に使われたエンドポイントを直ちに遮断したうえで脆弱性を特定して修正した、と続きます。Metabase Cloudの利用者についてはすでに更新済みで対策されているとし、自社運用のMetabaseは脆弱な可能性があると案内しています。

修正が存在しない状態で悪用が先行したという性格そのものは、次の記事で整理しています。

注目したいのは、CVE番号が付いたのが8月10日で、Metabaseの公表から4日後だった点です。8月6日から8月10日までのあいだ、この脆弱性はCVE番号を持たないまま実環境で悪用されていました。CVE番号を検知や台帳の起点にしている運用では、この4日間が空白になります。ベンダーのセキュリティ告知とGitHub Security Advisoryを、CVEの採番とは独立に監視する経路を持っておく必要があります。

CVE-2026-72898の基本情報#

CVEレコードを採番したCNAはCISA(cisa-cg)です。Metabase自身ではありません。レコードの公開は2026年8月10日、最終更新は8月11日で、KEV追加を受けたCISAのADP情報が加わっています。

CVSS 10.0という上限値が付く条件は限られています。CVSS v3.1の仕様では、ネットワーク越し(AV:N)に、低い攻撃条件(AC:L)で、権限なし(PR:N)かつ利用者の関与なし(UI:N)で成立し、さらにScopeがChanged(S:C)であることが必要です。S:Cは、脆弱なコンポーネントの権限の及ぶ範囲を越えて、別の権限範囲にあるリソースへ影響が及ぶ状態を指します。CVSS v4.0の評価でも、後続システムへの影響を表すSC、SI、SAがすべてHighとされています。採点者がどの資産を後続システムとみなしたかは公開されていませんが、Metabaseが接続先データベースの資格情報を保管する製品であることを踏まえると、影響がMetabase単体で完結しないという読み方になります。

CISAのSSVCは、悪用が現に起きており(Exploitation: active)、攻撃の手順を自動化でき(Automatable: yes)、得られる支配力も全面的である(Technical Impact: total)という3拍子がそろった評価です。KEVとEPSSを組み合わせた優先順位付けの考え方は、次の記事で整理しています。

CISAのKEVカタログ(執筆時点で参照した版は2026.08.11、収録1665件)は、CVE-2026-72898について、未認証のリモート攻撃者がMetabaseのアプリケーションデータベースへ任意のSQLを注入し、インスタンスの管理者権限を得られること、そこからアプリケーション設定の変更、接続先データベースに保管された資格情報の窃取、それらの接続を通じて到達できるデータの読み取りとエクスポートが可能になることを記載しています。追加日は2026-08-11、Due Dateは2026-08-14です。この期限はCISAのBOD 26-04にもとづいて米国の連邦文民行政機関へ課されるもので、KEVカタログの説明は、それ以外の組織に対してはカタログを脆弱性管理の優先順位付けの入力として使うよう案内しています。

パスワードリセット経路がSQL注入に変わる機構#

Metabaseの告知は、注入点が/api/session/reset_passwordであることと、影響が1.58以降であることを示していますが、内部の詳細は公開していません。以下は、Wiz Researchがパッチの差分から復元した解析にもとづく説明です。同社は動作するPoCの全体を意図的に伏せており、この記事でも攻撃者が実行できる形のリクエストは扱いません。

Wizは脆弱な版v0.58.22と修正版v0.58.24のJARを比較し、修正の要点として次の形の変更を示しています。変更前はリクエスト由来のuser-idをそのままクエリへ渡していたのに対し、変更後はpos-int?(正の整数か)を確かめ、そうでない場合は利用者の解決を拒否してログへ警告を残す、というものです。この差分から逆に、注入の成立条件が読み取れます。

成立には、言語とライブラリの標準的な挙動が3つ重なっています。

1つ目はClojureのmerge関数です。2つのマップを結合し、後ろのマップの値で上書きしますが、前のマップにある余分なキーを取り除きはしません。脆弱な実装は受信リクエストと認証結果を(merge request (authenticate ...))の形で結合しており、認証が失敗して結果にuser-idが含まれないとき、攻撃者がリクエストへ入れたuser-idがそのまま生き残ります。

2つ目はJSONのキーワード化です。解析時にJSONのキーはClojureのキーワードへ変換されるため、{"user-id": {"raw": "..."}} という本体は {:user-id {:raw "..."}} というマップになります。

3つ目はHoneySQLの:rawです。これはクエリビルダで表現できないSQLを直接埋め込むために用意された正規の機能で、プレースホルダによるパラメータ化を意図的に迂回します。生き残ったuser-idの値が t2/select-one へ渡るとき、本来は整数が来るはずの場所に {:raw "..."} が届き、HoneySQLはこれを「この文字列をそのままSQLとして埋め込め」という指示として解釈します。ここでブラインドSQLインジェクションが成立します。

Wizは、この欠陥がauth_identityモジュールのリファクタで混入し、1.58以降に存在すると記載しています。注入に使えるペイロードはアプリケーションデータベースの種類に依存するとも述べています。Metabaseは既定でH2を使い、本番向けにはPostgreSQL、MySQL、MariaDBが推奨されています。

型が検証されないまま値がクエリ生成器へ届くという構造は、SQLインジェクションの教科書的な形と同じです。違うのは、注入がSQL文字列の連結ではなく、データ構造の取り違えとして起きた点です。OWASPのSQL Injection Prevention Cheat Sheetが第一の防御としてパラメータ化クエリを挙げているのは、値をデータとして扱う経路をコードとして扱う経路から分離するためですが、HoneySQLの:rawのような明示的な迂回口が用意されている場合、その口へ外部入力が届かないことを型で保証する層が別に要ります。

SQLインジェクションそのものの原理と、根本対策としてのプレースホルダの使い方は次の記事で扱っています。

Wiz Researchのブログは、脆弱版v0.58.22と修正版v0.58.24のJARを比較して修正箇所を特定したこと、修正がuser-idをpos-int?で検証する内容であること、Clojureのmergeが余分なキーを残すこととJSONのキーワード化とHoneySQLの:rawが重なって任意のブラインドSQLインジェクションが成立すること、この脆弱性がauth_identityモジュールのリファクタで導入され1.58以降に存在すること、そして完全なPoCは悪用を助長しないため公開を控えることを記載しています。あわせて、クラウド環境の約13パーセントに自社運用のMetabaseが存在し、そのうち約25パーセントがインターネットから完全に到達可能であること、Shodanで約2,500台のMetabaseが把握できること、2026年8月10日正午(UTC)時点で公開のPoCが出回っていることを示しています。

同時に公表された2件のCVEとの切り分け#

8月6日にMetabaseが公開したアドバイザリは3件あり、CVEも3件採番されています。番号を取り違えると対応の判断を誤るため、整理しておきます。

CVE-2026-72899は、公開リンクのUUIDさえ分かれば未認証でも到達できる経路です。CVEレコード側とGHSA側で数値が食い違っており、GHSAはCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:Hで9.6、CISAが採番したCVEレコードはUI:Nとして10.0を付けています。CISAのCSAFに記録されたSSVCでは、2026年8月10日時点でExploitationがnoneであり、CVE-2026-72898とは悪用状況が異なります。とはいえ公開共有を有効にしている組織では、フィールドフィルタを含む公開リンクの棚卸しが必要になります。

CVE-2026-72900は、特別な権限を持たない認証済み利用者が監査用データベースを対象とするネイティブクエリの質問を作り、公開共有を有効にしてそれを実行することで、アプリケーションデータベースの内容を読み出せるというものです。GHSAは、読み出せる内容にセッション記録、パスワードハッシュ、そしてMB_ENCRYPTION_SECRET_KEYが設定されていない場合の平文のデータベース資格情報が含まれると記載しています。Metabaseの公式ドキュメントは、この環境変数を設定すると接続情報が保存時にAES256とSHA512を用いて暗号化され、必要なときに復号されると記載しています。設定していない環境では、接続情報が平文でアプリケーションデータベースに置かれます。

影響を受ける版と更新目標#

Metabaseの版番号は、先頭の0が無償のオープンソース版、1が有償のソース公開版(Enterprise Edition)を表します。それ以降の番号は共通です。公式ドキュメントのversioningの説明にこの規則が書かれています。CVEレコードやCSAFがx.58.0のように書いているのは、両方の系列をまとめて指すためです。Metabaseのブログが「versions 1.58 and above」と書きつつ最小安全版を0.58.24のように示しているのも同じ理由です。

Metabaseのブログが示す最小安全版は次のとおりです。

8月11日に公開されたGHSA-r495-55cx-fjh7は、単一のCVEではなく10項目にわたる強化をまとめたアドバイザリです。利用者由来の値がデータベースへ送るSQLへ埋め込まれないようにするクエリ入力の検証、HoneySQLの依存更新、参照先コンテンツの権限チェック、ヘッダを変えるだけでログイン試行やパスワードリセットの回数制限を回避できた問題の修正、データサンドボックスの抜け、公開共有の実行を管理者権限に限定する変更、SSHトンネルの待ち受けをループバックに限定する変更などが含まれます。執筆時点でCVE番号は付いていません。

したがって、8月6日の告知だけを見て0.58.24へ上げた組織も、8月11日時点では0.58.28が更新目標になります。Docker Hubのタグ更新時刻でも、v0.58.24などが8月5日、v0.58.28などが8月11日に公開されたことが確認できます。

なお、GitHubのアドバイザリ画面が表示する「Affected versions」の上限と「Patched versions」の値はつながっていません。GHSA-vwf4-m7j8-wcjfの58系列の影響範囲は >= x.58.0, < x.58.23 と示される一方、パッチ版は「x.58.24」です。x.58.23がどちらにも現れないため、この表示だけでは扱いを決められません。CISAのCSAFは同じ範囲を >=x.58.0|<x.58.24 としており、x.58.23を影響側に含める保守的な書き方です。自組織の判定は、ベンダーが最小安全版として示した番号以上かどうかで行うのが確実です。

今日確認する手順#

自組織が管理するMetabaseに対する構成確認とログ確認に限った手順を示します。攻撃の再現は行いません。

侵害を疑ったときに最初の数時間で何をどの順で行うかは、次の記事にまとめています。

資格情報のローテーションを事故のたびの手作業にしないための設計は、次の記事で扱っています。

Metabaseの2026年8月6日付のセキュリティ告知は、Metabase Cloudが1.58以降の版に存在する未知のゼロデイを使って攻撃されたこと、攻撃に使われたエンドポイントを直ちに遮断してから脆弱性を特定して修正したこと、Metabase Cloudの利用者はすでに更新済みであること、自社運用の利用者は直ちに更新すべきであることを記載しています。更新後の措置として、core_sessionテーブルの全行削除による全セッションの失効、見覚えのないAPIキーの削除、管理者アカウントの想定外の変更の確認、接続先データベースの資格情報のローテーション、データウェアハウスのログの確認、Metabaseのアクティビティと質問履歴の確認を挙げています。攻撃の並びとしてPOST /api/session/reset_passwordの400とそれに続くGET /api/user/currentの200を示し、暫定の回避策として/api/session/reset_passwordの遮断を案内しています。

公表された被害事例から読み取れること#

複数の組織が、自社のMetabaseインスタンスへの不正アクセスと、アクセスされた情報の範囲を公表しています。どこまでが確認された事実で、どこからが可能性にとどまるかは各社で異なります。以下は各社の公表と、それを伝えた報道にもとづく整理で、当サイトが独自に確認した事実ではありません。

Frameworkについては、Help Net Securityが、同社の通知として攻撃者が氏名、メールアドレス、電話番号、住所、ログイン時のIPアドレスへアクセスしたこと、支払い情報と注文記録は含まれないことを伝えています。BleepingComputerはこれに加え、請求先住所と配送先住所、会社名が含まれ、法人向けの顧客についてはVAT番号とEIN番号も含まれたと報じています。同記事は、Frameworkが接続していたデータベースの資格情報をローテーションしたことにも触れています。

Tallyについては、BleepingComputerが、同社の説明として流出したのはメールアドレスと復元できない形式のパスワードハッシュであり、フォームそのものや回答内容には到達されていないと報じています。

n8nは、2026年8月3日に不正な活動があり、8月6日に通知を受け、8月8日に最初の公表を行ったとしています。8月11日のフォレンジック調査の更新では、全利用者を通じて氏名とメールアドレスを含む136件の記録がアクセスされたこと、そのうち5件には氏名、ユーザー名、メールアドレス、bcryptでハッシュ化されたパスワードが含まれていたことを記載しています。あわせて過去の不具合により少数のn8n Cloudアカウントのパスワードが平文で保管されていたことを公表し、ベルリンのデータ保護監督機関へ届け出たとしています。

Checklyは、2026年8月3日に攻撃者が同社のMetabase Cloudインスタンスで管理者セッションを取得し、アクセスは約26分間で読み取りのみだったと公表しました。露出しうる情報として、チェック設定にハードコードされた資格情報、OpenTelemetryのAPIキーのハッシュ、チェックごとの環境変数を挙げる一方、Checklyのシークレット機能に保存された資格情報は保存時に暗号化され実行時にのみ注入されるため平文で露出していないと述べています。

AnacondaはKilo Codeの利用者に関わる侵害として、発生時間帯を8月2日の約4時間とし、氏名、メールアドレス、請求先住所などが含まれ、支払いカード情報は含まれないと公表しました。影響はKilo Codeの利用者に限られ、Slack連携のトークンは無効化したとしています。

これらの公表に共通しているのは、侵入口が自社開発のコードではなく、業務のために導入したBIツールだったという点です。自社のアプリケーションをどれだけ丁寧に作っても、隣に置いた製品の欠陥は塞げません。IPAの「情報セキュリティ10大脅威 2026」でも、サプライチェーンや委託先を経由した攻撃は組織向けの脅威として上位に挙げられています。

個人データの漏えいが疑われたときの報告義務と本人通知の判断は、次の記事で整理しています。

もう1点、公表内容を読むうえで押さえておきたいのは、侵害時間の短さが被害の小ささを意味しないことです。Checklyの事例では26分の読み取りアクセスで、チェック設定に埋め込まれていた資格情報が露出範囲に入りました。BIツールが握っているのは集計結果だけでなく、集計元へ到達するための鍵でもあります。

社内向けBIを直接インターネットへ出さない設計#

この事案の技術的な核はSQLインジェクションですが、被害の規模を決めたのは別の要因です。Metabaseが未認証で到達できる状態でインターネットに置かれていたこと、そしてMetabaseの背後に接続先データベースの資格情報が集まっていたことです。

BIツールは業務の性質上、社外の関係者や在宅勤務の従業員が使うため、公開したくなる動機が強い部類に入ります。しかし公開の方法には幅があります。アプリケーション自身の認証だけを頼りにインターネットへ直接出す構成は、その認証に穴が空いた瞬間に何も残りません。認証プロキシや、接続元の制限、機器と利用者の状態を毎回評価する仕組みを前段に置き、対象のエンドポイントを含むすべての経路へその制御を適用できていれば、アプリケーション側の未認証エンドポイントが直接叩かれるリスクを下げられます。迂回できる経路や除外設定が残っていれば効果はそのぶん落ちます。NIST SP 800-207は、ネットワークの位置を信頼の根拠にせず、リソースへのアクセスごとに認証と認可を行う設計を示しています。

チェック項目のうち、被害の範囲を抑える手立てとして効きやすいのが接続先アカウントの権限を絞ることです。BIツールが読み取り専用で、参照範囲も限定されていれば、管理者権限を奪われたときに持ち出される範囲がそのぶん狭まります。逆に、便宜のために強い権限のアカウントを1つ登録している構成では、BIツールの脆弱性がそのままデータ基盤全体の脆弱性になります。

まとめ#

CVE-2026-72898は、未認証で到達できるパスワードリセットのエンドポイントにSQLを注入され、Metabaseの管理者権限を奪われる脆弱性です。CVSSはv3.1とv4.0のいずれも10.0で、CISAは2026年8月11日にKEVカタログへ追加しました。修正より先に悪用が始まっており、CVE番号が付いたのは公表から4日後でした。

対処は版を上げることです。8月6日には系列ごとの最小安全版(0.58.24、0.59.21、0.60.17、0.61.11、0.62.9、0.63.5)が示され、8月11日にはさらに追加のハードニングを含む版(0.58.28、0.59.25、0.60.21、0.61.15、0.62.13、0.63.10)が公開されました。更新目標は、いま動かしている系列に対応する後者の番号に合わせるのが確実です。すぐに更新できない場合の暫定策として、Metabaseは/api/session/reset_passwordの遮断を案内しています。

そして、更新だけでは終わりません。管理者権限を得た攻撃者が手を伸ばせるのは、Metabaseが保管している接続先データベースの資格情報です。すでに窃取されたものとして扱い、入れ替えることが前提になります。セッションの失効、APIキーと管理者アカウントの棚卸し、接続先資格情報のローテーション、接続先側のアクセスログの確認までを行って、初めて一連の作業が完了します。BIツールは、社内のデータへ到達する鍵をまとめて預かる位置に置かれた仕組みです。その前提で公開範囲と権限を組み直すことが、この事案から引き出せる要点になります。