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

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

Екстрений реліз охоплює всі підтримувані мажорні версії одночасно. Вже одне це говорить вам про масштаб знахідки.

Що сталося

PostgreSQL випустив екстрені оновлення безпеки 14 травня 2026 року, закривши версії 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 і забезпечує тригери референційної цілісності. Віддалений непривілейований користувач бази даних може подати спеціально сформовані дані, щоб викликати стекове переповнення буфера та виконати довільний код від імені OS-користувача, під яким працює сервер бази даних. Це найгірший вид помилки в БД: вона не зупиняється на рівні бази, а виходить на рівень хоста.

У тій самій CVE є вторинний вектор, який уможливлює SQL-ін'єкцію, коли застосунок підставляє керований користувачем стовпець як первинний ключ каскаду refint. Тож навіть якщо refint захищений від переповнення, необережне проектування схеми може надати зловмиснику довільний SQL під час оновлення первинних ключів.

Інші серйозні вразливості: CVE-2026-6473 — цілочисельне переповнення в кількох компонентах сервера, що призводить до занадто малих виділень пам'яті та записів за межами буфера; CVE-2026-6477 — помилка у стилі gets() у функціях роботи з великими об'єктами в libpq, яка дозволяє зловмисному суперкористувачу сервера перезаписати пам'ять стека в psql і pg_dump; CVE-2026-6475 — обхід шляху через символічні посилання в 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 працює під OS-користувачем postgres, який зазвичай є власником директорії даних, конфігураційних файлів та WAL. Довільне виконання коду на цьому рівні — це не просто компрометація бази даних. Це весь вузол. Звідти можна читати всі секрети конфігурацій на диску, втручатися в реплікацію, писати до authorized_keys і прокладати шлях далі.

CVE-2026-6477 — це інверсна модель загрози, і саме вона має змусити схопитися всіх, хто керує спільною або мультитенантною Postgres-інфраструктурою. Вразливість дозволяє зловмисному суперкористувачу сервера перезаписати стекову пам'ять у клієнтському інструменті. Кожен, хто запускав pg_dump проти бази, яку він не налаштовував особисто, знає про припущення довіри, вбудоване в клієнтські утиліти: ви вважаєте сервер безпечним. Це припущення щойно зламалося. lo_read() викликається і в psql, і в pg_dump — а значить, ваше нічне завдання резервного копіювання тепер є потенційною точкою атаки на хост резервних копій.

CVE-2026-6475 слідує тій самій логіці під іншим кутом. Обхід через символічні посилання під час запусків pg_basebackup у простому форматі або операцій переключення pg_rewind дозволяє суперкористувачу джерела перезаписати файли на рівні OS на репліці. Захопіть .bashrc облікового запису postgres на OS — і ви отримаєте контроль над реплікою наступного разу, коли хтось зайде туди через шел.

Хороша новина, згідно з рекомендаціями PostgreSQL: дамп бази, перезавантаження або pg_upgrade не потрібні. Достатньо замінити бінарники та перезапустити сервіс. Нудна частина — без катастроф.

Хто під загрозою

Усі, хто керує мультитенантною Postgres-інфраструктурою — а на практиці це більшість фінтех-, iGaming- та ad-tech-платформ певного масштабу. Якщо ви керуєте продуктом managed-бази даних або запускаєте логічну реплікацію через межі довіри між бізнес-підрозділами, CVE-2026-6637 — це ваша найвища тривога. Непривілейований користувач будь-якого тенантного рівня з налаштованими тригерами refint може теоретично вийти на рівень хоста.

Платіжні платформи, що досі покладаються на застарілі тригери refint з міграції з Postgres 9.x або 10, вразливі одразу з двох сторін: через переповнення та через вектор SQL-ін'єкції каскадного первинного ключа. Я бачив чимало платіжних леджерів, де каскад прив'язаний до ідентифікаторів на рівні застосунку. Саме такий патерн і експлуатує цей баг.

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

Часовий канал MD5 важливий лише тоді, коли у вас досі є записи md5 у pg_hba.conf. Типовим значенням у всіх підтримуваних релізах є scram-sha-256, якого це не торкається. Але застарілі фінтех-інсталяції, що поетапно оновлювалися з версії 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. Managed-бази в хмарі оновлюватимуться у вікно обслуговування провайдера, але зазвичай можна вручну ініціювати оновлення мінорної версії через консоль, не чекаючи.

Після патчування перевірте схеми за допомогою grep на наявність тригерів 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 уможливлює віддалене виконання коду від імені OS-користувача та вторинний шлях SQL-ін'єкції через каскадні первинні ключі.
• CVE-2026-6477 та CVE-2026-6475 інвертують модель загрози: зловмисний сервер може скомпрометувати клієнтські утиліти та хости реплік під час звичайних операцій pg_dump, pg_basebackup або pg_rewind.
• Патчування — це заміна бінарників і перезапуск сервісу, без дампу та перезавантаження, тому немає жодного виправдання відкладати це за межі вікна обслуговування.
• PostgreSQL 14 досягає кінця підтримки 12 листопада 2026 року. Використайте цей цикл патчування як старт міграції на версію 16 або 17, а не просто як термінове виправлення.

Повертаючись до метафори старого будинку. Проводку цього тижня замінили, інспектор підписав акт. Але він також нагадує, що оренда всього будинку закінчується в листопаді. Полагодьте проводку — і починайте пакувати речі.