CVE-2025-1094
PostgreSQL: SQL-инъекция через quoting API при некорректной кодировке
CVE-2025-1094 затрагивает функции quoting в libpq и некоторые утилиты PostgreSQL при специальных сочетаниях кодировок и способов передачи данных. Проверьте версии клиента и сервера, сценарии вызова PQescape* и использование psql: обновление до исправленного minor-релиза устраняет проблему, но не требует считать любую SQL-строку уязвимой автоматически.
Кому нужно проверить
Администраторам PostgreSQL, разработчикам приложений на libpq, владельцам интеграций с psql и сопровождающим образов/пакетов PostgreSQL. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
В соответствующем сценарии поставщик данных может добиться выполнения SQL-инъекции через недостаточно нейтрализованные quoting-конструкции. Риск зависит от того, как приложение передаёт результат API, какие кодировки разрешены и используется ли затронутый клиентский путь.
Затронутые версии
По официальному advisory PostgreSQL затронуты версии до 17.3, 16.7, 15.11, 14.16 и 13.19 соответственно. SQL-инъекция через libpq API требует, чтобы результат функции использовался для формирования входа psql; для командных утилит указано специальное сочетание client_encoding BIG5 и server_encoding EUC_TW или MULE_INTERNAL.
Исправленные версии
Исправления опубликованы в PostgreSQL 17.3, 16.7, 15.11, 14.16 и 13.19. Установите актуальный поддерживаемый minor-релиз своей ветки и проверьте backport пакетного поставщика, особенно если клиентские библиотеки и сервер устанавливаются отдельно.
Что сделать
- 1Зафиксируйте версии отдельно для сервера, libpq и клиентских утилит: проверьте PostgreSQL server_version, пакетный менеджер и фактически загруженную libpq. Версия драйвера приложения может отличаться от версии сервера.
- 2Проверьте код, который вызывает PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() или PQescapeStringConn(), особенно если результат затем формирует команду для psql. Предпочитайте параметризованные запросы и не используйте psql как универсальный исполнитель непроверенного текста.
- 3Проверьте настройки client_encoding и server_encoding в затронутых интеграциях. Не меняйте кодировку вслепую в production: сначала оцените совместимость данных, драйверов и миграций.
- 4Обновите серверные и клиентские пакеты до 17.3, 16.7, 15.11, 14.16 или 13.19 либо более нового поддерживаемого minor-релиза. Проверьте advisory дистрибутива для backport и перезапустите процессы, чтобы они загрузили новую libpq.
- 5На staging выполните безопасные тесты подключения, миграций и ключевых интеграций, затем проверьте логи после выкладки. Не вставляйте реальные секреты или пользовательские данные в диагностические команды и тестовые запросы.
- 6Если используется неподдерживаемая ветка PostgreSQL, спланируйте миграцию на поддерживаемую. WAF и BotProtection могут сократить автоматизированный шум, но не исправляют клиентскую библиотеку или ошибку quoting.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.