CVE-2026-17566

Zusammenfassung

pgAdmin 4's Import/Export Data tool baut eine psql \copy (...) -Kommandozeile auf, indem es eine vom Benutzer bereitgestellte SQL-Abfrage in eine Jinja-Vorlage interpoliert und die gerenderte Zeile über --command an psql übergibt. Um zu verhindern, dass ein Angreifer aus dem (...) -Wrapper ausbricht, validierte create_import_export_job() (Route POST /import_export/job/<sid>, nur durch die gewöhnliche, häufig erteilte Berechtigung tools_import_export_data geschützt) die Abfrage mit einem handgeschriebenen Klammergleichgewichts-Prüfer, _is_query_parens_balanced(). Dieser Prüfer behandelte stets einen Backslash vor einem einfachen Anführungszeichen (\') als Escape des Anführungszeichens, d. h. als ob standard_conforming_strings deaktiviert wäre. PostgreSQL hat standard_conforming_strings seit 9.1 (2010) standardmäßig aktiviert, dem Standard auf jeder PostgreSQL-Version, die pgAdmin 4 derzeit unterstützt (13-18); unter diesem Standard behandelt psqls eigener \copy-Tokenizer \ als gewöhnliches Zeichen, sodass ein direkt darauf folgendes einfaches Anführungszeichen das String-Literal schließt. Eine Abfrage wie SELECT 'a\') TO PROGRAM 'echo pwned' x' wurde daher von pgAdmins Prüfer als „ausgeglichen" akzeptiert (der glaubte, die ) befände sich noch innerhalb des Strings), während psql, ausgeführt über die tatsächlich gerenderte Kommandozeile, den String an dieser Stelle schließt und die folgende ) als Ende der umschließenden \copy (...)-Unterabfrage behandelt, wodurch eine vom Angreifer gewählte TO PROGRAM '<command>'-Klausel offengelegt wird, die psql über popen() ausführt – unabhängig von einem späteren Syntaxfehler in derselben Zeile. Dies ist dieselbe Fehlerklasse wie CVE-2025-12762/CVE-2025-13780 (RCE über psql-Metabefehl/COPY-Injection während der Wiederherstellung im PLAIN-Format), erreicht über eine unabhängig geschriebene Verteidigung in einem anderen Modul (Import/Export Data statt Restore), die ihren eigenen, anderen Logikfehler hatte (invertierte Backslash-Escape-Semantik statt eines durch BOM ausgehebelten Regex-Ankers). Der Fix lehnt jeden Backslash innerhalb eines in einfache Anführungszeichen gesetzten Strings in der Abfrage vollständig ab, anstatt eine der beiden möglichen psql-Interpretationen zu wählen. Dies ist bewusst konservativ: Da die korrekte Interpretation von \ von der standard_conforming_strings-Einstellung des Zielservers abhängt, die der Prüfer zum Validierungszeitpunkt nicht zuverlässig kennen kann, ist die Verweigerung der Abfrage sicherer als eine Vermutung. Dieses Problem betrifft pgAdmin 4: von der Einführung von _is_query_parens_balanced() vor 9.18.