Metabaseの脆弱性と、BIツールからの情報漏えいを防ぐために見直すこと

2026年9月前後から、国内の組織で、不正アクセスによる個人情報などの漏えいが相次いでいます。JPCERT/CCは10月8日に注意喚起を出し、一般の利用者向けのアプリだけでなく、BIツールや従業員向けの管理システムでも情報が漏えいしていると伝えました（JPCERT/CC（別タブで開く））。

注意喚起が示した4つの手口のうち、製品名が挙がったのは、BIツールのMetabaseだけです。

BIツールは、社内でデータを見るための道具です。一方で、多くのデータベースにつながり、顧客の情報を横断して読めるため、入られたときの被害が大きくなります。

本記事では、Metabaseの脆弱性の内容と、BIツールやデータ基盤で見直す点を整理します。記載の内容は、2026年10月時点の公式情報に基づきます。

相次ぐ不正アクセスの手口

JPCERT/CCは、報告された手口を4つに分けています。手口は事案によって異なります。

	手口
ケースA	さまざまなソフトウェアの既知の脆弱性を探し、攻撃を試みる。設定ファイルやバックアップのファイルを盗む試みもある
ケースB	スマートフォンのアプリを解析してAPIを特定し、画面からは使えない内部のAPIで権限の変更やアカウントの作成をする。別のシステムから盗んだAPIのキーを使うこともある
ケースC	MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）を悪用する
ケースD	公開しているWebサーバーから届くアプリケーションのサーバーに、Webシェルを置く

政府も対応を進めています。個人情報保護委員会（10月7日）、国家サイバー統括室、IPA、経済産業省など（10月9日）が、注意喚起を出しました（個人情報保護委員会（別タブで開く）、IPA（別タブで開く））。

Metabaseの脆弱性（CVE-2026-72898）

何が起きるか

CVE-2026-72898は、MetabaseのSQLインジェクションの脆弱性です。ログインしていない攻撃者が、細工したリクエストを送ることで、Metabaseのアプリケーションのデータベースに任意のSQLを実行できます（JPCERT/CC（別タブで開く））。

Metabaseの発表によると、攻撃者は管理者の権限を得るおそれがあります。管理者になると、設定の変更、接続先のデータベースの認証情報の窃取、データの読み取りや書き出しができてしまいます（Metabase（別タブで開く））。

Metabaseは2026年8月6日に修正版を公開しました。公開の時点で、すでにこの脆弱性を使った攻撃（ゼロデイ攻撃）が確認されていました。

国内で公表された事例

国内でも、データの集計や分析に使っていたMetabaseから、顧客の情報を取得された、または見られる状態だったと公表した企業があります。各社の発表には、CVEの番号は書かれていません。

企業	公表日	発表の内容
LEAN BODY	2026年9月15日	分析ツール（Metabase）の脆弱性を悪用され、退会者を含む約44万アカウントの情報を取得された。最初の不正アクセスは8月11日。原因は、脆弱性の情報の確認と更新ができていなかった可能性が高いとしている（LEAN BODY（別タブで開く））
JGC Digital	2026年9月18日	BIツール「Metabase」の脆弱性を悪用され、「アザス」「するーぷ」の利用者の情報、合計約6万件を取得された。Metabaseの利用をやめるとしている（JGC Digital（別タブで開く）。10月11日時点の保存）
NEXT STAGE	2026年10月13日	社内で使うMetabaseのBIツールで、第三者がアカウントを不正に使い、サービスのデータベースを検索できる状態だった。期間は9月22日〜10月9日で、漏えいの可能性は最大約4万件（適時開示（別タブで開く））

LEAN BODYは、その後Metabaseの利用をやめ、外部から接続できない環境に移したとしています。

影響するバージョンと修正版

自社のサーバーで動かしている（セルフホストの）Metabaseが対象です。各系列で、次の版より前のものが影響を受けます。

系列	修正版
63	0.63.5
62	0.62.9
61	0.61.11
60	0.60.17
59	0.59.21
58	0.58.24

58より前の系列は影響を受けません。Metabase Cloudは、Metabaseがすでに更新しています。

Metabaseの番号は、オープンソース版が「0.」、有料版が「1.」で始まります（例：1.63.5）。同じ系列でも、修正版より前の番号なら影響を受けます。たとえば、0.58.6を使っている場合は、0.58.24以降に上げます。

すぐに更新できない場合は、/api/session/reset_password へのアクセスをネットワーク機器などで止めます。

侵害を確かめる

/api/session/reset_password にインターネットから届く状態だった場合は、更新するだけでなく、入られていないかを確かめます。Metabaseは、ログに次の2つが続けて出ていれば、侵害の可能性が高いとしています。

POST /api/session/reset_password が400を返している
続けて GET /api/user/current が200を返している

当てはまる場合や、公開していた期間が長い場合は、Metabaseが勧める次の対応をします。

アプリケーションのデータベースにあるセッションの表（core_session）の行をすべて消し、すべてのログインを切る
覚えのないAPIのキーを消す
管理者のアカウントに、覚えのない変更がないかを見る
接続先のデータベースの認証情報を変える
データウェアハウスのログと、Metabaseの操作やクエリの履歴に、不審な操作がないかを見る

BIツールとデータ基盤で見直すこと

Metabaseに限らず、BIツールやデータ基盤には、次の点を見直します。JPCERT/CCも、BIツールや従業員向けのシステムに、利用者向けのシステムと同じ点検をするよう勧めています。

BIツールとデータ基盤で見直す5つの点。インターネットへの公開、更新、接続の権限、保存するデータ、ログ。それぞれに確かめることを添えている

1. インターネットに公開しない

社内の人しか使わないBIツールが、インターネットから届く状態になっていないかを確かめます。JPCERT/CCは、業務に必要のない機能を公開している場合は、公開をやめるよう勧めています。

VPNや、許可したIPアドレスからだけ使えるようにする
クラウドのサービスなら、Googleアカウントなどで認証したうえで通す仕組みを前に置く
社外に共有したいダッシュボードは、公開の範囲を絞る

2. 更新を誰がするかを決める

セルフホストのBIツールは、自分で更新しないと古いままです。分析の担当者が立ち上げたまま、更新の担当が決まっていないと、修正版が出ても当てられません。

更新の担当者と、脆弱性の情報を見る場所（公式のブログ、GitHubの告知など）を決める
自分で運用しきれない場合は、事業者が更新するクラウド版を検討する

3. 接続のユーザーの権限を絞る

BIツールから接続するデータベースのユーザーは、読み取りだけにし、必要な表だけを見られるようにします。BIツールが乗っ取られたときに、持ち出される範囲を小さくするためです。

書き込みの権限を持たせない
氏名、メールアドレス、電話番号などの列は、分析に必要なければ渡さない。集計した表や、個人を特定できない形にした表をつなぐ
BIツールの中でも、個人情報を含むダッシュボードを見られる人を絞る

データ基盤で、権限と個人情報の扱いを設計の段階で決めておく方法は、「データ基盤の構築の進め方（別タブで開く）」で解説しています。

4. いらないデータを残さない

JPCERT/CCは、保存の期間を過ぎたデータや、使い終えたデータを残さないよう勧めています。分析のために個人情報を丸ごと複製した表は、使い終えたら消します。

5. ログを残し、見られるようにする

入られたかどうかは、ログがないと分かりません。BIツールの操作の記録と、データベース側のクエリの記録を残しておきます。

BigQueryを使っている場合は、INFORMATION_SCHEMA.JOBSで、直近180日のクエリの履歴を見られます。たとえば、BIツールが使うサービスアカウントの、日ごとのクエリの数と読んだデータの量は、次のように出せます。

SELECT
  DATE(creation_time, 'Asia/Tokyo') AS day,
  COUNT(*) AS jobs,
  ROUND(SUM(total_bytes_processed) / POW(1024, 3), 1) AS gb_processed
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
  AND user_email = 'bi-tool@your-project.iam.gserviceaccount.com'
GROUP BY day
ORDER BY day

region-asia-northeast1 の部分は、データを置いている地域（例：region-us）に合わせて書き換えます。

普段と比べて、急にクエリの数や読んだ量が増えた日があれば、その日のクエリ（query列）と、読んだ表（referenced_tables列）を確かめます。このビューを見るには、プロジェクトでBigQueryユーザー（roles/bigquery.user）とBigQueryリソース閲覧者（roles/bigquery.resourceViewer）のロールが要ります（INFORMATION_SCHEMA.JOBS（別タブで開く））。

漏えいが疑われる場合

個人情報が漏れた、または漏れたおそれがある場合は、個人情報保護委員会への報告が必要になることがあります。不正アクセスのように不正の目的によるおそれがある個人データの漏えいは、人数にかかわらず報告の対象になりえます。速報は速やかに（目安はおおむね3〜5日以内）、確報は60日以内に出します（個人情報保護委員会（別タブで開く）、漏えい等報告の義務化について（別タブで開く））。

JPCERT/CCは、不審なアクセスや侵害の手口などの情報の提供を求めています。

自社ではなく、使っているSaaSで漏えいした場合の対応は、「使っているSaaSから個人情報が漏えいしたら（別タブで開く）」で解説しています。

2026年10月には、PHPの本体にも重大な脆弱性（PHP2Shell）が見つかりました。PHPで動くサイトを運営している場合は、「PHPの脆弱性「PHP2Shell」とは（別タブで開く）」もあわせてご覧ください。

まとめ

相次ぐ不正アクセス：2026年9月前後から国内で相次ぎ、BIツールや従業員向けのシステムからも情報が漏えいした。JPCERT/CCが手口として製品名を挙げたのはMetabaseだけ
Metabaseの脆弱性：CVE-2026-72898。ログインなしで管理者の権限を取られ、接続先のデータベースの認証情報やデータを持ち出されるおそれがある。セルフホストの58〜63系が対象で、2026年8月6日に修正版が出ている
侵害の確かめ方：reset_passwordへの400のあとに、user/currentへの200が続くログを探す。当てはまれば、セッション・APIキー・接続の認証情報を変える
見直すこと：公開しない、更新の担当を決める、接続の権限を絞る、いらないデータを残さない、ログを残す

BIツールやデータ基盤は、社内の便利な道具として、立ち上げたあとの管理が後回しになりがちです。データを使える人を増やすほど、誰が何を見られるかの設計が大切になります。

株式会社INVOXは、データ基盤の構築、データ分析の支援、AIエージェントの開発を行っています。広告やGA4、CRMのデータをBigQueryに統合する際に、権限や個人情報の扱いの設計から支援しています。

「BIツールの公開範囲や権限を見直したい」「データ基盤の権限の設計を相談したい」といった課題をお持ちでしたら、お問い合わせください。