Инструмент импорта/экспорта данных pgAdmin 4 создает командную строку psql \copy (...) путем интерполяции предоставленного пользователем SQL-запроса в шаблон Jinja и передачи обработанной строки в psql через --command. Чтобы помешать злоумышленнику вырваться из оболочки (...), функция create_import_export_job() (маршрут POST /import_export/job/<sid>, доступный только с помощью обычного, общедоступного разрешенияtools_import_export_data) проверила запрос с помощью написанной вручную программы проверки баланса скобок _is_query_parens_balanced(). Эта программа проверки всегда рассматривала обратную косую черту перед одинарной кавычкой (\') как экранирующую кавычку, т. е. как если бы параметр Standard_conforming_strings был отключен. PostgreSQL по умолчанию включил стандартные_конформирующие_строки с версии 9.1 (2010 г.), значение по умолчанию для каждой версии PostgreSQL, которую в настоящее время поддерживает pgAdmin 4 (13-18); при этом по умолчанию собственный токенизатор \copy psql обрабатывает \ как обычный символ, поэтому одинарная кавычка сразу после нее закрывает строковый литерал.
Таким образом, такой запрос, как SELECT 'a\') TO PROGRAM 'echo pwned' x', был принят как "сбалансированный" программой проверки pgAdmin (которая полагала, что ) все еще находится внутри строки), в то время как psql, запускаемый через фактическую визуализированную командную строку, закрывает строку в этой точке и обрабатывает следующую ) как конец оберточного подзапроса \copy (...), раскрывая выбранный злоумышленником TO PROGRAM '<command>' предложение, которое psql выполняет через popen() - независимо от последующей синтаксической ошибки позже в той же строке. Это тот же класс ошибок, что и CVE-2025-12762/CVE-2025-13780 (RCE через метакоманду psql/внедрение COPY во время восстановления дампа в формате PLAIN), достигнутый с помощью независимо написанной защиты в другом модуле (импорт/экспорт данных, а не восстановление), который имел свою собственную, другую логическую ошибку (семантика инвертированного обратного слеша-экранирования, а не регулярное выражение, побежденное спецификацией BOM). якорь). Исправление полностью отклоняет любую обратную косую черту внутри строки в одинарных кавычках в запросе, вместо того, чтобы выбирать одну из двух возможных интерпретаций psql.
Это намеренно консервативно: поскольку правильная интерпретация \ зависит от параметра default_conforming_strings целевого сервера, который проверяющий не может достоверно знать во время проверки, отклонить запрос безопаснее, чем гадать. Эта проблема затрагивает pgAdmin 4: с момента появления _is_query_parens_balanced() до версии 9.18.
Показать оригинальное описание (EN)
pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor). The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing. This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.
Характеристики атаки
Последствия
Строка CVSS v4.0
Тип уязвимости (CWE)
Уязвимые продукты 1
| Конфигурация | От (включительно) | До (исключительно) |
|---|---|---|
|
Pgadmin Pgadmin_4
cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*
|
— |
9.18
|