CVE-2026-51992

Dentro de ClickHouse, existe una funcionalidad que permite a un usuario con los permisos adecuados crear diccionarios para interactuar con diferentes bases de datos y ejecutar consultas específicas en ellas. Para PostgreSQL, las consultas SELECT se envuelven en una declaración COPY( {QUERY} ) TO STDOUT antes de ejecutarse en la base de datos. Al añadir un paréntesis a un diccionario creado, se puede escapar de la declaración COPY( {QUERY} ) TO STDOUT y ejecutar sentencias SQL arbitrarias, lo que a su vez puede llevar a ejecutar comandos arbitrarios en el servidor de base de datos.

Detalles

Los diccionarios de PosgreSQL se crean con la siguiente estructura:

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'
))

La documentación de los motores PostgreSQL utilizados en los diccionarios menciona lo siguiente:

Las consultas SELECT en el lado de PostgreSQL se ejecutan como COPY (SELECT ...) TO STDOUT dentro de una transacción PostgreSQL de solo lectura con commit después de cada consulta SELECT.

Dado que no hay validación adicional sobre las consultas definidas en el diccionario antes de ser enviadas a la instancia de Postgres, se puede salir de "COPY(...) TO STDOUT" comenzando la consulta con un ")", creando una transacción que no es de solo lectura. Como ejemplo, la siguiente consulta se puede utilizar en ClickHouse para crear un diccionario Postgres "maligno":

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())

Una vez creado el diccionario, se puede cargar dentro de ClickHouse haciendo referencia a él. ClickHouse devolverá un error, indicando que la función COPY que espera ClickHouse ha fallado. Sin embargo, el resto de la consulta se ejecutará igualmente en la base de datos PostgreSQL subyacente. Al abusar de la funcionalidad PROGRAM de PostgreSQL, se pueden ejecutar comandos arbitrarios.

Contexto

Aunque las pruebas originales se realizaron en la versión 25.8.10.7, cuando el informe se envió el 30 de enero de 2025, la última versión en ese momento era la 26.3.9.8 y la vulnerabilidad seguía presente. Tras la revisión, el problema se marcó como "no aplicable" el 10 de abril de 2026, con la siguiente declaración:

no - esto no se debe a razones de seguridad sino principalmente a eficiencia. Un usuario con credenciales de postgres + función de tabla remota ya puede hacer mucho o conectarse directamente a la base de datos postgresql y ejecutar estas consultas.

Por lo tanto, esto no es un riesgo; aquí el atacante requiere credenciales válidas para la base de datos postgresql y un usuario válido en ClickHouse + permiso para usar la función de tabla postgresql.

En cuanto a la protección de la base de datos Postgresql, los usuarios deberían usar permisos sensatos para cualquier credencial postgresql utilizada por el usuario de ClickHouse - esto significa permisos limitados, alcance restringido y no usar directamente las credenciales predeterminadas "postgres".

Por lo tanto, esto sigue siendo aplicable en las últimas versiones de ClickHouse en el momento de redactar este informe:

No parece probable que se publique un parche, lo que significa que todas las versiones actuales y posiblemente futuras de ClickHouse se verán afectadas.