В PostgreSQL закрыли ошибку 22-летней давности, через которую можно запустить код на сервере

Разработчики PostgreSQL 12 ноября выпустили обновления 18.7, 17.12, 16.16, 15.20 и 14.25. По данным проекта, они закрывают 52 уязвимости и больше 140 обычных ошибок. Самая обсуждаемая из уязвимостей - CVE-2026-6460 с оценкой 8,8 из 10: пользователь базы, которому разрешено создавать объекты, может запустить на сервере свой код с правами системного пользователя, под которым работает PostgreSQL. Такую же оценку проект дал ещё 31 уязвимости из этого выпуска. Атак через CVE-2026-6460 пока не замечено.

Почему ошибке 22 года

Дыра связана с составными типами, то есть типами из нескольких именованных полей. Тип поля можно поменять, пока старые значения ещё лежат в других частях сервера, и тогда сервер читает старое значение так, будто у него уже новый тип. В описании уязвимости проект признаёт, что система плохо отслеживала типы значений. Исследователь Мехмет Индже, который показал рабочий эксплойт на версии 18.6, ведёт начало проблемы от 5 мая 2004 года, когда в PostgreSQL появилась возможность менять тип столбца, пишет The Hacker News.

По словам Индже, уронить непропатченный сервер ему удалось с самой слабой учётной записью. Можно ли с такими правами дойти до запуска кода, ни один из источников не уточняет. Свой эксплойт он ещё в августе адаптировал под облачные базы и передал службам безопасности AWS, Microsoft Azure, Google, Supabase, Databricks и Ubicloud. Закрыли ли дыру у каждого из них, не сообщается.

Кого это касается

В первую очередь тех, кто пускает в одну базу чужих людей: хостинги, облачные сервисы и любые проекты, где клиент получает собственную учётную запись в PostgreSQL. Если в вашей базе работает только ваше приложение, внешнему атакующему сначала придётся получить в ней права. Отдельно исправлены клиентские утилиты: специально подготовленный архив может заставить pg_restore выполнить код на машине того, кто восстанавливает базу. Только одна уязвимость из 52 срабатывает без входа: она позволяет перезапустить сервер PostgreSQL 18.

Это уже не первое за неделю серверное обновление, которое стоит поставить без промедления: на днях мы писали о дыре в Apache с HTTP/2.

Что сделать

• Обновите сервер до 18.7, 17.12, 16.16, 15.20 или 14.25 в своей основной ветке. Выгружать и заново загружать базу не нужно.
• Пересоберите или обновите все расширения на C одновременно с сервером. Старые сборки загрузятся, но, по словам сопровождающих RPM-пакетов, могут остаться без защиты.
• Обновите pg_dump, pg_restore, reindexdb и vacuumdb на всех машинах, где ими пользуются.
• Если PostgreSQL запущен не через службу пакета, например под Patroni, перезапустите его сразу после обновления.
• Не отключайте новые проверки настройкой composite_type_mismatch: проект предупреждает, что это небезопасно.
• Выполните шаги из раздела «Updating» в объявлении о выпуске: перестроить затронутые индексы (GIN, GiST с pg_trgm, B-tree на столбцах bpchar), а при инкрементных бэкапах сделать новый полный.
• Если у вас 14-я или более ранняя версия, планируйте переход: после 14.25 исправлений для неё не будет.