CVE-2026-6471 у PostgreSQL: що змінює оновлення безпеки

PostgreSQL випустив оновлення безпеки, що усувають вразливість CVE-2026-6471 (CVSS 7.2) у механізмі логічного декодування. Дефект дає змогу обліковому запису бази даних з атрибутом REPLICATION завантажити довільну бібліотеку та виконати код від імені системного користувача, під яким працює сервер. Уразливість стосується всіх підтримуваних гілок — PostgreSQL 14, 15, 16, 17 і 18 до версій 14.24, 15.19, 16.15, 17.11 і 18.6 відповідно. Виправлення, випущене 13 серпня 2026 року, запроваджує новий параметр конфігурації, який може порушити роботу сторонніх плагінів після оновлення, якщо адміністратор не виконає додаткове налаштування.

Суть вразливості та вектор атаки

Згідно з офіційним бюлетенем PostgreSQL, проблему класифіковано як відсутність авторизації в ядрі сервера під час логічного декодування. Користувач із привілеєм REPLICATION міг указати довільну завантажувану бібліотеку як плагін виводу — без перевірок, які застосовуються до звичайних операцій завантаження бібліотек через команду LOAD.

Офіційний CVSS-вектор: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H — мережевий вектор атаки, низька складність експлуатації, але високі вимоги до привілеїв. Вплив оцінюється як високий за всіма трьома параметрами: конфіденційність, цілісність і доступність. Для експлуатації необхідно виконання двох умов: наявність облікового запису з атрибутом REPLICATION і серверна конфігурація з параметром wal_level = logical.

Атрибут REPLICATION нерідко призначають службовим обліковим записам: інструментам резервного копіювання, серверам-реплікам, конвеєрам захоплення змін даних (CDC) та системам моніторингу. Це розширює потенційну поверхню атаки, попри формально високий рівень необхідних привілеїв.

Механізм виправлення: параметр output_plugin_libraries

Як зазначено в примітках до випуску PostgreSQL 18.6, виправлення запроваджує серверний параметр output_plugin_libraries — білий список бібліотек, які дозволено завантажувати як плагіни виводу логічного декодування. Значення за замовчуванням — 'pgoutput, test_decoding'.

Це означає, що після оновлення будь-який сторонній плагін — зокрема широко використовувані wal2json і decoderbufs — буде відхилений сервером, доки адміністратор явно не додасть його до списку й не перезавантажить конфігурацію. У разі відхилення в журналі сервера з’являється повідомлення: ERROR: library "..." may not be used as an output plugin із посиланням на параметр output_plugin_libraries.

Автор виправлення Jacob Champion пояснив у коміті, що стандартні обмеження LOAD свідомо не застосовувалися до шляху реплікації: їхнє ретроактивне запровадження вимагало б установлення всіх сторонніх плагінів до каталогу $libdir/plugins, що зламало б наявні інсталяції.

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

Вразливість зачіпає будь-яку інсталяцію PostgreSQL версій 14–18, де одночасно виконуються дві умови: існує обліковий запис з атрибутом REPLICATION і сервер працює з wal_level = logical. Це типова конфігурація для:

• систем логічної реплікації між кластерами PostgreSQL
• конвеєрів CDC (Debezium, Kafka Connect та аналоги)
• інструментів резервного копіювання з логічним декодуванням
• платформ моніторингу, що використовують слоти реплікації

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

Практичні рекомендації

Порядок дій під час оновлення, згідно з документацією PostgreSQL:

1. Інвентаризація плагінів — до оновлення виконайте запит: SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; Запит покаже плагіни, які коли-небудь успішно використовувалися.
2. Оновлення до PostgreSQL 18.6, 17.11, 16.15, 15.19 або 14.24. Пакети доступні в основних дистриб’юторів: Amazon RDS (з 25 серпня), Ubuntu (22.04, 24.04, 26.04 LTS), Debian і SUSE.
3. Додавання сторонніх плагінів до output_plugin_libraries і перезавантаження конфігурації командою pg_ctl reload або SELECT pg_reload_conf(); — перезапуск сервера не потрібен.
4. Під час міграції з PostgreSQL 17 і новіших через pg_upgrade: установіть output_plugin_libraries на новому кластері до запуску pg_upgrade --check, інакше перевірка завершиться помилкою, якщо слоти старого кластера використовують плагіни, відсутні в списку.

Тимчасові заходи до оновлення

• Вилучити атрибут REPLICATION з облікових записів, яким він не потрібен
• Обмежити записи реплікації в pg_hba.conf лише відомими IP-адресами
• Заблокувати вихідний трафік із серверів баз даних на порти 445 (SMB) і 2049 (NFS)

Статус експлуатації та відкриті питання

На момент публікації статус активної експлуатації CVE-2026-6471 не підтверджено. Публічний код для відтворення атаки у відкритих репозиторіях не виявлено. Вразливість виявлена дослідниками Vladimir Tokarev та Yu Kunpeng, про що повідомляється в офіційному анонсі релізу.

Слід враховувати, що PostgreSQL 14 — остання зачеплена гілка — припинить отримувати оновлення безпеки 12 листопада 2026 року. Організаціям, які працюють на цій версії, варто планувати міграцію на новішу гілку.

Оновлення до виправлених версій PostgreSQL слід виконати в пріоритетному порядку, особливо на серверах з wal_level = logical. Вкрай важливо не обмежуватися встановленням патча: необхідно перевірити список використовуваних плагінів виводу, додати їх до output_plugin_libraries і переконатися, що логічна реплікація та CDC-конвеєри продовжують працювати після оновлення. Пропуск цього кроку призведе до відмови логічного декодування — проблема операційна, але передбачувана й легко усувна.