データ分析ツール『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を社内で動かしている場合は、後回しにせず最新版へ上げてください。

さらに2026年7月には、これらとは経路の異なるサーバー乗っ取りの欠陥（CVE-2026-50148／危険度は最大値の10.0）も公表されました。こちらはH2ではなく、クラウド型のデータ保管サービス「Snowflake」との接続を悪用して、Metabaseが使うプログラム部品（データベース接続用のドライバ）を丸ごと差し替える手口です。悪用にはデータベース接続を追加・変更できる権限（通常は管理者）が必要という違いがありますが、成立すれば同じくサーバー上で任意のプログラムを実行されます。前の2件とあわせ、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）は、悪用に管理者権限が必要な分だけ条件は厳しくなります。ただ、管理者アカウントが乗っ取られた場合や、内部の関係者が悪意を持った場合には、同じくサーバー上で任意のプログラムを実行される恐れがあります。両方をあわせると、「一般アカウントからでも、管理者アカウントからでも、経路は違えど最終的にサーバーを制圧できる」という、守る側にとって厄介な状況になっています。7月に加わった10.0のCVE-2026-50148は、H2ではなくSnowflakeとの接続を悪用する第3の経路で、これも管理者相当の権限が前提ながら、最終的なゴールはやはりサーバー上でのプログラム実行です。攻撃の入口は違っても行き着く先が同じ、という穴が短期間に重なった点が、今回のMetabaseをめぐるRCE（遠隔からのコード実行）の特徴です。

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

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

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

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

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

今回取り上げる3件は、根っこが2種類に分かれます。うち2件（59827・59826）はMetabaseが同梱する「H2」という軽量データベースの扱いに、残る1件（50148）は「Snowflake」との接続を通じて読み込むドライバの扱いに根があります。それぞれ突く場所が異なり、別々の識別番号が割り当てられています。

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

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

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

CVE-2026-50148：Snowflake接続を悪用してドライバを差し替える

3件目は、これまでの2件とはまったく別の経路をたどります。舞台になるのは、Metabaseが外部のデータ保管サービス「Snowflake」（クラウド上に大量のデータをためて分析する、いわゆるデータ倉庫）へ接続する仕組みです。Metabaseは各種データベースにつなぐために「ドライバ」と呼ばれる接続用の部品を読み込んで使いますが、Snowflake用ドライバに、接続先のサーバーからMetabaseの動くマシンへ任意のファイルを書き込めてしまう欠陥がありました。

これを悪用すると、攻撃者はまず自分が用意した偽のSnowflakeサーバーを指す接続をMetabaseに設定します。Metabaseがそこへ接続した際、偽サーバーはMetabase自身のドライバ部品を、悪意あるものにこっそり上書きします。次にMetabaseがそのドライバを読み込んだ瞬間、差し替えられた中身がMetabaseのプログラムとして動き出し、サーバー上で攻撃者の命令が実行されます。もとをたどれば、Metabaseに同梱されているSnowflakeのJDBCドライバ（Javaからデータベースにつなぐための標準部品）が抱えていた欠陥で、外部の部品に依存することのリスクが表面化した「サプライチェーン型」の側面を持ちます。同種の構図は、Snowflakeのコマンドツールで不正なプロジェクトのビルド時に乗っ取られる脆弱性でも指摘されており、あわせて点検したい場合はオープンソース部品の安全性を確認する方法も参考になります。

危険度は最大値の10.0が付いていますが、悪用にはデータベース接続を追加・変更できる権限（通常は管理者）が必要という緩和要因があります。開発元も勧告の中で、この権限が前提になる点を明記しています。つまり、誰でも外から突けるわけではなく、H2のCVE-2026-59827（一般アカウントで悪用可）とは危険の質が異なります。とはいえ管理者アカウントが乗っ取られた場合や、内部に悪意ある関係者がいた場合には、決済や顧客データにつながるMetabaseサーバーが乗っ取られるため、軽視はできません。開発元は修正版で、第一者提供のドライバをアプリ本体に組み込み、ディスク上で差し替えられないようにする対処を取っています。

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の繰り返す弱点になっている、というのが専門家の見方です。さらに2026年7月のCVE-2026-50148は、火種がH2だけではないことも示しました。Metabaseは多くの種類のデータベースにつなぐため多数のドライバを同梱しており、その一つ（Snowflake用）の欠陥が乗っ取りの経路になりました。外部から取り込む部品が増えるほど、そのどれかに穴があれば入口になり得る——H2に限らない構造的な課題が背景にあります。

これまでの経緯

← スワイプで移動

今回の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で動かしている「セルフホスト」の場合は、自分たちで最新版へ上げる必要があります。今回のように更新が唯一の根本対策となるケースでは、放置した分だけ危険にさらされる時間が延びます。

Snowflake接続を悪用するCVE-2026-50148（10.0）は、単体では0.54.24／0.55.24／0.56.25／0.57.19／0.58.14／0.59.10／0.60.4以降で修正されています（企業向け版はそれぞれ先頭が1の同番号）。上の表の「上げるべき版」はこれらより新しいため、表に従って最新版へ上げれば、H2起因の2件とあわせて3件すべてをまとめて塞げます。1.54系より前の古い系統を使っている場合は、少なくとも0.54.24／1.54.24以降へ上げてください。

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

今すぐできる対策

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

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

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

よくある質問

まとめ

今回の件は、社内のデータを見やすくするための便利なツールが、設定を変えていない初期状態ほどサーバー乗っ取りの入口になり得るという話です。9.9のCVE-2026-59827は一般アカウントから、9.1のCVE-2026-59826は管理者アカウントから、そして7月に加わった10.0のCVE-2026-50148はSnowflake接続を悪用する管理者相当の経路から悪用され、いずれも最終的には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）
• ▸ Metabase Security Advisory - Arbitrary File Write via Malicious Snowflake Connection（GHSA-r6x2-rchx-q9g9 / CVE-2026-50148）
• ▸ NVD - CVE-2026-50148
• ▸ NVD - CVE-2026-59827
• ▸ NVD - CVE-2026-59826
• ▸ NVD - CVE-2023-38646（2023年のH2関連RCE）
• ▸ Metabase セキュリティ勧告一覧（GitHub）
• ▸ Metabase 公式サイト