CVE-2026-17351

Zusammenfassung

Die Behebung für CVE-2026-12045 in pgAdmin 4 9.16 erforderte, dass die vom LLM gelieferte Abfrage, die an das execute_sql_query-Tool des KI-Assistenten übergeben wird, über sqlparse als genau eine Nicht-Transaktionskontroll-Anweisung geparst wird, bevor sie innerhalb eines BEGIN TRANSACTION READ ONLY-Wrappers ausgeführt wird. Die String-Literal-Lexik von sqlparse kann mit dem eigenen Parser von PostgreSQL kollidieren: bei standard_conforming_strings = on (PostgreSQL-Standard seit 9.1) ist ein Backslash unmittelbar vor einem Anführungszeichen für PostgreSQL ein gewöhnliches Zeichen, aber sqlparse behandelt ihn als Escape des Anführungszeichens. Ein Payload wie SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' wird daher vom sqlparse-Validator als einzelnes SELECT geparst, während PostgreSQL ihn als vier Anweisungen ausführt: das eingeschmuggelte COMMIT beendet die umschließende Read-Only-Transaktion, und das nachfolgende ROLLBACK wird zu einem No-op. Dies führt denselben Write/RCE-Bypass wieder ein, den CVE-2026-12045 schließen sollte, erreichbar über dieselbe indirekte Prompt-Injection-Zustellung (ein Angreifer platziert den Payload in einem beliebigen Objekt, das der KI-Assistent lesen kann; das LLM gibt ihn als Tool-Aufruf aus). Ein erster Kandidat für die Behebung führte die Abfrage mit psycopgs execute(..., prepare=True) aus, in der Absicht, PostgresQLs eigenen Parse-Schritt (erweitertes Abfrageprotokoll) zu erzwingen, um Mehrfachanweisungstext unabhängig von der sqlparse-Klassifizierung abzulehnen. Dieser Kandidat für die Behebung funktioniert wie eingereicht nicht: psycopg3s PrepareManager ignoriert das prepare-Argument stillschweigend, wenn das prepare_threshold der Verbindung None ist, was pgAdmins Standard für jede Serververbindung ist (das serverseitige Feld „Prepare threshold" ist leer, sofern ein Administrator es nicht explizit setzt) – psycopg3 fällt auf das einfache Abfrageprotokoll zurück, denselben Mehrfachanweisungs-fähigen Pfad, den der Bypass ausnutzt, sodass der Kandidat für die Behebung bei keiner realen Standardkonfiguration etwas schließt. Die korrigierte Behebung setzt conn.prepare_threshold = 0 direkt auf der dedizierten, einmalig verwendeten Read-Only-Verbindung, die das KI-Assistenten-Tool öffnet, und erzwingt strukturell das erweiterte Abfrageprotokoll unabhängig von jeder Serverkonfiguration. Verifiziert gegen eine Live-PostgreSQL-18-Instanz: der Payload wird unter dem prepare_threshold=None-Verhalten (Standard) erfolgreich ausgeführt und wird mit „cannot insert multiple commands into a prepared statement" abgelehnt, sobald prepare_threshold=0 auf dieser Verbindung gesetzt ist. Dieses Problem betrifft pgAdmin 4: von 9.13 vor 9.17.