Выпуск обновлений PostgreSQL закрыл 52 уязвимости. Главная из них — CVE-2026-6460 с оценкой CVSS 8.8: ошибка типа type confusion позволяет пользователю базы, умеющему создавать объекты, выполнить код на сервере. Патчи вышли 12 ноября, исправлены все версии до 18.7, 17.12, 16.16, 15.20 и 14.25.
Как работает CVE-2026-6460
Проблема связана с составными типами (composite types) — типами, собранными из именованных полей, каждое со своим типом данных. Тип поля можно изменить, пока старые значения этого типа ещё хранятся в других частях сервера. После этого сервер может прочитать старое значение так, будто у него уже новый тип.
Исправление, описанное в release notes, добавляет проверки версий: сервер распознаёт значение, которое больше не соответствует своему типу.
Код, выполненный таким образом, получает права операционной системы пользователя, под которым работает PostgreSQL. Это важно: дыра не даёт выхода за пределы процесса СУБД автоматически, но при стандартной настройке процесс часто работает под отдельным пользователем ОС.
Эксплойт уже показали публично
Исследователь Mehmet Ince опубликовал технический разбор с рабочим эксплойтом, продемонстрированным на PostgreSQL 18.6. Метод такой: подготовить запрос, удерживающий значение, изменить тип одного из полей значения, затем выполнить запрос. В разборе есть SQL, который роняет незапатченный сервер, и второй шаг, утекающий адреса памяти. SQL финального шага, запускающего команду на сервере, автор не приводит.
Ince пишет, что смог «вызвать этот краш под ролью с минимальными привилегиями». Security advisory проекта описывает атакующего просто как того, кто может создавать объекты, не уточняя, какие именно привилегии для этого нужны. Red Hat в своей оценке CVE говорит, что нужен логин в базу с правом создавать или изменять объекты. Ни один из источников не отвечает, достаточно ли аккаунта с одними привилегиями по умолчанию, чтобы выйти за пределы краша и выполнить код.
Корень ошибки исследователь относит к 5 мая 2004 года, когда в PostgreSQL появилась возможность менять тип колонки. Техника выполнения кода опирается на более позднее изменение от 14 мая 2015 года.
Эксплойт Ince адаптировал и для управляемых сервисов PostgreSQL, а в августе приватно передал proof-of-concept их командам безопасности. Среди провайдеров, с которыми он работал, — AWS (Aurora и RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks и Ubicloud. Текущий статус патчей каждого сервиса в разборе не указан.
Проект благодарит за CVE-2026-6460 более десятка сообщивших, включая самого исследователя, и отмечает его ещё в пяти исправлениях этого же выпуска.
Что ещё закрыли
32 из 52 уязвимостей получили оценку 8.8 — максимальную в этом релизе. Судя по оценкам в индексе уязвимостей проекта, только одна дыра в сервере не требует ни логина, ни действий пользователя: CVE-2026-116322 позволяет неаутентифицированному клиенту вызвать перезапуск серверов PostgreSQL 18.
Часть исправлений касается клиентских утилит. Специально собранный архив может заставить pg_restore выполнить код от имени пользователя, запустившего утилиту. Скомпрометированный исходный сервер может добиться выполнения кода через restore-скрипт в tar-выводе pg_dump.
Проект не сообщал об атаках с использованием CVE-2026-6460. В записи CVE оценка CISA также указывает на отсутствие эксплуатации.
Порядок действий для администратора
Обновите сервер до 18.7, 17.12, 16.16, 15.20 или 14.25 — по вашей мажорной версии. Одновременно пересоберите или обновите все расширения на языке C. Расширения, собранные под старые выпуски, всё ещё загружаются, но «могут быть не защищены от уязвимостей, исправленных в этом релизе» — так сказано в уведомлении репозитория от сопровождающих RPM-пакетов проекта. Некоторым расширениям понадобятся и правки в исходном коде.
Пересобранные под новые выпуски расширения могут не загрузиться на старых серверах. Пакеты расширений в RPM-репозиториях проекта теперь требуют нового минорного выпуска.
Если PostgreSQL работает не под собственной service-единицей пакета, например под Patroni, перезапустите его сразу после обновления — об этом пишет сопровождающий RPM-пакетов в блоге о пакетировании.
Обновите клиентские утилиты — pg_dump, pg_restore, reindexdb и vacuumdb — на всех машинах, где они запускаются.
Не отключайте новые проверки настройкой composite_type_mismatch: проект предупреждает, что это несёт риски безопасности. Для серверов, которые пока нельзя обновить, ни advisory, ни release notes обходного пути не предлагают.
PostgreSQL 14 теперь end-of-life, и 14.25 — его последний выпуск. Более старые мажорные версии также подвержены проблеме, но обновлений не получили.
После обновления выполните шаги переиндексации из анонса релиза. Если вы используете инкрементальные резервные копии, снимите новую полную копию и стройте последующие инкрементальные уже от неё.
Как это связано с другими свежими патчами
Картина этой осени повторяется: крупные проекты закрывают десятки дыр разом, и часть из них позволяет выполнить код после входа в систему. Так, GitLab закрыл CVE-2026-97229 с CVSS 10.0 — RCE без аутентификации через регулярные выражения CI/CD, а Gitea исправила 27 уязвимостей, включая обход SSH-аутентификации. Для администратора баз данных вывод один: обновление PostgreSQL — не только про сам сервер, но и про расширения и клиентские утилиты на всех машинах.
Частые вопросы
Кого касается CVE-2026-6460?
Все версии PostgreSQL до 18.7, 17.12, 16.16, 15.20 и 14.25. Атака требует логина в базу с правом создавать или изменять объекты — по формулировке Red Hat. Публичный эксплойт уже есть, но сообщений об атаках проект не приводил.
Обязательно ли пересобирать расширения на C?
Да, это прямо указано в уведомлении сопровождающих RPM-пакетов: старые сборки загружаются, но могут быть не защищены от исправленных уязвимостей. Части расширений понадобятся правки в исходном коде.
Что будет, если обновить только сервер, а утилиты оставить старыми?
pg_restore и pg_dump тоже получили исправления: специально собранный архив заставляет pg_restore выполнить код, а скомпрометированный источник — добиться выполнения кода через restore-скрипт в tar-выводе pg_dump. Обновлять нужно на всех машинах, где эти утилиты запускаются.
Можно ли отключить проверки composite_type_mismatch?
Проект этого не рекомендует и прямо говорит о рисках безопасности. Настройка существует, но использовать её как обходной путь не стоит.
Есть ли обходной путь, если обновиться нельзя?
Ни advisory, ни release notes проекта обходного пути не предлагают. Единственное, что остаётся, — ограничить круг ролей с правом создавать и изменять объекты и ускорить обновление.
Что с PostgreSQL 14?
Ветка 14 объявлена end-of-life, 14.25 — её последний выпуск. Более старые мажорные версии тоже уязвимы, но обновлений для них не вышло, так что оставаться на них — значит копить незакрытые дыры.
Нужно ли что-то делать после обновления?
Да: выполнить шаги переиндексации из анонса релиза. Если используются инкрементальные бэкапы — снять новую полную копию и строить последующие инкрементальные от неё.
PostgreSQL под Patroni: перезапуск обязателен?
Сопровождающий RPM-пакетов пишет: если СУБД работает вне собственной service-единицы пакета, например под Patroni, перезапустить её нужно сразу после обновления.
Источник: thehackernews.com