PostgreSQL закрыл 52 уязвимости одним релизом, а ветка 14 больше не получит патчей
52 исправленные уязвимости в одном выпуске и последнее обновление ветки PostgreSQL 14. Коротко: что исправили, что сделать на серверах и почему после обновления нужен REINDEX.
12 ноября 2026 года PostgreSQL Global Development Group выпустила PostgreSQL 18.7, 17.12, 16.16, 15.20 и 14.25, а также второй релиз-кандидат PostgreSQL 19. Обновление закрывает 52 уязвимости и исправляет больше 140 ошибок. Новость в тот же день разобрал Phoronix.
Обновлять придётся всем, у кого PostgreSQL стоит в продакшене, а у такой базы часто не один владелец. Если на ней работает бэкенд мобильного приложения, обновить СУБД должен тот, кто отвечает за серверную часть. При разработке и поддержке мобильного приложения у подрядчика вроде YuSMP Group стоит заранее закрепить в договоре, кто и в какой срок ставит такие патчи на сервер API и кто проверяет приложение после обновления.
Какие уязвимости закрыты
Для 32 уязвимостей оценка CVSS 3.1 — 8.8. Их общий сценарий такой: пользователь с обычной учётной записью в базе может выполнить произвольный код от имени системного пользователя, под которым работает сервер PostgreSQL. Среди них:
- путаница типов после
ALTER ... SET DATA TYPE(CVE-2026-6460); - use-after-free в
plperl; - переполнения буфера в функциях полнотекстового поиска
tsvector_delete()иts_rank_cd().
Отдельно стоит CVE-2026-120145: логическая репликация может писать в системные каталоги подписчика.
Что значит конец PostgreSQL 14
Выпуск 14.25 — последний для ветки 14, она вышла в сентябре 2021 года. Следующая уязвимость, найденная в PostgreSQL 14, исправлена уже не будет. Переходить стоит на поддерживаемую ветку: 15, 16, 17 или 18. Выход PostgreSQL 19 запланирован на 19 ноября. Для мажорного перехода нужен pg_upgrade или выгрузка через dump/restore. Обновление внутри своей ветки делается проще: остановить сервер и заменить бинарные файлы.
Что сделать после обновления
- Поставьте минорную версию из репозитория своего дистрибутива или из официальных репозиториев PGDG и перезапустите сервис.
- Перестройте GIN-индексы: в выпуске исправлена ошибка, из-за которой запрос по такому индексу мог пропускать нужные строки или возвращать лишние.
- Перестройте GiST-индексы с
gist_trgm_opsиз расширения pg_trgm и B-tree-индексы на столбцахbpcharбез указания длины (наchar(n)это не распространяется). - Если пользуетесь инкрементальными бэкапами, снимите после обновления новый полный бэкап и стройте следующие инкременты от него.
- На партиционированных таблицах проверьте ограничения
NOT NULL NO INHERIT: запрос для поиска есть в примечаниях к выпуску.
Перестройку индексов на нагруженной базе удобнее делать через REINDEX CONCURRENTLY: в этом выпуске заодно исправили и его ошибку с номерами чанков. Как настроить сервер после обновления, мы разбирали в материале о настройке и тюнинге PostgreSQL на Linux. Про резервные копии перед любыми работами с базой — в статье о стратегии бэкапов 3-2-1.