PostgreSQL устраняет уязвимость выполнения кода через логическое декодирование — затронуты все версии с 14 по 18

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-конвейеры продолжают работать после обновления. Пропуск этого шага приведёт к отказу логического декодирования — проблема операционная, но предсказуемая и легко устранимая.