Исправление CVE-2026-12045 в pgAdmin 4 9.16 требовало, чтобы запрос, предоставленный LLM, передавался в инструмент Execute_sql_query AI Assistant для анализа через sqlparse как ровно один оператор, не связанный с управлением транзакциями, прежде чем запускать его внутри оболочки BEGIN TRANSACTION READ ONLY. Лексия строковых литералов в sqlparse может не соответствовать собственному синтаксическому анализатору PostgreSQL: в соответствии со стандартом_conforming_strings = on (по умолчанию в PostgreSQL, начиная с версии 9.1), обратная косая черта непосредственно перед кавычкой является обычным символом для PostgreSQL, но sqlparse рассматривает ее как экранирующую кавычку. Полезная нагрузка, такая как SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --', таким образом, анализируется как один SELECT для валидатора sqlparse, в то время как PostgreSQL выполняет ее как четыре оператора: контрабандный COMMIT завершает обертывающую транзакцию только для чтения, а завершающий ROLLBACK становится пустым.
Это вновь вводит тот же обход записи/RCE, который должен был закрыть CVE-2026-12045, доступный через ту же непрямую доставку подсказки (злоумышленник помещает полезную нагрузку в любой объект, который может прочитать AI Assistant; LLM отправляет ее как вызов инструмента). Первоначальный кандидат на исправление запускал запрос с помощью выполнения psycopg (..., подготовить = True), намереваясь заставить собственный шаг анализа PostgreSQL (расширенный протокол запроса) отклонять текст из нескольких операторов независимо от классификации sqlparse. Это потенциальное исправление не работает в том виде, в котором оно было отправлено: psycopg3's AcceptManager молча игнорирует аргумент подготовки всякий раз, когда для соединения подготовлено значение None, что является значением по умолчанию pgAdmin для каждого подключения к серверу (поле «Порог подготовки» для каждого сервера остается пустым, если администратор явно не задает его) - psycopg3 возвращается к простому протоколу запроса, тому же пути с поддержкой нескольких операторов, который используется обходным путем, поэтому исправление-кандидат ничего не закрывает ни на одном из них. реальная конфигурация по умолчанию.
Исправленное исправление устанавливает conn.prepare_threshold = 0 непосредственно в выделенном одноразовом соединении только для чтения, которое открывает инструмент AI Assistant, структурно заставляя расширенный протокол запросов быть независимым от какой-либо конфигурации на уровне сервера. Проверено на работающем экземпляре PostgreSQL 18: полезная нагрузка успешно выполняется с поведением «prepre_threshold=None» (по умолчанию) и отклоняется с сообщением «невозможно вставить несколько команд в подготовленный оператор», как только для этого соединения установлено значение «preparate_threshold=0». Эта проблема затрагивает pgAdmin 4: с 9.13 до 9.17.
Показать оригинальное описание (EN)
The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call). An initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server "Prepare threshold" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration. The corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with "cannot insert multiple commands into a prepared statement" once prepare_threshold=0 is set on that connection. This issue affects pgAdmin 4: from 9.13 before 9.17.
Характеристики атаки
Последствия
Строка CVSS v4.0