CVE-2026-17351

Resumo

A correção para CVE-2026-12045 no pgAdmin 4 9.16 exigia que a consulta fornecida pela LLM passada para a ferramenta execute_sql_query do AI Assistant fosse analisada, via sqlparse, como exatamente uma única instrução que não fosse de controle de transação antes de ser executada dentro de um wrapper BEGIN TRANSACTION READ ONLY. A análise de literais de string do sqlparse pode discordar do próprio parser do PostgreSQL: com standard_conforming_strings = on (o padrão do PostgreSQL desde 9.1), uma barra invertida imediatamente antes de uma aspa é um caractere comum para o PostgreSQL, mas o sqlparse a trata como escape da aspa. Um payload como SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' portanto é analisado como um único SELECT pelo validador do sqlparse, enquanto o PostgreSQL o executa como quatro instruções: o COMMIT contrabandeado encerra a transação somente leitura do wrapper, e o ROLLBACK final torna-se um no-op. Isso reintroduz a mesma bypass de escrita/RCE que CVE-2026-12045 pretendia fechar, alcançável pela mesma entrega indireta de injeção de prompt (um atacante planta o payload em qualquer objeto que o AI Assistant possa ler; a LLM o emite como uma chamada de ferramenta). Uma correção candidata inicial executava a consulta com execute(..., prepare=True) do psycopg, pretendendo forçar a própria etapa Parse do PostgreSQL (protocolo de consulta estendido) a rejeitar texto com múltiplas instruções, independentemente da classificação do sqlparse. Essa correção candidata não funciona como submetida: o PrepareManager do psycopg3 ignora silenciosamente o argumento prepare sempre que o prepare_threshold da conexão é None, que é o padrão do pgAdmin para toda conexão de servidor (o campo "Prepare threshold" por servidor fica em branco a menos que um administrador o defina explicitamente) — o psycopg3 recorre ao protocolo de consulta simples, o mesmo caminho com capacidade de múltiplas instruções que a bypass explora, então a correção candidata não fecha nada em qualquer configuração padrão do mundo real. A correção corrigida define conn.prepare_threshold = 0 diretamente na conexão somente leitura dedicada e de uso único que a ferramenta do AI Assistant abre, forçando estruturalmente o protocolo de consulta estendido, independentemente de qualquer configuração no nível do servidor. Verificado contra uma instância PostgreSQL 18 ativa: o payload é executado com sucesso sob o comportamento prepare_threshold=None (padrão) e é rejeitado com "cannot insert multiple commands into a prepared statement" uma vez que prepare_threshold=0 é definido nessa conexão. Esse problema afeta o pgAdmin 4: da versão 9.13 até antes da 9.17.