データ分析ツール『Metabase』にサーバー乗っ取りの脆弱性 CVE-2026-59827、一般アカウントから社内サーバー制圧・最新版へ即更新を

会社のデータを集計してグラフや表にする人気ツール「Metabase（メタベース）」に、ログインできる一般社員のアカウントさえあれば、ツールが動いているサーバーを丸ごと乗っ取られる深刻な欠陥が見つかりました。識別番号はCVE-2026-59827で、危険度は10点満点中9.9という最上位クラスです。開発元のセキュリティ勧告が2026年6月30日に公開され、7月上旬に共通脆弱性番号として登録されました。

同じタイミングで、管理者アカウントを持つ人が悪用できるもう1件の乗っ取りの穴（CVE-2026-59826／危険度9.1）も公表されています。どちらもMetabaseが標準で抱える「H2」という簡易データベースの扱いが原因で、設定を変えていない初期状態のMetabaseほど危ないという共通点があります。幸い両方とも修正版はすでに出ており、更新すれば防げます。Metabaseを社内で動かしている場合は、後回しにせず最新版へ上げてください。

そもそもMetabaseとは何か

Metabaseは、社内にたまっている売上や会員などのデータをつないで、プログラミングなしでグラフや一覧表を作れる「BIツール」と呼ばれるサービスです。BIはビジネス・インテリジェンスの略で、要はデータを見やすく可視化して経営や現場の判断に使う道具のことです。2015年に登場したオープンソースソフトで、世界で約5万社が利用しているとされ、「5分で入れられて、社員全員が使える」手軽さから、エンジニアのいるスタートアップから大企業の一部門まで幅広く導入されています。

ここで大事なのは、Metabaseは社内の本番データベースに直接つないで動くという点です。売上管理システム、顧客管理システム、在庫データなど、会社の中核データにアクセスできる「窓口」として設置されます。つまりMetabaseのサーバーそのものを乗っ取られると、攻撃者はそこにつながったすべてのデータベースの接続情報（ユーザー名やパスワード）にまで手が届くことになります。ただの分析ツールに見えて、実は会社のデータの中心に置かれた鍵束のような存在なのです。

似た性質を持つ、社内向けの業務ツールを作る基盤では過去にも乗っ取りの脆弱性が相次いでいます。たとえばローコード開発基盤Appsmithの通信の出入り口を乗っ取られる脆弱性もその一つで、社内の便利ツールが逆に会社全体のデータへの入口になってしまう構図は共通しています。

何が危険なのか、どれくらいの規模なのか

今回の2件は、いずれも「サーバー上で攻撃者が自由にプログラムを実行できてしまう」タイプの欠陥です。専門用語では遠隔からのコード実行（RCE）と呼ばれ、脆弱性の中でも最も重い部類に入ります。サーバー上で好きな命令を動かせるということは、保存されているデータを盗む・書き換える・消す、他のシステムへの踏み台にする、といった行為が理屈のうえでは何でもできる状態を意味します。

危険度が特に高いのは9.9のCVE-2026-59827のほうです。悪用に必要なのは管理者権限ではなく、SQLという問い合わせ言語を実行できる一般利用者のアカウントだけ。しかもMetabaseは初期状態で「H2」という練習用の簡易データベースを標準搭載しており、この標準構成のままだと大半のMetabaseが影響を受けると説明されています。分析担当者に配った普通のアカウントが、そのままサーバー乗っ取りの入口になり得るということです。

もう1件のCVE-2026-59826（9.1）は、悪用に管理者権限が必要な分だけ条件は厳しくなります。ただ、管理者アカウントが乗っ取られた場合や、内部の関係者が悪意を持った場合には、同じくサーバー上で任意のプログラムを実行される恐れがあります。両方をあわせると、「一般アカウントからでも、管理者アカウントからでも、経路は違えど最終的にサーバーを制圧できる」という、守る側にとって厄介な状況になっています。

誰がこの穴を狙い、何が起きるのか

この脆弱性で真っ先に狙われるのは、Metabaseを社内のデータ基盤として運用している企業や組織です。狙う側として想定されるのは、企業の内部データを盗んで身代金を要求するランサムウェア集団や、盗んだ顧客情報を売りさばく攻撃グループです。Metabaseは会社のデータが集まる交差点にあるため、一度制圧できれば効率よく大量の機密情報に手が届く、彼らにとって旨みの大きい標的だからです。

攻撃の流れはこうです。攻撃者はまず、何らかの方法でMetabaseにログインできる一般アカウントを一つ手に入れ、そこから細工した問い合わせを送り込んでサーバー上でプログラムを実行させます。フィッシングで盗んだ社員の認証情報や、退職者の消し忘れアカウント、あるいは外部に公開されてしまっているMetabaseの弱いパスワードなどが入口になり得ます。9.9の欠陥では管理者である必要すらなく、閲覧・分析用の権限だけで足ります。

その結果、企業が失うものは分析ツール一つにとどまりません。Metabaseがつないでいた本番データベースの接続情報が抜かれれば、顧客情報や売上といった会社の中核データそのものが芋づる式に流出する恐れがあります。運用する情報システム部門にとっては、被害範囲がMetabase単体では終わらないのが最大の怖さです。社内の業務基盤が攻撃者の入口に変わる事故は、開発・運用ツールの欠陥を突かれる事例として繰り返し起きており、今回はその舞台が全社的なデータ分析基盤だったという構図です。

技術的に見ると何が起きているのか

2件はどちらも、Metabaseが同梱している「H2」という軽量データベースの扱いに根がありますが、突く場所は異なります。それぞれ別の識別番号が割り当てられています。

CVE-2026-59827：問い合わせ結果に紛れ込んだ「仕込み」を鵜呑みにする

Metabaseでは、利用者がSQLというデータベース向けの問い合わせ言語を直接書いて実行できます。H2データベースに対してこの生のSQLを実行すると、返ってくる結果の中に「OTHER（その他）」という種類の列が混ざることがあります。問題は、Metabaseがこの列の中身を検証せずにそのままJavaのプログラム部品として復元（デシリアライズ）してしまう点にありました。デシリアライズとは、保存や通信のために文字列化されたデータを、元のプログラム上の部品に戻す処理のことです。

攻撃者はこの仕組みを逆手に取り、復元されると悪意ある命令が動き出すように細工した部品を、問い合わせ結果に忍ばせます。Metabaseがそれを疑わずに組み立て直した瞬間、サーバー上で攻撃者の命令が実行されてしまう、という流れです。米国立標準技術研究所（NIST）はこれを「信頼できないデータのデシリアライズ」（CWE-502）として分類しています。前述のとおり、初期状態のH2サンプルデータベースがそのまま経路になるため、標準構成のMetabaseの多くが該当します。危険度9.9という数字は、この「特別な権限がいらないのにサーバーを奪える」点を反映したものです。

CVE-2026-59826：危険な接続設定のチェックをすり抜ける

2件目は、Metabaseに新しいデータベースをつなぐ「接続登録」の画面が舞台です。H2データベースは接続設定の文字列の中に、初期化時に自動でSQLを実行させる指定などを書き込めます。この指定を悪用すればサーバー側で任意のプログラムを走らせられるため、本来Metabaseは危険な接続設定をはじく検査を行うべきでした。ところがその検査を一部の経路ですり抜けられる不備があり、管理者が細工したH2接続を登録すると、サーバー上で任意のJavaコードが実行されてしまいます。

NISTはこれを「コード生成の不適切な制御」（CWE-94）として整理しています。悪用には管理者権限が必要なため危険度は9.1と59827より一段低いものの、Metabaseの管理者アカウントは分析基盤全体を握る強力な立場です。そのアカウントが乗っ取られれば、この穴を通じてサーバー制圧まで一直線でつながります。開発元の勧告でも、両方をまとめて塞ぐことが推奨されています。

H2はMetabaseの弱点を繰り返してきた

今回に限らず、Metabaseにとって同梱の「H2」データベースは何度も火種になってきました。2023年にはログインする前でも悪用できる致命的な乗っ取りの穴（CVE-2023-38646／危険度9.8）が見つかり、米政府機関CISAが「実際に攻撃に使われている脆弱性」として警告する事態になりました。この一件をきっかけに、Metabaseは新規のインストールでH2を正式な接続先としてサポートしない方針へと舵を切っています。

それでも2026年3月には、企業向け版でH2の接続文字列を悪用する別のコード実行の脆弱性（CVE-2026-33725）が公表されるなど、H2まわりの問題は完全には収まっていません。今回の2件も同じ流れの上にあります。H2は手軽に使える反面、設計上サーバー側で強力な操作を許してしまう性質があり、そこがMetabaseの繰り返す弱点になっている、というのが専門家の見方です。

これまでの経緯

← スワイプで移動

今回の2件は、開発元自身がGitHubのセキュリティ勧告として詳細を公開し、あわせて修正版もリリースしています。前史の2件と並べると、H2まわりの問題が数年おきに繰り返されている流れがよく見えます。

影響を受けるバージョンと安全な修正版

2件は影響する範囲が少しずつ異なります。9.9のCVE-2026-59827は1.58系以降、9.1のCVE-2026-59826は1.55系以降が対象です。両方をまとめて塞げる版を系統ごとに整理したのが次の表です。なお、無料のオープンソース版はバージョンの先頭が「0」、企業向け版は「1」で始まりますが、続く番号は共通です（例：企業向け1.58.15はオープンソース版0.58.15にあたります）。

クラウド版（Metabase Cloud）を使っている場合は、更新は運営側で適用されるため利用者の作業は基本的に不要です。一方、自社サーバーやDockerで動かしている「セルフホスト」の場合は、自分たちで最新版へ上げる必要があります。今回のように更新が唯一の根本対策となるケースでは、放置した分だけ危険にさらされる時間が延びます。

確認できていること、まだ分からないこと

今すぐできる対策

今回は修正版が出ているため、対策の軸ははっきりしています。使っている系統に応じて、上の表の「上げるべき版」以降へ更新するのが最優先です。セルフホストで動かしている場合は、DockerイメージやJARファイルを差し替えて再起動する形になります。更新の前後でダッシュボードや接続設定が壊れていないかを確認しておくと安心です。

すぐに更新できない事情がある場合の緩和策として、Metabaseをインターネットに直接公開しない（社内ネットワークやVPNの内側に置く）、不要になったアカウントや退職者アカウントを整理する、一般利用者に生のSQL実行を許可する範囲を見直す、といった手当てが被害の入口を狭めます。ただしこれらはあくまで時間稼ぎであり、根本的にはバージョンアップが必要です。

自社で使っている業務ツールや開発基盤に、外部に公開された管理画面や弱い認証が残っていないかを棚卸ししておくことは、今回のMetabaseに限らず有効です。同種の注意は、開発支援ツールの乗っ取り脆弱性のような別のケースでも役立ちます。

よくある質問

まとめ

今回の件は、社内のデータを見やすくするための便利なツールが、設定を変えていない初期状態ほどサーバー乗っ取りの入口になり得るという話です。9.9のCVE-2026-59827は一般アカウントから、9.1のCVE-2026-59826は管理者アカウントから悪用され、いずれも最終的にはMetabaseのサーバー制圧につながります。Metabaseは会社の中核データにつながる位置にあるため、被害はツール単体では終わりません。

救いは、両方とも修正版がすでに出ていることです。自社の系統に合わせて最新版へ上げれば防げます。過去にもH2まわりで繰り返し問題が起きてきた経緯を踏まえると、更新の先送りは避けたいところです。新たな悪用の動きや続報があれば、あらためてお伝えします。

参照元

• ▸ Metabase Security Advisory - Unsafe Deserialization of H2 Query Results（GHSA-w95f-x9v9-wv36 / CVE-2026-59827）
• ▸ Metabase Security Advisory - Arbitrary Code Execution via Database Connection Detail Bypass（GHSA-8wx2-rxp2-4x35 / CVE-2026-59826）
• ▸ NVD - CVE-2026-59827
• ▸ NVD - CVE-2026-59826
• ▸ NVD - CVE-2023-38646（2023年のH2関連RCE）
• ▸ Metabase セキュリティ勧告一覧（GitHub）
• ▸ Metabase 公式サイト