Postgres Pro закрыл 28 уязвимостей PostgreSQL внеочередными релизами

Postgres Professional 2 сентября сообщила о выходе «нулевых» релизов Postgres Pro Enterprise: внеочередных обновлений безопасности, которые переносят в корпоративную редакцию исправления 28 уязвимостей и более 110 ошибок из августовского обновления PostgreSQL. По словам компании, она первая и пока единственная среди коммерческих форков на российском рынке, кто довёл эти исправления до редакции уровня enterprise.

Если ваш прод стоит на Postgres Pro Enterprise, это тот случай, когда обновляться нужно не по плану, а сейчас: среди закрытых проблем четырнадцать с оценкой CVSS 8,8, и для одиннадцати из них upstream прямо пишет о выполнении произвольного кода, причём часть срабатывает через обычные SQL-функции вроде to_char() или через регулярные выражения. Если вы на ванильном PostgreSQL, те же исправления вышли ещё 13 августа в версиях 18.6, 17.11, 16.15, 15.19 и 14.24, и проверить стоит, что вы их уже накатили.

Что такое «нулевой» релиз

Обычный цикл коммерческого форка выглядит так: выходит минорный релиз upstream PostgreSQL, вендор переносит исправления в свою ветку, тестирует вместе с собственными доработками и выпускает очередную минорную версию, где безопасность идёт вперемешку с новыми функциями. Для заказчика это означает выбор: либо ждать плановый релиз с открытыми дырами, либо ставить его сразу и получать вместе с патчами новую функциональность, которую никто не тестировал в его контуре.

«Нулевой» релиз разрывает эту связку. Он собирается на базе предыдущего минорного релиза Postgres Pro Enterprise, в него переносятся только исправления из актуальной версии PostgreSQL, и никаких новых возможностей там нет. Доработки, отложенные ради скорости, выйдут позже в привычных минорных версиях по обычному циклу. Технический директор Postgres Professional Юлия Рыденкова объясняет это так: «Заказчик может установить необходимые исправления сразу, не дожидаясь следующего планового обновления и не внедряя одновременно с этим новые возможности продуктов».

Подход не новый для индустрии: примерно так устроены security-only ветки у дистрибутивов Linux. Для российского рынка СУБД, где заказчики часто сидят на сертифицированных редакциях с долгим циклом обновления, разделение потоков «безопасность» и «функции» снимает главный аргумент против быстрого патчинга.

Какие уязвимости закрыты

Все 28 CVE перечислены в анонсе PostgreSQL от 13 августа. Четырнадцать из них имеют максимальную в этом наборе оценку CVSS 8,8; Postgres Professional выделяет одиннадцать, где по описанию upstream возможно выполнение произвольного кода:

• CVE-2026-14664: переполнение буфера в обработке регулярных выражений.
• CVE-2026-14669: переполнение буфера в функции to_char().
• CVE-2026-14670: переполнение буфера в связанных (tied) объектах PL/Perl.
• CVE-2026-14671: путаница типов в кэше планов contrib/refint.
• CVE-2026-14676: переполнение буфера в pg_stat_statements.
• CVE-2026-14680: путаница типов через аргументы типа internal.
• CVE-2026-15741: SQL-инъекция через аргумент функции EXTRACT() при обратном разборе (deparse) выражений.
• CVE-2026-16238 и CVE-2026-16239: путаница типов в pg_restore_attribute_stats() и в связке CLOSE + DECLARE курсоров.
• CVE-2026-18408: команда psql \unrestrict позволяла суперпользователю сервера-источника pg_dump выполнить произвольный код в клиенте psql при восстановлении дампа.
• CVE-2026-19385: переполнение буфера в pg_dump.

Ещё две проблемы стоят отдельно. CVE-2026-6471 (CVSS 7,2): пользователь с правами на репликацию мог заставить логическое декодирование подгрузить произвольную библиотеку через dlopen. После исправления список разрешённых плагинов вывода ограничен новым параметром output_plugin_libraries, и если у вас работает логическая репликация с нестандартными плагинами, их нужно туда прописать. CVE-2026-6464 (CVSS 8,1) касается psql: при раннем сбое команды COPY FROM STDIN или \copy FROM STDIN строки данных могли быть разобраны как команды psql. Для эксплуатации нужен контроль и над серверной ошибкой, и над данными COPY; вариант COPY FROM с именем файла не затронут.

Ещё три уязвимости с оценкой 8,8 в этот список компания не включила: недоразмерные выделения памяти в tsvector и tsquery (CVE-2026-14662), в 32-битных pltcl и plperl (CVE-2026-14677) и запись по произвольным адресам в fuzzystrmatch (CVE-2026-15742). Остальные пункты списка, от раскрытия существования пользователя через нестандартное число итераций SCRAM (CVE-2026-14672, CVSS 5,3) до чтения за границей буфера в функции ascii() (CVE-2026-18024, CVSS 4,3), имеют оценки от 3,8 до 8,2. Компания отмечает, что несколько уязвимостей, в частности CVE-2026-16239 и CVE-2026-14680, найдены исследователями при участии ИИ-инструментов Claude и Codex Security.

Что делать после обновления

Обновления накопительные: выгружать и загружать базы или запускать pg_upgrade не нужно, достаточно штатно остановить сервер и заменить бинарные файлы. Но после этого Postgres Professional, как и upstream в своём анонсе, просит выполнить несколько проверок, потому что часть исправлений затрагивает индексы:

1. Проверить таблицы с GIN-индексами и выполнить ANALYZE, если значение reltuples выглядит некорректным (исправлена ошибка параллельной сборки GIN).
2. Переиндексировать btree_gist-индексы на столбцах типов float4, float8, bit и bit varying, если они есть.
3. Переиндексировать B-tree-индексы по столбцам ltree, если значения могут содержать больше 14 653 меток.
4. Проверить конфигурацию логического декодирования и добавить доверенные плагины в output_plugin_libraries.

Пользователям ванильного PostgreSQL стоит помнить ещё об одном: ветка 14 перестанет получать исправления 12 ноября 2026 года, а версии 18.4 и 18.5 не выходили вовсе, ветка 18 перескочила с 18.3 сразу на 18.6 из-за регрессии в 18.5.

Почему компания торопится

Postgres Professional прямо связывает формат «нулевых» релизов с регуляторикой. С 1 марта 2026 года действует приказ ФСТЭК России №117 от 11 апреля 2025 года о защите информации в государственных информационных системах и системах госорганов и госучреждений: уязвимости критического уровня нужно устранить или закрыть компенсирующими мерами за 24 часа, высокого уровня за 7 календарных дней, а если уязвимости нет в БДУ ФСТЭК, сведения о ней нужно направить в службу в течение 5 рабочих дней. На коммерческие компании приказ напрямую не распространяется, но именно госзаказчики составляют заметную часть пользователей сертифицированных редакций, и для них ждать плановый релиз вендора с патчем невозможно: сроки считаются с момента выявления.

Второй фактор, который называет компания: ИИ-инструменты резко ускорили поиск дефектов. В качестве примера Postgres Professional ссылается на программу координированного раскрытия уязвимостей Anthropic, в которой модель Claude нашла и передала мейнтейнерам сотни проблем в проектах с открытым кодом; две CVE из сегодняшнего списка тоже найдены с участием ИИ. Чем быстрее находят, тем важнее способность вендора быстро адаптировать и протестировать upstream-патч для своей редакции.

Чего в сообщении нет: точных номеров «нулевых» версий по веткам и ссылок на страницы загрузки. Не сказано и о сроках аналогичных релизов для редакции Postgres Pro Standard. Следующая точка на календаре для всех пользователей PostgreSQL, плановое квартальное обновление upstream в ноябре; будет ли к нему «нулевой» релиз и как быстро, компания не обещала.

Источники: Postgres Professional: новость на Хабре, PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released, PostgreSQL: Security Information

Изображение на обложке: Изображение: Postgres Professional