PostgreSQL закрыла 52 уязвимости, включая RCE с оценкой 8.8, и прекратила поддержку 14

PostgreSQL выпустила внеочередное обновление безопасности: 18.7, 17.12, 16.16, 15.20 и 14.25, а также второй релиз-кандидат 19. В релизе закрыты 52 уязвимости и более 140 ошибок. Многие CVE дают выполнение кода и имеют оценку CVSS 3.1 - 8.8. Ветка PostgreSQL 14 получила последнее обновление и больше не поддерживается. После установки патча администраторам может понадобиться перестроить индексы и сделать новую полную резервную копию.

Что исправлено

PostgreSQL - одна из самых распространённых СУБД, и такое количество security-исправлений за один выпуск случается редко. Большая часть ошибок относится к классам type confusion и use-after-free: СУБД неверно интерпретирует тип данных или обращается к освобождённой памяти, и в ряде случаев это приводит к выполнению произвольного кода. Другая группа - SQL-инъекции в служебных утилитах и обходы проверок прав.

Из критичных по оценке стоит выделить несколько. CVE-2026-6460 (CVSS 3.1 8.8) - type confusion после ALTER ... SET DATA TYPE, который позволяет выполнить произвольный код. CVE-2026-116304 (8.8) - use-after-free при параллельном использовании RECORD с модификатором типа, тоже приводит к выполнению кода. CVE-2026-116314 (8.8) - pg_restore выполняет произвольный код из-за отсутствия проверки non-plain архива. CVE-2026-116318 (8.8) - SQL-инъекция через имя not-null ограничения в pg_dump. CVE-2026-120139 (8.8) - целочисленное переполнение при вычислении размера кортежа, ведущее к выполнению кода. CVE-2026-116315 (8.8) - переполнение буфера в tsvector_delete(), которое также может привести к выполнению кода.

Остальные исправления того же уровня разбросаны по plperl, pltcl, статистике, логической репликации, dblink, расширениям и планировщику. Есть и ошибки с меньшими оценками: SQL-инъекции в reindexdb и pg_dump, обход row security, раскрытие памяти сервера, проблемы с правами в REASSIGN OWNED и CREATE TYPE в pg_temp. Полный перечень из 52 CVE с оценками приведён в анонсе релиза и заметках к выпуску.

Чем это грозит

Выполнение кода в процессе СУБД - это доступ к базе и, в зависимости от прав процесса, к файлам сервера. Для компании это означает риск утечки данных, изменения или удаления записей, а также компрометацию приложений, которые ходят в эту базу. Если СУБД обслуживает несколько клиентов или внутренних команд, одна уязвимая база может стать точкой входа для соседних систем.

SQL-инъекции в pg_dump и pg_restore опасны в конвейерах резервного копирования и восстановления. Если дампы или архивы приходят из недоверенного источника, вредоносный объект в дампе может выполниться на стороне, которая восстанавливает базу. Поэтому обновлять нужно не только серверы, но и машины, где запускаются утилиты.

Условия эксплуатации

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

Для ошибок в pg_dump, pg_restore, vacuumdb и reindexdb нужен запуск утилиты или обработка подготовленного архива. Для части проблем с правами достаточно роли владельца объекта. Поэтому в аудит стоит включить не только суперпользователей, но и сервисные учётные записи приложений. Отдельная категория риска - расширения и недоверенные SQL-функции: они выполняются в процессе сервера, поэтому ошибка типа в них опаснее, чем в обычном запросе.

Затронутые версии

Уязвимы версии ниже 18.7, ниже 17.12, ниже 16.16, ниже 15.20 и ниже 14.25. Ветка 19 затронута до 19 RC 2. PostgreSQL 14 - последний выпуск: вендор прямо рекомендует планировать миграцию на поддерживаемую версию, потому что новых исправлений для 14 больше не будет.

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

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

Проверьте индексы. В релизе исправлены ошибки, которые могли повредить GIN-индексы и GiST-индексы pg_trgm. Если есть подозрение на повреждение, нужно выполнить REINDEX; для pg_trgm стоит перестроить GiST-индексы с классом операторов gist_trgm_ops. Для индексов B-tree на колонках bpchar без длины тоже рекомендован reindex.

Проверьте ограничения. На партиционированных таблицах могли остаться NOT NULL NO INHERIT, из-за которых в партиции попадали NULL. В релизе приведён запрос для поиска таких ограничений и описано, как их удалить или исправить.

Если используются инкрементальные бэкапы, после обновления стоит сделать новую полную копию и строить инкременты от неё: в релизе исправлены ошибки, которые могли приводить к повреждённым инкрементальным копиям. Для обычных base backup тоже есть исправления, поэтому старые копии лучше проверить.

Что делать

Обновить все узлы PostgreSQL до исправленных версий своей ветки, включая реплики и серверы, где запускаются утилиты. После обновления выполнить рекомендованные reindex и проверки ограничений, затем сделать свежие резервные копии. Для PostgreSQL 14 - запланировать миграцию на поддерживаемую ветку.

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