Организация Postgres Professional первой среди коммерческих форков закрыла критические уязвимости PostgreSQL

Postgres Professional выпустила «нулевые» релизы корпоративных редакций СУБД Postgres Pro Enterprise с исправлениями актуальных уязвимостей PostgreSQL. Организация первой и пока единственной среди коммерческих форков на российском рынке перенесла эти исправления в редакции уровня enterprise, предоставив заказчикам защиту от нескольких десятков известных CVE без ожидания следующего функционального релиза.

«Нулевые» релизы Postgres Pro Enterprise — это оперативные обновления безопасности. Они создаются на базе предыдущего минорного релиза с переносом исправлений из актуальной версии PostgreSQL и не содержат новой функциональности. Новые возможности и доработки, отложенные ради скорости, появятся позже — в привычных минорных релизах вида 17.11.1 и так далее, которые выйдут по обычному циклу разработки.

«Для бизнес-систем важно не только быстро закрывать угрозы безопасности, но и сохранять предсказуемость работы. Следовательно мы выпускаем внеочередные обновления безопасности отдельно от функциональных. Клиент может установить необходимые исправления сразу, не дожидаясь следующего планового обновления и не внедряя одновременно с этим новые возможности продуктов. Это даёт возможность оперативно устранить уязвимости без лишних изменений в уже работающей системе», — Юлия Рыденкова, технический директор Postgres Professional.

Что закрывает обновление

Релиз устраняет 28 уязвимостей и более 110 багов, накопленных за последние месяцы. Среди самых серьёзных проблем — уязвимости с максимальной оценкой CVSS 8.8, позволяющие выполнить произвольный исходник:

• CVE-2026-14664 — переполнение буфера в обработке регулярных выражений, ведущее к выполнению кода;

• CVE-2026-14669 — переполнение буфера в функции to_char();

• CVE-2026-14670 — переполнение буфера в связанных объектах PL/Perl;

• CVE-2026-14671 — путаница типов в кеше плана contrib/refint;

• CVE-2026-14676 — переполнение буфера в pg_stat_statements;

• CVE-2026-14680 — путаница типов через аргументы internal;

• CVE-2026-15741 — SQL-инъекция через аргумент функции EXTRACT() при деpapсинге выражений;

• CVE-2026-16238 и CVE-2026-16239 — путаница типов в pg_restore_attribute_stats() и в связке CLOSE + DECLARE курсоров;

• CVE-2026-18408 — возможность выполнить произвольные команды оболочки через psql \unrestrict при восстановлении дампа;

• CVE-2026-19385 — переполнение буфера в pg_dump.

Равным образом закрыта уязвимость CVE-2026-6471, в связи с которой потребитель репликации мог подгрузить произвольную библиотеку для логического декодирования. Теперь список разрешённых модулей ограничен параметром output_plugin_libraries.

CVE-2026-6464 исправляет ошибку в psql: при раннем сбое COPY FROM STDIN или \copy FROM STDIN строки inline-данных могли быть обработаны как команды psql. Для эксплуатации обычно требуется сочетание контроля над серверной ошибкой и данными COPY; скрипт не затрагивает COPY FROM с именем файла.

Интересно, что несколько уязвимостей — например, CVE-2026-16239 и CVE-2026-14680 — обнаружены исследователями безопасности при прямом участии ИИ-инструментов Claude (Anthropic Research) и Codex Security (OpenAI).

Рекомендации по установке

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

После обновления рекомендуется:

• проверить таблицы с GIN-индексами и при необходимости выполнить ANALYZE, если значение reltuples выглядит некорректным;

• переиндексировать btree_gist-индексы на столбцах float4, float8, bit и bit varying, если они используются;

• переиндексировать B-tree-индексы по ltree, если значения могут содержать более 14 653 меток;

• проверить конфигурацию логического декодирования и добавить используемые доверенные плагины в output_plugin_libraries.

Почему важна скорость закрытия CVE

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

Параллельно ИИ-инструменты заметно ускоряют поиск дефектов и анализ кода. Anthropic сообщала, что применяла раннюю версию Claude Mythos Preview в программе координированного раскрытия уязвимостей: к 22 мая 2026 года организация раскрыла 1 596 уязвимостей в 281 open-source проекте, при этом часть результатов ещё находилась на стадиях проверки, раскрытия и исправления.

В таких условиях известная, но не закрытая уязвимость становится всё более существенным риском. Важно не только наличие исправления в исходном PostgreSQL, но и способность поставщика оперативно адаптировать, протестировать и выпустить его для используемой корпоративной редакции.