※本稿は、2026年8月30日時点で公表されているJPCERT/CCおよびMetabaseの公式情報に基づいています。脆弱性の対象バージョンや修正版は更新される可能性があるため、公開前に最新情報を再確認してください。

※脆弱性の内容、対象バージョン、開発元が案内する対処は公表資料に基づく事実です。一方、公開範囲の分類、台帳項目、確認頻度などは、中小企業向けの実務上の提案です。

「これは社内で売上を見るためのダッシュボードなので、外部からは見えません」

その説明は、本当に確認した結果でしょうか。

BIツールやダッシュボードは、売上、在庫、顧客動向、製造実績などをグラフで表示するために利用されます。社内向けの画面であることから、一般的なWebサイトよりも安全だと思われがちです。

しかし、「社内向けに利用している」ことと、「インターネットからアクセスできない」ことは同じではありません。

実際には、次のような状態になっている場合があります。

  • 管理画面がインターネットへ公開されている
  • URLを知っていれば誰でも見られる公開リンクが残っている
  • Webサイトへ認証なしで埋め込まれている
  • 開発・検証用の環境が公開されたままになっている
  • VPNを廃止した後も、以前のアクセス設定が残っている
  • 管理者が把握していないAPIキーが利用されている

さらに、BIツールは単にグラフを表示するだけではありません。

多くの場合、社内のデータベースやデータウェアハウスへ接続するための認証情報を持っています。BIツールが侵害されると、ダッシュボードだけでなく、その先にあるデータへ影響が広がる可能性があります。

2026年8月、BIツール「Metabase」に深刻なSQLインジェクションの脆弱性が公表されました。

今回の事案は、BIツールを「便利な集計画面」ではなく、社内データベースへ接続する重要なシステムとして管理する必要があることを示しています。

Metabaseで何が起きたのか

Metabaseは2026年8月6日、同製品にSQLインジェクションの脆弱性が存在することを公表しました。

JPCERT/CCによると、CVE-2026-72898を悪用した場合、遠隔の第三者が認証なしで細工したリクエストを送信し、Metabaseが利用するアプリケーションデータベースに不正なSQLクエリを実行できる可能性があります。

その結果、攻撃者がMetabaseの管理者権限を取得する可能性があります。

Metabaseは、この脆弱性を利用したゼロデイ攻撃が確認されていると説明しています。JPCERT/CCも、海外の複数組織が被害を公表しており、概念実証コードとみられる情報も確認されているとして、早急な対応を呼び掛けました。

Metabaseが公表した影響は、管理画面へ不正にログインされることだけではありません。

管理者権限を取得した攻撃者は、次のことが可能になるおそれがあります。

  • Metabaseの設定を変更する
  • 接続先データベースの認証情報を取得する
  • その認証情報でアクセス可能なデータを読み取る
  • データを外部へ出力する

つまり、影響範囲はMetabaseの画面内にとどまらず、接続先のデータベースへ広がる可能性があります。

なお、Metabaseは同社のクラウド環境が未知の脆弱性を利用した攻撃を受けたことを公表していますが、個々の利用者について情報漏えいが発生したと一律に公表しているわけではありません。

攻撃を受けたという事実と、全ての利用者に具体的な被害が発生したということは分けて考える必要があります。

対象となるバージョン

JPCERT/CCが2026年8月14日に公表した対象バージョンと、最低限必要な修正版は次のとおりです。

系列影響を受けるバージョン修正を含むバージョン
63系x.63.5より前x.63.5以降
62系x.62.9より前x.62.9以降
61系x.61.11より前x.61.11以降
60系x.60.17より前x.60.17以降
59系x.59.21より前x.59.21以降
58系x.58.24より前x.58.24以降

Metabaseは、58系より前のバージョンはCVE-2026-72898の影響を受けないとしています。また、Metabase Cloudについては、開発元が対策済みと説明しています。

ただし、「この脆弱性の対象外」であることと、「古いバージョンを使い続けても安全」であることは同じではありません。

古い系列では別の脆弱性やサポート終了の問題がある可能性があります。単に対象外であることを理由に更新を見送るのではなく、現在利用している系列のサポート状況と最新版を確認してください。

公開ダッシュボードを経由する別の脆弱性も公表された

同じ2026年8月6日には、CVE-2026-72899という別のSQLインジェクションの脆弱性も公表されています。

こちらは、公開共有されたカードやダッシュボードに特定のフィルター項目が含まれている場合、認証されていない第三者が不正なSQLを実行し、Metabaseの管理者権限を取得する可能性があるというものです。

攻撃には公開リンクのURLに含まれる識別情報が利用される可能性があります。

Metabaseの公式アドバイザリでは、公開共有機能が既定で有効であり、対象のリンクを公開するだけで攻撃条件が成立し得ると説明されています。修正版はCVE-2026-72898と共通です。

CVE-2026-72898とCVE-2026-72899は別の脆弱性です。

前者は認証なしで利用できるパスワードリセット関連のエンドポイント、後者は公開共有されたダッシュボード等が主な確認対象になります。

「管理画面にパスワードがあるから大丈夫」と考えるだけでは不十分です。

なぜBIツールの侵害がデータベースまで広がるのか

Metabaseでは、二種類のデータベースを分けて考える必要があります。

種類主な内容
アプリケーションデータベース利用者、質問、ダッシュボード、設定、接続情報など、Metabaseを動かすための情報
接続先データベース売上、在庫、顧客、会計、製造など、分析対象となる業務データ

今回の脆弱性で直接不正なSQLを実行される可能性があるのは、Metabaseのアプリケーションデータベースです。

しかし、そこで管理者権限を取得されると、接続先データベースの認証情報を窃取され、その認証情報で閲覧できる業務データまでアクセスされる可能性があります。

攻撃経路は、次のようにつながります。

インターネットからアクセス可能なMetabase
↓
脆弱性を悪用して管理者権限を取得
↓
接続先データベースの認証情報を取得
↓
データベースへアクセス
↓
業務データを閲覧・出力

この構造から分かるのは、ダッシュボードが「閲覧専用」に見えても、その裏側の接続アカウントまで閲覧専用とは限らないということです。

BIツールにデータベース管理者と同等の権限を与えている場合、侵害時の影響が大きくなります。

「社内向け」と「社内からしか見えない」は違う

社内会議で利用している画面であっても、技術的にはインターネットからアクセスできる場合があります。

次の状態を区別してください。

公開状態説明主な確認事項
一般公開認証なしで誰でも閲覧できる公開する情報の内容、出力機能
URL限定公開URLを知る人が閲覧できるURL流出、公開期限、無効化方法
外部認証付き顧客や取引先がログインして閲覧する認証、権限、利用者ごとのデータ分離
社内認証付き社員がSSO等でログインする退職者、MFA、権限設定
VPN等に限定社内ネットワークやVPN経由のみVPN利用者、機器設定、例外公開
管理ネットワーク限定管理者だけが特定経路からアクセスする管理者端末、接続元制限、ログ

社内で使っているからといって、自然に「社内認証付き」や「VPN限定」になるわけではありません。

実際のURL、ファイアウォール、リバースプロキシ、ロードバランサー、クラウドのアクセス制御などを確認する必要があります。

簡単な確認方法の一つは、会社のWi-Fiを切り、スマートフォンの携帯回線から対象URLへアクセスすることです。

ただし、認証画面が表示されたからといって安全が確認できたとは限りません。今回の脆弱性のように、ログイン画面とは別のAPIが認証なしで利用できる場合があります。

外部公開の有無は、アプリケーションの画面だけでなく、ネットワーク設定やアクセスログも含めて確認してください。

公開リンクはアクセス制御ではない

Metabaseでは、管理者が質問、ダッシュボード、文書などについて公開リンクを作成できます。

公開リンクには認証や認可の仕組みがなく、URLを知っている人はデータを閲覧できます。質問については、公開リンクからCSV、XLSX、JSON形式で結果を出力することもできます。

したがって、公開リンクを次のように扱うべきではありません。

  • URLが長いので推測されない
  • 社内チャットにしか送っていない
  • 検索サイトには掲載していない
  • フィルターを非表示にしている
  • 顧客ごとに異なるURLを送っている

URLは、メールの転送、チャットへの転載、ブラウザ履歴、画面共有、誤送信などによって第三者へ伝わる可能性があります。

また、Metabaseは、公開埋め込みでフィルターを非表示にしても、URLのパラメーターを削除することで、元のフィルターなしのデータを閲覧できる場合があると説明しています。

画面上でフィルターを隠すことは、データへのアクセス制御にはなりません。

公開共有を無効にしただけでは、古いリンクが消えない場合がある

Metabaseの管理画面では、公開共有機能そのものを無効化できます。

ただし、公式資料では、公開共有を一度無効にした後、再び有効にすると、個別に無効化していない過去の公開リンクが再び利用できると説明されています。

そのため、公開共有を止める場合は、設定をオフにするだけでなく、現在有効な公開リンクを一覧で確認し、不要なリンクを個別に無効化してください。

公開リンク台帳には、少なくとも次の項目を記録します。

管理項目記録する内容
対象質問、ダッシュボード、文書など
表示するデータ売上、顧客、在庫、稼働実績など
公開目的顧客向け、社内共有、Web掲載など
作成者公開リンクを作成した管理者
承認者データ公開を承認した責任者
公開日リンクを作成した日
公開期限いつまで必要か
出力可否CSV等のダウンロードが可能か
個人情報等個人情報、営業秘密等を含むか
確認日最後に公開の必要性を確認した日
無効化日公開を終了した日

公開期限を設定できない仕組みの場合でも、台帳側で見直し日を管理します。

今回の脆弱性への対応手順

ここからは、2026年8月時点の公式情報を基にした確認手順です。

1．Metabaseを利用しているか確認する

最初に、自社でMetabaseを利用しているか確認します。

公式の分析環境だけでなく、次のような環境も対象です。

  • 部署が独自に構築した環境
  • データ分析担当者の検証環境
  • 開発会社が構築した環境
  • Dockerコンテナで稼働している環境
  • クラウド上の仮想サーバー
  • 以前利用していた旧環境
  • 顧客向けサービスへ埋め込んだ環境

「情報システム担当者は使っていない」という回答だけで終わらせず、サーバー、クラウド、DNS、コンテナ、契約情報などから確認します。

2．セルフホストかMetabase Cloudか確認する

Metabase Cloudについては、開発元が修正済みと説明しています。

一方、自社サーバー、レンタルサーバー、IaaS、Dockerなどで動かしているセルフホスト環境は、自社または委託先で更新する必要があります。

自社で管理しているつもりがなくても、制作会社や開発会社がセルフホスト版を構築している場合があります。

契約先へ、次のように具体的に確認してください。

当社が利用しているMetabaseは、Metabase Cloudですか。それとも自社・御社管理のサーバーで動くセルフホスト版ですか。

3．バージョンを確認して更新する

Metabaseの管理画面から現在のバージョンを確認し、対象バージョンであれば、該当系列の修正版以上へ更新します。

ただし、修正版として示されたバージョンは最低限の基準です。実際には、利用している系列の最新ポイントリリースと、その後に公開されたセキュリティ情報を確認してください。

更新前には、アプリケーションデータベースや設定のバックアップ、復旧方法、停止時間、接続先への影響を確認します。

Metabaseのアプリケーションデータベースには、質問、ダッシュボード、コレクションなどの運用情報が保存されるため、更新失敗に備えたバックアップが必要です。

4．直ちに更新できない場合は一時的に遮断する

CVE-2026-72898について、MetabaseとJPCERT/CCは、直ちに更新できない場合の一時的な回避策として、次のエンドポイントをネットワーク機器などで遮断するよう案内しています。

/api/session/reset_password

これは更新の代わりとなる恒久対策ではありません。修正版の適用までの一時的な対応です。

CVE-2026-72899については、修正版を適用できない場合、公開共有を無効にするか、該当するフィルターを含む公開リンクを取り下げる方法が案内されています。

5．外部公開されていた場合は侵害の有無を調べる

CVE-2026-72898の影響を受けるエンドポイントがインターネットからアクセス可能だった場合、更新だけで対応を終えてはいけません。

Metabaseが確認した攻撃では、次のアクセスが続けて記録されるパターンが示されています。

  1. POST /api/session/reset_passwordへのアクセスでHTTPステータスコード400
  2. GET /api/user/currentへのアクセスでHTTPステータスコード200

Metabaseやリバースプロキシなどのログでこの組合せが確認された場合、侵害されている可能性が高いとされています。

ただし、このパターンが見つからなかったことだけで、安全だと断定できるわけではありません。

ログが保存されていない、保存期間が短い、対象となる機器のログを確認していないといった可能性があります。

更新後に確認する六つの項目

Metabaseは、対象エンドポイントを公開していた場合や侵害の可能性がある場合、更新後に次の対応を行うよう案内しています。

  1. 全ての利用者セッションを無効化する
  2. APIキーを確認し、見覚えのないものを削除する
  3. 管理者アカウントに不審な変更がないか確認する
  4. 接続先データベースの認証情報を変更する
  5. データウェアハウスのログを確認する
  6. Metabaseの利用履歴やクエリ履歴を確認する

これらは「念のための一般的な推奨」ではなく、Metabaseが今回の脆弱性への対処として明示している内容です。

特に注意したいのは、接続先データベースの認証情報の変更です。

Metabaseの管理者パスワードだけを変更しても、接続先データベースのIDとパスワードが窃取されていれば、攻撃者がMetabaseを経由せずにデータベースへ接続する可能性があります。

認証情報を変更した後は、Metabase側の接続設定も更新し、正常に接続できることを確認します。

データベースの接続権限を見直す

Metabase公式資料では、接続先データベースについて、専用の利用者を作成し、分析に必要なスキーマやテーブルへ最低限の読み取り権限だけを与える構成が推奨されています。

書込みが必要な機能を利用する場合は、通常の読取り接続とは別に、書込み用の接続や権限を分ける方法が案内されています。

例えば、次のように見直します。

避けたい状態見直し例
データベース管理者のIDで接続しているMetabase専用のIDを作成する
全データベースを閲覧できる必要なデータベースだけに限定する
全スキーマを閲覧できる分析に必要なスキーマだけに限定する
読取りと書込みを同じIDで行う読取り用と書込み用を分ける
削除権限まで付与している不要なINSERT、UPDATE、DELETE権限を外す
複数のBIツールで同じIDを共有するツールごとに専用IDを作る
担当者不明のIDを使っている責任者、用途、更新日を台帳で管理する

BIツールの画面でデータを変更しないからといって、データベースの接続アカウントも読取り専用とは限りません。

実際の権限は、データベース側で確認する必要があります。

接続情報の暗号化も確認する

セルフホスト版Metabaseでは、MB_ENCRYPTION_SECRET_KEYを設定することで、アプリケーションデータベースに保存される接続先データベースの認証情報を暗号化できます。

既存の接続については、暗号化キーを設定しただけではなく、各接続設定を保存し直す必要があると公式資料に記載されています。

自社で技術的な設定を行っていない場合は、保守事業者へ次の点を確認してください。

  • 接続情報の暗号化を有効にしているか
  • 既存の接続情報も暗号化されているか
  • 暗号化キーをどこで管理しているか
  • バックアップと暗号化キーを同じ場所に置いていないか
  • キーを変更する手順があるか
  • 担当者が退職した場合も復旧できるか

ただし、保存時の暗号化を設定していても、稼働中のMetabaseが接続先データベースを利用できる以上、管理者権限を奪われた場合の影響がなくなるわけではありません。

暗号化、接続権限の最小化、認証情報の定期変更、外部公開の制限を組み合わせる必要があります。

管理者アカウントを増やしすぎない

Metabaseの管理者は、管理画面の設定を変更できるだけでなく、Metabaseに接続されたデータへ制限なくアクセスできます。

そのため、管理者グループへ追加する利用者は慎重に選ぶ必要があります。

次のような管理者アカウントが残っていないか確認してください。

  • 退職した社員
  • 異動して管理業務を行っていない社員
  • 開発を完了した外部事業者
  • 個人名ではなく用途不明の共用アカウント
  • テスト時に作成したアカウント
  • 実際の利用者を確認できないアカウント

管理者権限が必要なのは、ダッシュボードを閲覧する人ではありません。

一般利用者、ダッシュボード作成者、データ管理者、システム管理者を分け、それぞれに必要な権限だけを与えます。

APIキーにも所有者と利用目的を設定する

MetabaseのAPIキーは、プログラムからMetabaseのAPIへアクセスするために利用できます。

APIキーには、割り当てられたグループと同じ権限が与えられます。したがって、広い権限を持つグループへ割り当てられたAPIキーが漏えいした場合、影響も大きくなります。

APIキー台帳には、次の項目を記録します。

項目内容
キーの名称用途が分かる名前
利用システムどのプログラムが使うか
所有者業務上の責任者
技術担当者更新や停止を行う人
権限グループどの権限が付与されているか
作成日キーを作成した日
最終利用日直近で利用された日
更新日最後に再生成した日
有効期限自社で定めた見直し期限
停止方法無効化した場合の影響と手順

APIキーそのものを一般的な台帳へ記載してはいけません。

秘密情報は専用の管理場所へ保存し、台帳には保管場所と管理責任者を記録します。

確認すべきログはMetabaseだけではない

今回のような事案では、一つのログだけを確認しても全体像が分からない場合があります。

確認対象の例は次のとおりです。

ログ主に確認する内容
Metabaseログエラー、APIアクセス、設定変更
Metabaseの利用・クエリ履歴不審な閲覧、クエリ、ダウンロード
リバースプロキシ・Webサーバーログ外部からのアクセス元、URL、応答コード
WAF・ロードバランサーログ攻撃検知、遮断、転送先
クラウド監査ログ設定変更、管理画面操作
認証基盤ログ不審なログイン、管理者追加
データベースログ不審な接続、クエリ、データ出力
VPN・アクセス制御ログ社外からの接続経路

Metabaseのログは、管理画面の「Admin → Tools → Logs」から確認・ダウンロードできます。セルフホスト環境では、サーバー側にもログが出力されます。

ただし、必要な期間のログが残っているかは、サーバーやサービスの設定によって異なります。

インシデントが起きてから「ログが3日分しか残っていなかった」と気付かないよう、保存場所、保存期間、時刻設定、確認担当者を平時に決めてください。

BIツール台帳を作る

Metabaseに限らず、Power BI、Tableau、Looker、Redash、Grafanaなど、ダッシュボードや分析画面を提供するシステムは、まとめて台帳管理することが重要です。

台帳には、少なくとも次の項目を記載します。

管理項目記載内容
製品・サービス名Metabaseなど
利用目的売上分析、製造実績、顧客向け表示など
URL・設置場所ドメイン、サーバー、クラウド環境
提供形態SaaS、セルフホスト
バージョンセルフホストの場合
管理責任者業務上の責任者
技術担当者更新、設定、障害対応を行う人
外部公開状態一般公開、認証付き、VPN限定など
公開リンク有効なリンクの有無
接続先データベース、データウェアハウス
接続アカウント専用ID、権限、管理者
取扱情報個人情報、営業秘密、会計情報など
管理者アカウント氏名、所属、必要性
APIキー用途、所有者、権限
ログ保存場所、保存期間、確認者
バックアップ対象、保存先、復旧方法
更新方法自動、手動、委託先対応
緊急連絡先ベンダー、保守事業者、社内責任者

最初から全てを詳細に調査する必要はありません。

まずは、会社で使っているダッシュボードのURLを三つ挙げ、誰が管理し、どのデータベースへ接続し、外部からアクセスできるかを確認してください。

公開範囲を決める際の考え方

BIツールを全て社内ネットワークへ閉じることが、必ずしも正解ではありません。

顧客や取引先へ情報を提供するため、外部公開が必要な場合もあります。

重要なのは、利用目的に合わせて公開方法を選ぶことです。

一般公開する場合

公開しても問題のない集計情報だけに限定します。

個人名、顧客別売上、未発表の業績、内部の識別番号などが含まれていないか確認します。CSV等で元データを出力できないかも確認してください。

顧客別に表示する場合

URLだけで顧客を分けるのではなく、認証と権限管理を利用します。

一社の利用者が、URLの変更やフィルター操作によって別の顧客のデータを見られないことを確認します。

社員だけが利用する場合

SSO、MFA、VPN、接続元制限などを組み合わせます。

退職者や異動者のアカウント停止も、通常のアカウント管理手順に含めます。

管理画面

一般利用者の閲覧画面よりも強く制限します。

可能であれば、管理者だけが利用するネットワーク、端末、アカウントへ限定します。

15分でできる最初の確認

Metabaseを利用している会社は、まず次の五つを確認してください。

  1. 管理画面の「About Metabase」等でバージョンを確認する
  2. 会社外の回線から対象URLへアクセスできるか確認する
  3. 管理画面の「Public Sharing」で公開中の項目を確認する
  4. 管理者アカウントとAPIキーの一覧を確認する
  5. 接続先データベースのアカウントが読取り専用か確認する

自社だけで確認できない場合は、構築した開発会社や保守事業者へ、書面やメールで回答を求めます。

「対応済みです」という回答だけでなく、次の情報を確認してください。

  • 現在のバージョン
  • 更新した日時
  • 更新前のバージョン
  • 外部公開の有無
  • 公開リンクの確認結果
  • ログ調査の実施結果
  • 管理者アカウントの確認結果
  • APIキーの確認結果
  • 接続先認証情報の変更結果

経営者が確認したい五つの質問

経営者がSQLインジェクションの仕組みを詳しく理解する必要はありません。

まず、担当者へ次の五つを確認してください。

  1. 自社で利用しているBIツールとダッシュボードを全て把握しているか
  2. 社外からアクセスできる画面と公開リンクを一覧にできるか
  3. BIツールがどのデータベースへ、どの権限で接続しているか分かるか
  4. 管理者アカウント、APIキー、接続用IDの責任者が決まっているか
  5. 脆弱性が公表されたとき、誰が更新し、誰が侵害調査を行うか決まっているか

この五つに答えられなければ、会社の重要データへつながる入口が、管理されないまま公開されている可能性があります。

まとめ

2026年8月に公表されたMetabaseの脆弱性では、認証なしの攻撃によって、Metabaseの管理者権限を取得される可能性が示されました。

攻撃者が管理者権限を取得した場合、接続先データベースの認証情報を窃取し、その認証情報で閲覧できるデータを読み取り、外部へ出力する可能性があります。

また、公開共有されたダッシュボード等を経由する別の脆弱性も公表されています。

今回確認すべきなのは、Metabaseのバージョンだけではありません。

  • インターネットからアクセスできるか
  • 公開リンクが残っていないか
  • 管理者アカウントが多すぎないか
  • 不明なAPIキーがないか
  • 接続先データベースの権限が広すぎないか
  • 認証情報を変更したか
  • 不審なアクセスを調べられるログがあるか

これらを一つずつ確認する必要があります。

BIツールは、単にグラフを表示するための画面ではありません。

社内の売上、顧客、在庫、製造、会計などのデータへ接続するシステムです。

まずは、社内で使用しているダッシュボードを一つ開き、次の質問へ答えてください。

この画面は、会社の外から誰が閲覧でき、どのデータベースのどこまでアクセスできるのか。

回答できなければ、バージョン、公開範囲、接続権限の三点から確認を始めてください。

ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象に、外部公開システム、クラウドサービス、管理者アカウント、APIキー、データベース接続権限などの棚卸しを支援しています。

製品の導入を否定するのではなく、利用目的に必要な範囲へ公開と権限を絞り、問題発生時に説明できる状態を作ることが目的です。

投稿タグ
, , , , , , , , , , , ,