PostgreSQL security release 18.2/17.8/16.12/15.16/14.21: як оновитися безпечно і швидко оцінити ризик

Коротко: вийшов security release PostgreSQL для всіх підтримуваних гілок (14–18) з кількома високими CVSS, включно зі сценаріями, які можуть призвести до RCE. Хороша новина: це minor upgrade — зазвичай достатньо оновити пакети/образ і перезапустити сервіс. Погана: відкладати без оцінки експозиції — ризиковано.

Офіційний анонс: https://www.postgresql.org/about/news/postgresql-182-178-1612-1516-and-1421-released-3235/

Які версії вважати «безпечними»

Якщо ти на підтримуваних major-версіях, цільові мінорні версії такі:

• PostgreSQL 18 → 18.2
• PostgreSQL 17 → 17.8
• PostgreSQL 16 → 16.12
• PostgreSQL 15 → 15.16
• PostgreSQL 14 → 14.21

Якщо ти нижче — план простий: оновитися до відповідного патч-релізу своєї гілки якнайшвидше.

«Чи нас це стосується?» — швидка оцінка за 15 хв

1) Підтвердь точну версію

У psql:

SHOW server_version;
SELECT version();

Важливо знати саме minor, бо security релізи закривають проблеми на рівні патч-версій.

2) Інвентаризуй увімкнені розширення

Вразливості в цьому релізі зачіпають і ядро, і модулі з пакета contrib (зокрема pgcrypto та intarray; для v18 згадується також pg_trgm).

Перевір, що реально увімкнено в базах:

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Якщо бачиш pgcrypto / intarray / pg_trgm — пріоритет оновлення стає ще вищим.

3) Оціни модель доступу: хто може виконувати SQL

Багато критичних CVE мають нюанс: для експлуатації часто потрібна можливість виконувати атакувальний запит. Тому ключове питання не тільки «чи база публічна», а чи є в тебе “неповністю довірені” користувачі/запити.

Зони підвищеного ризику:

• multi-tenant (різні клієнти в одній БД/кластері);
• аналітика/BI, де користувачі можуть писати довільні запити;
• будь-який сервіс, де можливі SQL-injection або “динамічний SQL” без жорсткої валідації;
• shared staging, де «багато людей мають psql, бо так зручно».

Навіть якщо зовнішнього доступу немає, внутрішній доступ до SQL у поєднанні з вразливістю рівня 8.8 по CVSS — це серйозно.

Практичний план оновлення (без зайвих рухів)

Крок 0: зменш ризик перед змінами

• Заплануй коротке вікно простою: minor upgrade зазвичай = рестарт.
• Переконайся, що є актуальний бекап (і ти вмієш його відновити).
• Для критичних систем — спочатку відпрацюй сценарій на staging.

Варіант A: один інстанс (без реплік)

1. Онови пакети PostgreSQL до потрібного мінору (і не забудь про contrib, якщо він у твоєму дистрибутиві окремим пакетом).
2. Перезапусти PostgreSQL.
3. Проганяй «smoke checks» (нижче).

Це не major-апгрейд: pg_upgrade і “дамп/рестор на весь кластер” зазвичай не потрібні. Але бекап — обов’язковий.

Варіант B: primary + replicas (streaming replication)

Мета — мінімізувати простій і ризик:

1. Онови replica(и) першими (по одній): зупинка → оновлення → старт.
2. Переконайся, що реплікація наздоганяє і немає помилок у логах.
3. Онови primary в узгоджене вікно.

Якщо у тебе автоматичний фейловер (Patroni/репліка-менеджери) — слідуй їхній рекомендованій процедурі rolling update.

Варіант C: Docker / Kubernetes

• Онови образ до версії з потрібним мінором (14.21/15.16/16.12/17.8/18.2).
• Перезапусти pod/statefulset з тим самим data volume.
• Переконайся, що схема міграцій/апп-старти не залежать від старих поведінок.

Тут типова помилка — оновити тільки образ, але не продумати порядок рестарту в кластері.

Мінімальний чеклист перевірки після патчу

1. Сервіс реально стартував і приймає з’єднання:

pg_isready

2. Версія оновилась:

SHOW server_version;

3. Критичні розширення на місці:

SELECT extname, extversion FROM pg_extension ORDER BY extname;

4. Ключові запити/ендпоінти застосунку проходять (логін, записи/читання, основні звіти).

5. Якщо є реплікація — статус ок (затримка не росте, WAL-стрімінг живий).

6. Метрики/логи без нових crash/segfault/OOM.

Defense-in-depth: що зробити, якщо оновлення не сьогодні

Якщо реально не можеш пропатчити негайно, зменшуй поверхню атаки — особливо там, де вразливість може бути досяжною через SQL.

1. Переглянь role-модель: хто має “зайві” права, і чи є обліковки, яким не місце в проді.
2. Забери можливість довільним ролям створювати обʼєкти в публічних схемах (часта база для ланцюжків атак). Мінімум:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

3. Обмеж CREATE EXTENSION: це має робити тільки DBA-роль або superuser.
4. Якщо pgcrypto / intarray / pg_trgm не потрібні — не вмикай їх «про запас».
5. Відокрем аналітиків/звітність від OLTP: окремий read-only кластер або хоча б жорсткі ролі без небезпечних прав.
6. Перевір, чи немає “загальних” логінів, які знає півкоманди.
7. Тимчасово підсиль аудит доступу (логування підключень/помилок) і моніторинг незвичних запитів.

Це не замінює патч, але купує час і зменшує шанс, що один «поганий запит» перетвориться на інцидент.

Висновок

Цей реліз — класичний випадок, де правильна реакція проста: швидко оцінити експозицію (версія + розширення + хто виконує SQL) і зробити контрольований minor upgrade до безпечного мінору. Якщо в системі є не повністю довірені запити або ти використовуєш pgcrypto/intarray/pg_trgm, відкладати патч — погана ставка.