CVE-2026-17351

Riepilogo

La correzione per CVE-2026-12045 in pgAdmin 4 9.16 richiedeva che la query fornita dall'LLM passata allo strumento execute_sql_query dell'Assistente AI fosse analizzata, tramite sqlparse, come esattamente una singola istruzione non di controllo delle transazioni prima di essere eseguita all'interno di un wrapper BEGIN TRANSACTION READ ONLY. La tokenizzazione delle stringhe letterali di sqlparse può essere in disaccordo con il parser di PostgreSQL: con standard_conforming_strings = on (impostazione predefinita di PostgreSQL dalla 9.1), una barra rovesciata immediatamente prima di una virgoletta è un carattere ordinario per PostgreSQL, ma sqlparse la tratta come se facesse l'escaping della virgoletta. Un payload come SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' viene quindi analizzato come un singolo SELECT dal validatore di sqlparse, mentre PostgreSQL lo esegue come quattro istruzioni: la COMMIT contrabbandata termina la transazione di sola lettura wrapper, e la ROLLBACK finale diventa un no-op. Questo reintroduce la stessa bypass di scrittura/RCE che CVE-2026-12045 doveva chiudere, raggiungibile tramite lo stesso vettore di consegna indiretto tramite prompt injection (un attaccante inserisce il payload in qualsiasi oggetto che l'Assistente AI possa leggere; l'LLM lo emette come chiamata di strumento). Una correzione candidata iniziale eseguiva la query con psycopg's execute(..., prepare=True), con l'intenzione di forzare il passo Parse di PostgreSQL (protocollo di query esteso) a rifiutare testo multi-istruzione indipendentemente dalla classificazione di sqlparse. Questa correzione candidata non funziona come presentata: il PrepareManager di psycopg3 ignora silenziosamente l'argomento prepare ogni volta che prepare_threshold della connessione è None, che è l'impostazione predefinita di pgAdmin per ogni connessione al server (il campo "Prepare threshold" per-server è vuoto a meno che un amministratore non lo imposti esplicitamente) — psycopg3 ripiega sul protocollo di query semplice, lo stesso percorso capace di multi-istruzione che la bypass sfrutta, quindi la correzione candidata non chiude nulla in qualsiasi configurazione predefinita reale. La correzione corretta imposta conn.prepare_threshold = 0 direttamente sulla connessione di sola lettura dedicata e monouso che lo strumento dell'Assistente AI apre, forzando strutturalmente il protocollo di query esteso indipendentemente da qualsiasi configurazione a livello di server. Verificato contro un'istanza PostgreSQL 18 live: il payload viene eseguito con successo sotto il comportamento prepare_threshold=None (predefinito), e viene rifiutato con "cannot insert multiple commands into a prepared statement" una volta che prepare_threshold=0 è impostato su quella connessione. Questo problema riguarda pgAdmin 4: dalla 9.13 prima della 9.17.

Fonti

• pgadmin-ai-assistant-sql-injection-cve-2026-17351-lexer-differential-bypassPoC

  Proof-of-concept che dimostra il bypass dell'iniezione SQL CVE-2026-17351 nell'AI Assistant di pgAdmin 4 tramite il differenziale dei lexer sqlparse/PostgreSQL, inclusa la veicolazione di un'iniezione di prompt indiretta.