CVE-2026-17351

Резюме

Исправление для CVE-2026-12045 в pgAdmin 4 9.16 требовало, чтобы запрос, предоставленный LLM и переданный в инструмент execute_sql_query AI-ассистента, разбирался через sqlparse ровно как один оператор, не относящийся к управлению транзакциями, перед его выполнением внутри обёртки BEGIN TRANSACTION READ ONLY. Лексический анализ строковых литералов в sqlparse может расходиться с собственным парсером PostgreSQL: при standard_conforming_strings = on (значение по умолчанию в PostgreSQL начиная с 9.1) обратная косая черта непосредственно перед кавычкой является обычным символом для PostgreSQL, но sqlparse трактует её как экранирование кавычки. Поэтому такая нагрузка, как SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --', разбирается валидатором sqlparse как один оператор SELECT, тогда как PostgreSQL выполняет её как четыре оператора: протащенный COMMIT завершает обёртывающую транзакцию только для чтения, а завершающий ROLLBACK становится no-op. Это повторно вводит тот же обход записи/RCE, который CVE-2026-12045 должна была закрыть, и он достижим через ту же косвенную доставку с помощью инъекции в промпт (злоумышленник размещает нагрузку в любом объекте, который AI-ассистент может прочитать; LLM выдаёт её как вызов инструмента). Первоначальный кандидат исправления выполнял запрос с помощью psycopg execute(..., prepare=True), намереваясь заставить собственный этап Parse в PostgreSQL (протокол расширенных запросов) отклонять многооператорный текст независимо от классификации sqlparse. Этот кандидат исправления не работает в представленном виде: PrepareManager в psycopg3 молча игнорирует аргумент prepare, когда prepare_threshold соединения равен None, что является значением по умолчанию pgAdmin для каждого серверного соединения (поле «Prepare threshold» для сервера пусто, если администратор явно не задал его) — psycopg3 откатывается к простому протоколу запросов, тому же пути, допускающему многооператорность, который использует обход, поэтому кандидат исправления ничего не закрывает ни в одной реальной конфигурации по умолчанию. Исправленное решение устанавливает conn.prepare_threshold = 0 непосредственно на выделенном одноразовом соединении только для чтения, которое открывает инструмент AI-ассистента, структурно принудительно включая протокол расширенных запросов независимо от какой-либо конфигурации на уровне сервера. Проверено на работающем экземпляре PostgreSQL 18: нагрузка успешно выполняется при поведении prepare_threshold=None (по умолчанию) и отклоняется с сообщением «cannot insert multiple commands into a prepared statement», как только на этом соединении установлено prepare_threshold=0. Эта проблема затрагивает pgAdmin 4: с 9.13 до 9.17.