CVE-2026-17351

Résumé

Le correctif pour CVE-2026-12045 dans pgAdmin 4 9.16 exigeait que la requête fournie par le LLM et transmise à l'outil execute_sql_query de l'Assistant IA soit analysée, via sqlparse, comme exactement une seule instruction hors contrôle de transaction avant d'être exécutée dans un wrapper BEGIN TRANSACTION READ ONLY. L'analyse lexicale des littéraux de chaîne de sqlparse peut être en désaccord avec l'analyseur PostgreSQL lui-même : avec standard_conforming_strings = on (le défaut de PostgreSQL depuis 9.1), une barre oblique inverse immédiatement avant un guillemet est un caractère ordinaire pour PostgreSQL, mais sqlparse la traite comme échappant le guillemet. Une charge utile telle que SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' est donc analysée comme une seule instruction SELECT par le validateur de sqlparse, tandis que PostgreSQL l'exécute comme quatre instructions : le COMMIT dissimulé met fin à la transaction en lecture seule englobante, et le ROLLBACK final devient une opération sans effet. Cela réintroduit la même contournement d'écriture/RCE que CVE-2026-12045 était censé fermer, accessible via le même vecteur indirect d'injection par invite (un attaquant place la charge utile dans tout objet que l'Assistant IA peut lire ; le LLM l'émet comme un appel d'outil). Un correctif candidat initial exécutait la requête avec psycopg's execute(..., prepare=True), visant à forcer l'étape Parse de PostgreSQL elle-même (protocole de requête étendu) à rejeter le texte multi-instructions indépendamment de la classification de sqlparse. Ce correctif candidat ne fonctionne pas tel que soumis : le PrepareManager de psycopg3 ignore silencieusement l'argument prepare chaque fois que le prepare_threshold de la connexion est None, ce qui est le défaut de pgAdmin pour chaque connexion serveur (le champ « Prepare threshold » par serveur est vide à moins qu'un administrateur ne le définisse explicitement) — psycopg3 retombe sur le protocole de requête simple, le même chemin capable de multi-instructions que la contournement exploite, donc le correctif candidat ne ferme rien sur toute configuration par défaut réelle. Le correctif corrigé définit conn.prepare_threshold = 0 directement sur la connexion en lecture seule dédiée et à usage unique que l'outil de l'Assistant IA ouvre, forçant structurellement le protocole de requête étendu indépendamment de toute configuration au niveau serveur. Vérifié contre une instance PostgreSQL 18 en direct : la charge utile s'exécute avec succès sous le comportement prepare_threshold=None (défaut), et est rejetée avec « cannot insert multiple commands into a prepared statement » une fois prepare_threshold=0 défini sur cette connexion. Ce problème affecte pgAdmin 4 : de 9.13 avant 9.17.