CVE-2026-17566 in pgAdmin
Zusammenfassung
von VulDB • 31.07.2026
Das Import/Export-Daten-Tool von pgAdmin 4 erstellt eine psql `\copy (...)`-Befehlszeile, indem es eine vom Benutzer bereitgestellte SQL-Abfrage in ein Jinja-Vorlagenformat interpoliert und die gerenderte Zeile über `--command` an psql übergibt. Um zu verhindern, dass ein Angreifer aus der `( ... )`-Umhüllung ausbricht, validierte `create_import_export_job()` (Route POST `/import_export/job/<sid>`, geschützt nur durch die übliche und allgemein gewährte Berechtigung `tools_import_export_data`) die Abfrage mit einem handgeschriebenen Klammer-Ausgleichsprüfer `_is_query_parens_balanced()`. Dieser Prüfer behandelte einen Backslash vor einem einfachen Anführungszeichen (`\'`) stets als Escaping des Anführungszeichens, d. h., so als ob `standard_conforming_strings` deaktiviert wäre. PostgreSQL hat `standard_conforming_strings` seit Version 9.1 (2010) standardmäßig auf aktiv gesetzt; dies ist die Vorgabe für jede von pgAdmin 4 aktuell unterstützte PostgreSQL-Version (13–18). Unter dieser Standardvorgabe behandelt der eigene `\copy`-Tokenizer von psql den Backslash als gewöhnliches Zeichen, sodass ein einfaches Anführungszeichen unmittelbar danach das Stringliteral schließt. Eine Abfrage wie `SELECT 'a\') TO PROGRAM 'echo pwned' x'` wurde daher vom pgAdmin-Prüfer als „ausgewogen“ akzeptiert (der Prüfer ging davon aus, dass die `)` noch innerhalb des Strings liegt), während psql, ausgeführt über die tatsächlich gerenderte Befehlszeile, den String an dieser Stelle schließt und das folgende `)` als Ende der umhüllenden `\copy (...)`-Unterabfrage behandelt. Dies offenbart eine vom Angreifer gewählte `TO PROGRAM '<command>'`-Klausel, die psql über `popen()` ausführt – unabhängig von einem späteren Syntaxfehler in derselben Zeile. Es handelt sich hierbei um dieselbe Fehlerklasse wie bei CVE-2025-12762/CVE-2025-13780 (RCE via psql-Meta-Befehl-/COPY-Injection während der Wiederherstellung eines PLAIN-Format-Dumps), erreicht durch eine unabhängig geschriebene Verteidigungsmaßnahme in einem anderen Modul (Import/Export Data statt Restore), die ihren eigenen, unterschiedlichen Logikfehler aufwies (invertierte Backslash-Escaping-Semantik anstelle einer BOM-umgehungsfähigen Regex-Anker).
Die Korrektur lehnt jeden Backslash innerhalb eines einfach angeführten Strings in der Abfrage pauschal ab, statt sich für eine der beiden möglichen psql-Interpretationen zu entscheiden. Dies ist bewusst konservativ gestaltet: Da die korrekte Interpretation von `\` vom `standard_conforming_strings`-Einstellung des Zielservers abhängt, was der Prüfer zur Validierungszeit nicht zuverlässig wissen kann, ist das Zurückweisen der Abfrage sicherer als ein Raten.
Dieses Problem betrifft pgAdmin 4: ab der Einführung von `_is_query_parens_balanced()` vor Version 9.18.
VulDB is the best source for vulnerability data and more expert information about this specific topic.