Как PostGREShell превращает репликацию PostgreSQL в запуск чужого кода?

Уязвимость CVE-2026-6471, названная исследователями Cyera Research PostGREShell, около 12 лет скрывалась в механизме логического декодирования PostgreSQL. Ошибка появилась вместе с ним в PostgreSQL 9.4 в 2014 году и получила оценку 7,2 балла CVSS. Она позволяет выполнить произвольный код внутри серверного процесса базы данных с правами пользователя операционной системы, от имени которого запущен PostgreSQL.
Для атаки нужны учётная запись с атрибутом REPLICATION и сервер с параметром wal_level = logical. Cyera называет такую учётную запись низкопривилегированной резервной учёткой, тогда как PostgreSQL оценивает требуемые привилегии как высокие; ту же оценку приводит SUSE. На практике REPLICATION часто получают средства резервного копирования, резервные серверы, конвейеры CDC и системы мониторинга. Компрометация одного такого аккаунта поэтому опаснее, чем могло казаться администраторам.
Ошибка находилась в обработке имени плагина команды CREATE_REPLICATION_SLOT. PostgreSQL передавал это имя прямо функции загрузки библиотеки, не применяя ограничения путей, предусмотренные для команды LOAD у пользователей без прав суперпользователя. Парсер репликации разрешал в заключённом в двойные кавычки имени почти любые символы: разделители каталогов, последовательности ../ и абсолютные пути. В результате выбранная злоумышленником библиотека загружалась непосредственно в процесс базы данных.
На Windows библиотеку можно было получить по контролируемому атакующим сетевому пути SMB, не записывая её заранее на диск целевого сервера. На Linux и macOS похожая удалённая загрузка возможна при автоматическом монтировании NFS. В остальных конфигурациях требовался иной способ поместить файл на сервер. Демонстрационный плагин Cyera напрямую изменял каталог ролей, назначал репликационной учётной записи права суперпользователя PostgreSQL и устанавливал три механизма закрепления, переживавшие перезапуск сервера.
Исправление вышло 13 августа в PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24. Все более ранние выпуски этих веток уязвимы. Бюллетень охватывает поддерживаемые ветки 14–18, но не старые версии; поддержка PostgreSQL 14 завершится 12 ноября 2026 года. Исправленные пакеты доступны для Amazon RDS во всех пяти ветках, а также для Debian, SUSE и Ubuntu.
Обновление добавило параметр output_plugin_libraries со списком библиотек, разрешённых в качестве плагинов логического декодирования. По умолчанию в нём указаны pgoutput, test_decoding. Автор исправления Jacob Champion пояснил, что пользователи репликации прежде обходили защиту времени загрузки из-за отсутствия ограничений на пути выходных плагинов. Разработчики не стали переносить существующее правило LOAD, поскольку тогда все сторонние плагины пришлось бы размещать только в $libdir/plugins. Запрещённая загрузка теперь оставляет в журнале ошибку «Библиотека "...» не может использоваться как выходной плагин» и подсказку о параметре output_plugin_libraries.
После обновления сторонние плагины, включая wal2json и decoderbufs, перестанут работать, пока администратор явно не внесёт их в разрешённый список. Перезапуск для изменения параметра не нужен: достаточно выполнить pg_ctl reload либо SQL-команду SELECT pg_reload_conf();. При миграции с PostgreSQL 17 или новее список следует настроить в новом кластере до запуска pg_upgrade --check, иначе проверка завершится ошибкой, если плагины старых слотов репликации не разрешены.
Debian отдельно предупредил о необходимости дополнительной настройки расширений и назвал wal2json и decoderbufs. Ubuntu выпустила бюллетень USN-8653-1 для Ubuntu 22.04, 24.04 и 26.04 LTS 20 августа, но не упомянула output_plugin_libraries и предложила администраторам лишь перезапустить PostgreSQL. К 4 сентября документация wal2json уже требовала добавить плагин в новый список, прямо ссылаясь на CVE.
Новая защита обнаружила и неудобство в pg_createsubscriber. Утилита создаёт слоты репликации с pgoutput, но заранее не проверяет, разрешён ли этот плагин. Поэтому запуск с --dry-run способен завершиться успешно, а реальное преобразование — упасть. Hayato Kuroda из Fujitsu сообщил об этом в рассылке pgsql-hackers; на 4 сентября патч ещё проходил проверку и не был принят.
PostgreSQL Project указал авторами сообщения об уязвимости Vladimir Tokarev и Yu Kunpeng, исследовательской организацией выступила Cyera Research. Технический разбор Токарева опубликован 1 сентября, заявление проекта содержится в примечаниях к выпуску PostgreSQL 18.6, а среди публичных источников фигурирует The Hacker News. На 4 сентября CVE-2026-6471 отсутствовала в каталоге CISA Known Exploited Vulnerabilities, а The Hacker News не нашла открытого доказательства концепции в публичных репозиториях. Это не доказывает ни невозможность атаки, ни отсутствие случаев эксплуатации.
До установки обновления стоит отозвать REPLICATION у ненужных учётных записей, ограничить правила репликации в pg_hba.conf известными адресами, заблокировать исходящий SMB по TCP-порту 445 и NFS по порту 2049, а также отключить autofs там, где он не требуется. После обновления необходимо перечислить все используемые сторонние плагины в output_plugin_libraries и перечитать конфигурацию: одной установки исправленного пакета для сохранения рабочих CDC- и репликационных цепочек может оказаться недостаточно.


Новое на сайте

Ссылка