В популярном инструменте администрирования PostgreSQL, pgAdmin 4, обнаружена критическая уязвимость, позволяющая удалённым злоумышленникам обходить встроенные средства защиты и выполнять произвольные команды на целевом сервере. Уязвимость, получившая идентификатор CVE-2025-13780, связана с недостатками в обработке файлов восстановления базы данных и была оценена как критическая, поскольку она напрямую ведёт к удалённому выполнению кода (Remote Code Execution, RCE).
Делатели уязвимости
Как выяснили исследователи безопасности, проблема кроется в функции восстановления базы данных из обычного текстового SQL-файла. Когда пользователь запускает эту операцию, приложение для обработки данных вызывает утилиту командной строки "psql". Важно отметить, что "psql" поддерживает мощные метакоманды, которые могут запускать команды операционной системы. Следовательно, разработчики pgAdmin попытались блокировать такие опасные инструкции с помощью проверки регулярными выражениями (regex). Этот фильтр, названный "regex firewall", был предназначен для отклонения файлов, содержащих метакоманды, например, восклицательный знак ("!"), выполняющий сценарии командной оболочки.
Однако произошёл критический сбой безопасности. Оказалось, что фильтр регулярных выражений был составлен слишком жёстко. Он искал обратную косую черту, обозначающую метакоманду в "psql", только в самом начале строки или сразу после стандартного символа перевода строки ("\n"). Исследователи обнаружили, что вставка альтернативных пробельных символов, таких как возврат каретки ("\r"), между переводом строки и командой позволяет скрыть вредоносный (malicious) код от фильтра. Таким образом, возникало опасное несоответствие: написанный на Python фильтр распознавал текст как безопасный, а нижележащий интерпретатор "psql" обрабатывал последовательность как корректный перевод строки и исполнял команду.
По данным компании Endor Labs, это несоответствие позволяло злоумышленникам создавать специально сформированные SQL-файлы, которые выглядели безобидными для pgAdmin, но при обработке запускали выполнение кода. В демонстрационном подтверждении концепции (proof-of-concept) исследователям удалось создать файл, который при восстановлении немедленно выполнял произвольные команды оболочки на хост-сервере, где работал pgAdmin. Это предоставляло атакующему полный контроль над системой, что является классическим сценарием для уязвимостей типа RCE.
Команда разработчиков исправила эту проблему в pgAdmin 4 версии 9.11, кардинально изменив подход к безопасности. Вместо того чтобы пытаться отфильтровать входной файл с помощью сложного сопоставления текста, приложение теперь запускает процесс восстановления с ключом "--restrict". Эта директива принудительно отключает потенциально опасные метакоманды непосредственно в интерпретаторе "psql" на время выполнения операции. Данный метод обеспечивает гораздо более надёжную защиту, поскольку полагается на внутренние механизмы безопасности самого инструмента базы данных, а не на внешний текстовый сканер.
Администраторам настоятельно рекомендуется немедленно обновиться до версии 9.11 или более поздней, чтобы устранить данный риск. Как подчёркивают эксперты, заплатки, основанные на регулярных выражениях для сложных парсеров, часто оставляют остаточные бреши, которыми могут воспользоваться атакующие. Переход на использование встроенной функции "--restrict" считается более элегантным и безопасным решением. Своевременное обновление программного обеспечения остаётся ключевой практикой кибергигиены для предотвращения эксплуатации подобных критических уязвимостей.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2025-13780
- https://github.com/pgadmin-org/pgadmin4/issues/9368
- https://www.endorlabs.com/learn/when-regex-isnt-enough-how-we-discovered-cve-2025-13780-in-pgadmin
- https://github.com/meenakshisl/PoC-CVE-2025-13780
