PostgreSQL 18.7 и 14.25: 52 уязвимости в одном выпуске, ветка 14 закрыта

Что случилось

12 ноября проект PostgreSQL выпустил плановые обновления всех поддерживаемых веток: 18.7, 17.12, 16.16, 15.20 и 14.25, а также второй кандидат в релиз PostgreSQL 19. В одном выпуске закрыто 52 уязвимости и более 140 ошибок. Выпуск 14.25 — последний для ветки PostgreSQL 14: она объявлена снятой с поддержки и больше не будет получать исправлений безопасности.

Детали

Среди исправленных проблем есть группа с оценкой 8,8 по CVSS, и почти все они ведут к выполнению произвольного кода в процессе сервера или клиентских утилит:

• CVE-2026-116314 — pg_restore выполняет произвольный код из-за отсутствия проверки не-plain архивов;
• CVE-2026-116315 и CVE-2026-116317 — переполнения буфера в tsvector_delete() и ts_rank_cd();
• CVE-2026-116307, CVE-2026-116309, CVE-2026-116319, CVE-2026-116320, CVE-2026-116326 — use-after-free и путаница типов в plperl, в том числе при повторном вызове return_next();
• CVE-2026-116318 — SQL-инъекция через имя NOT NULL-ограничения в pg_dump;
• CVE-2026-6460 — путаница типов после ALTER ... SET DATA TYPE, тоже с выполнением кода.

Есть и проблемы с утечкой данных и обходом прав: CVE-2026-14661 позволяет dblink и подпискам дописывать данные в произвольные файлы (8,1), CVE-2026-116311 даёт снять ограничительные политики row security с чужих таблиц, CVE-2026-116313 — выполнить код от имени пользователя, запустившего vacuumdb --missing-stats-only. Уязвимость CVE-2026-116322 требует лишь одного запроса на отмену до аутентификации, чтобы исчерпать спинлок.

Что это значит

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

• переиндексировать GIN-индексы, если есть подозрение на затронутое повреждением содержимое, и GiST-индексы с классом операторов gist_trgm_ops при использовании pg_trgm;
• при ошибках «missing chunk number» переиндексировать таблицу — вместе с ней перестроится и её TOAST-таблица;
• если используются инкрементальные бэкапы, снять новый полный бэкап и строить последующие инкременты уже от него;
• проверить секционированные таблицы на лишние NOT NULL NO INHERIT ограничения — их находит отдельный запрос из инструкции, ненужные удаляются через ALTER TABLE ... DROP CONSTRAINT.

Тем, кто ещё держит PostgreSQL 14 в продакшене, пора планировать переезд: поддержки больше нет, а следующий подобный выпуск их уже не закроет. Отдельный контекст — темп: разработчики признают, что поток отчётов, в значительной части порождённый ИИ-инструментами поиска ошибок, сдвинул график PostgreSQL 19, и нынешний пакет из полусотни CVE — прямое следствие этой нагрузки.