>
>
公開日
metabase 脆弱性への対応を担う情報システム部門向けに、問題の概要から外部到達性、バージョンと更新、管理者アカウント、接続先データベースの権限、ログ調査まで整理します。開発元の公式発表を根拠に、更新だけでは判断できない点や侵害が疑われる場合の対応を解説。2026年10月22日時点の情報です。
Metabaseの脆弱性で確認すること
BIツールのMetabaseに、認証なしで管理者権限を取られるおそれのあるSQLインジェクションの脆弱性（CVE-2026-72898）が見つかり、開発元は2026年8月6日に修正版を公開しました。開発元は実際の悪用（ゼロデイ攻撃）を確認しており、JPCERT/CCは10月8日の注意喚起で、国内で相次ぐ不正アクセスの攻撃類型の一つとしてこの脆弱性を挙げています。
本記事のポイント
影響を受けるのはMetabase 58系以降で、系列ごとの修正版への更新が必要です。
パスワードリセットAPI（/api/session/reset_password）がインターネットから到達できた場合は、更新後も侵害の有無を調べます。
侵害が疑われる場合は、セッションの失効、APIキーと管理者アカウントの確認、接続先データベースの認証情報の変更を行います。
対象は、社内でMetabaseを運用している情報システム部門の担当者・管理者です。製品の概要や連携については「Metabaseとは」で紹介しています。本記事は脆弱性への対応に絞って扱います。
本記事の情報は2026年10月22日時点のものです。
Metabaseの脆弱性で問題になった点
CVE-2026-72898は、認証なしで呼び出せるエンドポイントを通じて、Metabase自身のアプリケーションデータベースに不正なSQLを実行させる脆弱性です（開発元のセキュリティアドバイザリ、深刻度Critical）。SQLインジェクションとは、入力を通じて意図しないデータベース処理を実行させる攻撃です。
悪用されると何が起きるか
開発元によると、攻撃者はMetabaseの管理者権限を取得でき、そこから設定の変更、接続先データベースの保存済み認証情報の窃取、接続先から参照できるデータの閲覧・エクスポートが可能になります。開発元は2026年8月27日の経緯の説明で、実際の攻撃では管理者のセッションを作り、APIキーを発行してテーブルを一括でダウンロードしていたと説明しています。
同じ日には、公開共有したダッシュボードを経由する別のSQLインジェクション（CVE-2026-72899、GHSA-r8h2-qpfx-mx59）も公表されています。修正版は共通です。
社内向けのBIツールも対象になる
JPCERT/CCは2026年10月8日の注意喚起（10月9日更新）で、BIツールや従業員向け管理システムなど、不特定多数からのアクセスを想定していないシステムが被害に遭い、内部の情報が漏えいするケースもあるとして、こうしたシステムの点検も求めています。攻撃類型の「ケースC」として挙げているのがこの脆弱性で、詳細は8月14日の注意喚起にまとめられています。
「社員しか使わない」という運用と、「外部から接続できない」という構成は別のものです。次章で、自社のMetabaseに外部から到達できるかを確かめます。
自社のMetabaseへの外部到達性
開発元とJPCERT/CCが判断の基準にしているのは、パスワードリセットAPI（/api/session/reset_password）がインターネットから到達できる状態だったかどうかです。到達できた場合は、更新だけで対応を終えず、侵害の有無を調べるよう求めています（JPCERT/CCの注意喚起）。すぐに更新できない場合の一時的な回避策は、ネットワーク機器などでこのエンドポイントへのアクセスを遮断することです。
社内向けであっても、外部から到達できる構成はあり得ます。利用者に案内しているURLから稼働先までの経路を、構成資料と接続結果の両方で確かめます。
接続経路と公開設定の把握
管理対象のURL、公開側の中継設定、ネットワークのアクセス制限が対応しているかを整理します。ここでいう中継設定とは、外部から受けた通信をBIツールの稼働先へ転送する設定です。
構成資料や設定を参照できる場合は、利用者に案内しているURLから稼働先までの経路をたどり、どこで接続元を制限しているかを記録します。別の公開URLや中継先が管理資料にある場合は、それらも照合対象に含めます。URLの一覧と設定が一致しなければ、非公開とは扱わず、構成管理担当へ差分の調査を引き継ぎます。
ログイン画面の有無と、ネットワーク上の到達性は別の判断項目です。ログイン画面が表示された場合は、その接続元から画面まで到達できたと記録し、認証があることを理由に外部アクセス制限の確認を省略しません。
許可された範囲での到達性確認
接続確認は、自社が管理し、実施許可のある環境と経路に限定します。対象URLと接続元を事前に定め、通常の画面アクセスの範囲で結果を記録する運用にします。
認証の突破、脆弱性の試行、管理範囲を超える広範な探索は行いません。確認作業によって業務アクセスへ影響する可能性がある場合は、変更担当と実施時間、対象、停止条件を調整してから進めます。
結果には接続元、対象URL、確認日時、表示内容を残します。一つの端末から接続できなかった結果だけで、すべての外部経路が閉じているとは判断しません。接続失敗の理由を設定と照合できなければ「制限済み」ではなく「判定保留」とし、担当者へ調査を引き継ぎます。
到達性に応じた対応の分岐
外部到達性の判断では、接続結果と構成上の根拠を組み合わせ、利用制限と更新確認の進め方を分けます。
外部到達性の判断フロー
管理対象のURLと接続経路を整理します。経路が不明な場合は非公開と扱わず、構成管理担当へ資料と接続結果を渡して調査を引き継ぎます。
許可された外部の接続元から到達できる場合は、業務で必要な利用者・接続元を整理し、利用範囲の制限と更新状況の把握を並行して進めます。
接続できず、想定する外部経路にアクセス制限が適用されていることも設定で確認できた場合は、確認済みの範囲を記録して更新確認へ進みます。接続失敗だけでは、この分岐に進めません。
制限を変更する場合は、変更担当と必要な業務アクセスへの影響を確認します。変更後は許可対象の利用を維持できるかも確かめ、制限による業務停止を避けます。
次章では、外部到達性とは切り離してバージョンと更新状況を判定します。
▲ 外部からの到達性確認と接続結果に応じた対応手順の判断フロー
バージョンと更新状況の確認
稼働中のバージョンを開発元が示す修正版と照合し、修正版より前なら更新します。バージョンは、画面右上の歯車（またはグリッド）アイコンから「About Metabase」を開くと確認できると開発元は案内しています。
影響を受けるバージョンと修正版
開発元によると、影響を受けるのは58系以降です。58系より前のバージョンは影響を受けません。Metabase Cloudは開発元が対策済みです（開発元の告知、JPCERT/CCの注意喚起）。
系列 | 修正版（これより前は影響あり） |
|---|---|
63系 | x.63.5 |
62系 | x.62.9 |
61系 | x.61.11 |
60系 | x.60.17 |
59系 | x.59.21 |
58系 | x.58.24 |
「x」の部分は、オープンソース版が0、Enterprise版が1です。たとえば0.58.6を使っている場合は0.58.24以降に更新します。検証環境や部署ごとに立てたインスタンスがある場合は、それぞれ確認します。
修正とその後のセキュリティ強化
開発元は8月27日の経緯の説明で、この脆弱性とは別に、防御を広く見直すセキュリティ強化の第1弾をバージョン63.13で出したと述べています。上の修正版はこの脆弱性を直す最低限の版で、63.13は追加の強化です。更新先を選ぶときは、まず修正版以上であることを確認し、強化版まで上げるかは変更の影響を見て決めます。
更新の進め方
更新前に、Metabaseのアプリケーションデータベースのバックアップと、切り戻しの手順を用意します。
更新後は、稼働している版が予定どおりか、ログインやダッシュボードの表示など業務で使う操作ができるかを確かめます。
切り戻しで修正前の版に戻る場合は、エンドポイントの遮断を続けたまま再更新の準備をします。
▲ 稼働中バージョンの照合から更新後の動作確認までの手順
管理者アカウントと連携データベースの権限
Metabaseの管理者権限と、連携するデータベースの権限は別々に点検します。Metabase側では誰が管理できるか、データベース側では接続用アカウントが何を操作できるかを整理し、それぞれの管理担当者と権限の妥当性を判断します。
管理者アカウントと変更履歴
管理者アカウントは、利用者・業務上の必要性・作成や権限変更の経緯を対応させて評価します。この脆弱性は管理者権限の取得につながるため、心当たりのない管理者の追加や権限変更がないかを確認します。現在の管理者一覧だけでなく、その権限が付与された理由まで点検対象に含めます。
棚卸しでは、次の項目をアカウントごとにまとめると判断に使えます。変更記録を取得できる場合は申請内容と照合し、取得できない場合は、残っている申請書や作業記録、担当者への聞き取りを分けて記載します。
アカウントの利用者と管理責任者
管理者権限が必要な業務と継続利用の理由
作成・権限変更の日時、実施者、承認や申請の記録
説明できない点と調査を引き継ぐ担当者
所有者と変更理由を説明できれば、現在も管理権限が必要かを評価します。説明できない管理者や変更がある場合は、不正と即断せず、関連記録を保全して調査担当へつなげます。
接続先データベースの操作権限
接続用アカウントは、参照できるデータと実行できる操作を業務要件に照合します。Metabase内の管理者を整理しただけで点検を終えず、データベース管理担当者と接続先の許可範囲を突き合わせます。
業務に必要なデータベースやテーブル、参照・書き込み・管理操作の要否を整理し、実際の付与権限と比較します。接続情報を台帳に記載する場合も、パスワードそのものではなく、保管先と管理担当を記録する運用にします。
参照だけで集計業務が成立する場合は、不要な書き込みや管理権限を縮小対象にします。
追加の操作が必要な場合は、対象データ、必要な理由、承認者、実施担当を明確にして権限を評価します。
必要性を説明できない権限がある場合は、利用状況と影響を調べ、縮小の可否を保留事項として管理します。
権限見直しと業務影響
権限の縮小や認証情報の変更は、既存の集計や接続を止める可能性を踏まえて実施します。変更前に利用先、影響する集計、作業担当、変更後の動作確認方法を整理できれば、通常の変更作業として進めます。
不審なアカウントや接続情報がある場合は、状況や記録を残さず削除・変更して終えてはいけません。侵害が疑われるなら、調査担当と被害拡大を抑える封じ込めと証拠保全を調整し、実施時刻・対象・判断理由を残します。緊急対応が必要な場合も、記録を取る担当と操作する担当を決めて進めます。
侵害の可能性がある場合に開発元が求める対応
パスワードリセットAPIが公開状態だった場合、開発元は更新後に次の対応を求めています（開発元のセキュリティアドバイザリ）。
すべてのユーザーセッションを失効させる（アプリケーションデータベースのcore_sessionテーブルの全行を削除）
APIキーを確認し、心当たりのないものを削除する
管理者アカウントに予期しない変更がないか確認する
接続先データベースの認証情報を変更する
データウェアハウス（接続先データベース）のログで不正なアクセスがないか確認する
Metabaseのアクティビティとクエリ履歴で不審な操作がないか確認する
実際の攻撃ではAPIキーを発行してデータを持ち出していたため、APIキーの確認は管理者アカウントの確認と同じ重さで扱います。接続先データベースの認証情報を変更するときは、同じ情報を使う接続先と再設定の担当を決め、変更後に接続と集計の結果を確かめます。
▲ Metabase管理者権限と接続先データベース権限の点検項目の比較
ログによる侵害の痕跡の確認
更新が終わっていても、更新前に侵害されていないかは、ログで別に確かめます。「調べた範囲で痕跡が見つからない」ことと、「調べる記録がない」ことは区別して記録します。
開発元が示す攻撃のパターン
開発元とJPCERT/CCによると、確認された攻撃では、パスワードリセットAPIへのPOST（HTTPステータス400）の直後に、ログイン中のユーザー情報を取得するAPI（GET /api/user/current、ステータス200）へのアクセスが続いていました。Metabaseやネットワーク機器のログでこの並びが見つかった場合、侵害された可能性が高いとされています（JPCERT/CCの注意喚起）。
JPCERT/CCは、10月8日の注意喚起の「ケースC」で、悪用に使われた送信元IPアドレスとUser-Agentの例も公開しています。照合する値はJPCERT/CCの注意喚起と開発元の告知から直接取ってください。IPアドレスは8月上旬〜9月上旬に悪用されたもので、調査時点では正規の利用者が使っている可能性もあると注記されています。一致しただけで侵害と断定せず、前後のアクセスと合わせて判断します。
集める記録
Metabaseのアクセスログ、またはその前段のリバースプロキシ・ロードバランサーのログ
Metabaseのアクティビティとクエリ履歴
管理者アカウントとAPIキーの作成・変更の記録
接続先データベース（データウェアハウス）のログ
開発元が修正版を出したのは2026年8月6日で、それ以前から悪用されていた情報もあります（JPCERT/CC）。少なくとも8月上旬以降の記録を対象にし、保存期間が短いものは先に保全します。取得できなかった期間は「未確認」として残します。
不審な記録が見つかったら
関連する記録を保全したうえで、前章の「開発元が求める対応」を進めます。接続先のデータが持ち出された可能性がある場合は、扱っていたデータの種類と範囲を整理し、個人データが含まれるなら法務・個人情報管理責任者と報告の要否を判断します。
まとめ
Metabaseの脆弱性（CVE-2026-72898）への対応は、次の3段階で進めます。
更新：58系以降を使っているなら、系列ごとの修正版（x.58.24〜x.63.5）以上に更新します。すぐに更新できなければ、/api/session/reset_passwordへのアクセスを遮断します。
到達性の確認：パスワードリセットAPIがインターネットから到達できる状態だったかを確かめます。社内向けのBIツールでも確認は省きません。
侵害調査：到達できた場合は、ログで攻撃のパターンとIoCを照合し、セッションの失効、APIキーと管理者アカウントの確認、接続先データベースの認証情報の変更を行います。
最新の情報は開発元の告知とJPCERT/CCの注意喚起で確認してください。
まとめ
Metabase 58系以降を使っている場合は、系列ごとの修正版へ更新し、パスワードリセットAPI（/api/session/reset_password）がインターネットから到達できたかを確かめます。
今日中に、稼働しているすべてのMetabaseのバージョンを確認し、修正版より前なら更新します。すぐに更新できなければ、このエンドポイントを遮断します。
エンドポイントが外部から到達できた場合は、ログで攻撃のパターンを照合し、セッションの失効、APIキーと管理者アカウントの確認、接続先データベースの認証情報の変更を進めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
