PostgreSQL выпустила экстренный патч для 11 CVE во всех версиях

Каждая давно работающая база данных немного похожа на старый рядный дом в Дублине. Парадные комнаты перекрашиваются каждый год, но проводка за плинтусами стоит ещё с семидесятых, и никто особо не хочет туда заглядывать. 14 мая сопровождающие PostgreSQL вскрыли полы в модуле contrib refint — и нашли кое-что неприятное.

Экстренный релиз охватывает сразу все поддерживаемые мажорные версии. Одно это говорит о масштабе находки.

Что произошло

14 мая 2026 года PostgreSQL выпустила экстренные обновления безопасности, закрыв уязвимости в версиях 18.4, 17.10, 16.14, 15.18 и 14.23. Как сообщает Cyber Press, скоординированный релиз устраняет 11 CVE, охватывающих переполнение стекового буфера, SQL-инъекции, утечку памяти и ошибки отказа в обслуживании — плюс более 60 дополнительных исправлений в нагрузку.

Главная уязвимость — CVE-2026-6637 с оценкой CVSS 8.8. Она находится в модуле contrib refint — старом компоненте, поставляемом вместе с Postgres и реализующем триггеры ссылочной целостности. Удалённый непривилегированный пользователь базы данных может передать специально сформированные данные, спровоцировать переполнение стекового буфера и выполнить произвольный код от имени пользователя ОС, запускающего сервер базы данных. Это худший вид ошибки в БД: она не останавливается на уровне базы — она выходит на хост.

Существует вторичный вектор той же CVE, позволяющий выполнить SQL-инъекцию, когда приложение использует управляемый пользователем столбец в качестве первичного ключа каскадного обновления refint. Таким образом, даже если refint защищён от переполнения, небрежная схема данных всё равно может предоставить атакующему произвольный SQL при обновлении первичного ключа.

Другие серьёзные уязвимости: CVE-2026-6473 — целочисленное переполнение в нескольких функциях сервера, приводящее к выделению слишком маленькой памяти и записи за её пределами; CVE-2026-6477 — ошибка типа gets() в функциях работы с большими объектами в libpq, позволяющая вредоносному суперпользователю сервера перезаписать стековую память в psql и pg_dump; CVE-2026-6475 — path traversal с переходом по символическим ссылкам в pg_basebackup и pg_rewind, позволяющий перезаписывать файлы вроде /var/lib/postgres/.bashrc. Все четыре затрагивают версии с 14 по 18.

Также присутствует CVE-2026-6478 — тайминг-атака на MD5, которая затрагивает только устаревшие инсталляции, по-прежнему использующие записи md5 в pg_hba.conf после обновления с PostgreSQL 13 или более ранней версии.

Техническая анатомия

Разберём суть подробнее, поскольку уязвимость в refint действительно интересна с инженерной точки зрения. Модуль refint появился ещё до реализации современных внешних ключей в Postgres. Это модуль contrib, существующий уже более двух десятилетий и используемый приложениями, в которых давно настроены триггеры для каскадной ссылочной целостности. Большинство команд забыли о его существовании. Атакующие — явно нет.

Переполнение стекового буфера в движке базы данных — это особый вид кошмара. Серверный процесс PostgreSQL работает от имени пользователя ОС postgres, которому, как правило, принадлежат директория с данными, конфигурационные файлы и WAL. Произвольное выполнение кода на этом уровне — это не просто компрометация базы данных. Это весь узел целиком. Оттуда можно прочитать все секреты конфигурации на диске, вмешаться в репликацию, добавить запись в authorized_keys и выбрать путь для дальнейшего продвижения.

CVE-2026-6477 — это инвертированная модель угрозы, и именно она должна заставить задуматься всех, кто эксплуатирует общую или мультитенантную инфраструктуру Postgres. Уязвимость позволяет вредоносному суперпользователю сервера перезаписать стековую память в клиентском инструменте. Любой, кто запускал pg_dump против базы данных, которую не разворачивал лично, понимает негласное допущение, заложенное в клиентские инструменты: предполагается, что сервер надёжен. Это допущение только что перестало работать. lo_read() вызывается как из psql, так и из pg_dump, а значит, ваше ночное задание резервного копирования теперь является реальной поверхностью атаки на хост резервного копирования.

CVE-2026-6475 следует той же схеме с другой стороны. Переход по символическим ссылкам во время запуска pg_basebackup в режиме plain или операций failover через pg_rewind позволяет суперпользователю источника перезаписывать файлы уровня ОС на реплике. Перехватив .bashrc учётной записи postgres на уровне ОС, атакующий получит контроль над репликой при следующем входе в систему.

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

Кого это затрагивает

Всех, кто эксплуатирует мультитенантную инфраструктуру Postgres — а на практике это большинство fintech-, iGaming- и ad-tech-платформ определённого масштаба. Если вы управляете managed-продуктом баз данных или используете логическую репликацию через границы доверия между бизнес-подразделениями, CVE-2026-6637 — это ваш пожар высшей категории. Непривилегированный пользователь в любой тенантской базе данных с настроенными триггерами refint теоретически может выбраться на уровень хоста.

Платёжные платформы, по-прежнему использующие устаревшие триггеры refint после миграции с Postgres 9.x или 10, уязвимы вдвойне: из-за переполнения буфера и из-за вектора SQL-инъекции через каскадный первичный ключ. Мне приходилось видеть немало платёжных реестров, где каскад завязан на идентификаторы, доступные из приложения. Именно этот паттерн и эксплуатирует данная уязвимость.

Операторам iGaming, использующим кросс-региональные реплики чтения через pg_basebackup, стоит внимательно изучить CVE-2026-6475. Failover во время регионального инцидента — худший момент, чтобы обнаружить, что учётная запись ОС вашей реплики была скомпрометирована шесть часов назад.

Тайминг-атака на MD5 имеет значение только при наличии записей md5 в pg_hba.conf. По умолчанию во всех поддерживаемых релизах используется scram-sha-256, который не затронут. Однако устаревшие fintech-инсталляции, обновлявшиеся постепенно с версии 13 и ниже, почти всегда сохраняют записи md5, поскольку никто не хотел принудительно сбрасывать пароли всех сервисных учётных записей. Этот технический долг только что получил собственный CVE.

Есть и проблема календаря. PostgreSQL 14 достигнет конца поддержки 12 ноября 2026 года. После этой даты исправлений безопасности больше не будет. У всех, кто ещё работает на версии 14, есть примерно шесть месяцев на планирование обновления до версии 16 или 17. Правильная установка: воспринимайте этот патч как последнее исправление безопасности для 14.x, которое вы когда-либо примените.

Руководство для инженерных команд

На этой неделе, в порядке приоритета:

Сначала патч, потом аудит. Выкатите 18.4, 17.10, 16.14, 15.18 или 14.23 на все кластеры. Замена бинарных файлов и перезапуск сервиса — дамп и перезагрузка не нужны. Для Debian/Ubuntu: sudo apt update && sudo apt install postgresql-18. Для RHEL/Fedora: sudo dnf update postgresql. Для Homebrew на машинах разработчиков: brew upgrade postgresql@18. Управляемые облачные базы данных будут обновлены в соответствии с окном обслуживания провайдера, но обычно можно инициировать обновление минорной версии вручную через консоль, не дожидаясь автоматического обновления.

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

Проведите аудит pg_hba.conf на всех хостах. Любую строку, использующую md5, необходимо перевести на scram-sha-256. Да, это означает смену паролей для затронутых ролей. Сделайте это в любом случае.

Проверьте инфраструктуру резервного копирования и failover с точки зрения клиентских рисков. Все, кто запускает pg_dump или pg_basebackup против баз данных из другой зоны доверия — включая отладочные сессии dev-против-prod — должны считать клиентский хост скомпрометированным до установки патча.

Если вы всё ещё на версии 14, прямо сейчас поставьте напоминание на 12 ноября и начните планирование обновления. Реалистичные цели — PostgreSQL 16 или 17. Воспринимайте этот патч как старт миграционного проекта, а не как закрытие квартального цикла.

Ключевые выводы

• Релиз PostgreSQL от 14 мая 2026 года закрывает 11 CVE во всех поддерживаемых мажорных версиях (с 14 по 18), плюс более 60 дополнительных исправлений.
• CVE-2026-6637 (CVSS 8.8) в модуле contrib refint обеспечивает удалённое выполнение кода от имени пользователя ОС и вторичный путь SQL-инъекции через каскадные первичные ключи.
• CVE-2026-6477 и CVE-2026-6475 инвертируют модель угрозы: вредоносный сервер может скомпрометировать клиентские инструменты и хосты реплик в ходе обычных операций pg_dump, pg_basebackup или pg_rewind.
• Применение патча — это замена бинарных файлов и перезапуск сервиса без дампа и перезагрузки, поэтому никаких оправданий для промедления сверх окна обслуживания нет.
• PostgreSQL 14 завершает поддержку 12 ноября 2026 года. Используйте этот патч-цикл как старт миграции на версию 16 или 17, а не просто как точечное исправление.

Возвращаясь к метафоре старого дома. Проводка на этой неделе была заменена, и инспектор дал добро. Но инспектор также напоминает, что аренда всего здания истекает в ноябре. Замените проводку — и начинайте собирать коробки.