theliimbo/cve-2026-51992Proof-of-Concept und ausführlicher Bericht zu CVE-2026-51992, einer SQL-Injection-Schwachstelle in den PostgreSQL-Dictionaries von ClickHouse, die die Ausführung beliebiger Befehle ermöglicht.
In ClickHouse gibt es eine Funktion, die es einem Benutzer mit den entsprechenden Berechtigungen ermöglicht, Wörterbücher zu erstellen, um mit verschiedenen Datenbanken zu interagieren und spezifische Abfragen auf ihnen auszuführen. Bei PostgreSQL werden SELECT-Abfragen in eine COPY( {QUERY} ) TO STDOUT-Anweisung verpackt, bevor sie in der Datenbank ausgeführt werden. Durch Hinzufügen einer Klammer zu einem erstellten Wörterbuch kann die COPY( {QUERY} ) TO STDOUT-Anweisung umgangen werden, und es können beliebige SQL-Anweisungen ausgeführt werden, was wiederum zur Ausführung beliebiger Befehle auf dem Datenbankserver führen kann.
PostgreSQL-Wörterbücher werden mit der folgenden Struktur erstellt:
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'
))
Die Dokumentation für die in den Wörterbüchern verwendeten PostgreSQL-Engines erwähnt Folgendes:
SELECT-Abfragen auf der PostgreSQL-Seite werden als COPY (SELECT ...) TO STDOUT innerhalb einer schreibgeschützten PostgreSQL-Transaktion mit Commit nach jeder SELECT-Abfrage ausgeführt.
Da die im Wörterbuch definierten Abfragen vor dem Senden an die Postgres-Instanz keiner zusätzlichen Validierung unterzogen werden, kann die „COPY(...) TO STDOUT“-Anweisung umgangen werden, indem die Abfrage mit einer „)“ beginnt, wodurch eine Transaktion entsteht, die nicht schreibgeschützt ist. Als Beispiel kann die folgende Abfrage in ClickHouse verwendet werden, um ein „schlechtes“ Postgres-Wörterbuch zu erstellen:
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())
Sobald das Wörterbuch erstellt ist, kann es in ClickHouse geladen werden, indem man auf das Wörterbuch verweist. ClickHouse gibt einen Fehler zurück, der anzeigt, dass die von ClickHouse erwartete COPY-Funktion fehlgeschlagen ist. Der Rest der Abfrage wird jedoch weiterhin in der Backend-PostgreSQL-Datenbank ausgeführt. Durch Missbrauch der PostgreSQL-PROGRAM-Funktion können beliebige Befehle ausgeführt werden.
Während die ursprünglichen Tests auf Version 25.8.10.7 durchgeführt wurden, war zum Zeitpunkt der Einreichung des Berichts am 30. Januar 2025 die neueste Version 26.3.9.8 und die Schwachstelle weiterhin vorhanden. Nach der Überprüfung wurde das Problem am 10. April 2026 mit der folgenden Aussage als „nicht zutreffend“ markiert:
nein – dies ist nicht aus Sicherheitsgründen der Fall, sondern hauptsächlich aus Gründen der Effizienz. Ein Benutzer mit Postgres-Zugangsdaten + Remote-Tabellenfunktion kann bereits viel tun oder sich direkt mit der PostgreSQL-Datenbank verbinden und diese Abfragen ausführen.
Daher stellt dies kein Risiko dar: Der Angreifer benötigt hier gültige Zugangsdaten für die PostgreSQL-Datenbank und einen gültigen Benutzer auf ClickHouse + die Berechtigung zur Nutzung der PostgreSQL-Tabellenfunktion.
Was den Schutz der PostgreSQL-Datenbank betrifft, sollten Benutzer für alle PostgreSQL-Zugangsdaten, die vom ClickHouse-Benutzer verwendet werden, angemessene Berechtigungen verwenden – das bedeutet eingeschränkte Berechtigungen, einen begrenzten Umfang und nicht direkt Standard-„postgres“-Zugangsdaten.
Daher ist dies zum Zeitpunkt dieses Berichts weiterhin auf den neuesten Versionen von ClickHouse anwendbar:
Es scheint unwahrscheinlich, dass ein Fix veröffentlicht wird, was bedeutet, dass alle aktuellen und möglicherweise zukünftigen Versionen von ClickHouse betroffen sein werden.