Обычная служебная учётная запись для репликации PostgreSQL больше десяти лет могла превратиться в скрытый вход из базы данных прямо в операционную систему сервера. Уязвимость появилась ещё в PostgreSQL 9.4 в 2014 году и позволяла аккаунту с правом REPLICATION запускать произвольный нативный код.
Проблема получила идентификатор CVE-2026-6471 и оценку 7,2 балла по CVSS. Команда Cyera назвала технику PostGREShell. Для атаки злоумышленнику требовались учётные данные пользователя с атрибутом REPLICATION и включённое логическое декодирование. Такие аккаунты используют системы резервного копирования, резервные серверы, конвейеры CDC и другие инструменты, которым нужно читать журнал изменений PostgreSQL.
Корень проблемы находился в механизме загрузки плагинов логического декодирования. Клиент с правом REPLICATION может создать слот репликации и указать плагин, который преобразует записи WAL в поток изменений. PostgreSQL передавал указанное имя непосредственно системному загрузчику библиотеки, не применяя проверку пути, которая защищает обычную SQL-команду LOAD.
В результате вместо доверенного плагина можно было указать произвольную библиотеку, доступную системному пользователю PostgreSQL. На Linux и macOS сервер загружал файл через dlopen(), а Windows использовала LoadLibrary(). В Windows атака могла проходить полностью удалённо: UNC-путь позволял заставить сервер получить вредоносную DLL с внешнего SMB-ресурса. В некоторых конфигурациях Linux и macOS похожий сценарий возможен через NFS, а в остальных случаях атакующему сначала требовалось разместить библиотеку на сервере другим способом.
После загрузки библиотека работала внутри процесса PostgreSQL с правами системного пользователя, под которым запущена СУБД. Специалисты Cyera показали, что такой код способен обойти SQL-модель разграничения доступа, изменить системный каталог pg_authid и превратить исходную служебную учётную запись в суперпользователя. Дальше атакующий получает доступ ко всем базам, может читать доступные серверу файлы, запускать команды операционной системы и закрепляться в системе.
Cyera также обнаружила на VirusTotal 114 вредоносных плагинов PostgreSQL, включая майнеры, трояны и обратные оболочки. Находка не доказывает эксплуатацию именно CVE-2026-6471 в реальных атаках. Подтверждённых случаев применения PostGREShell против организаций на момент раскрытия исследователи не приводили.
Разработчики PostgreSQL закрыли уязвимость 13 августа в версиях 18.6, 17.11, 16.15, 15.19 и 14.24. В обновлении появился параметр output_plugin_libraries, который разрешает использовать только явно доверенные плагины логического декодирования. По умолчанию список содержит встроенные pgoutput и test_decoding, поэтому администраторам, которые используют wal2json, decoderbufs или другие сторонние плагины, после обновления нужно самостоятельно добавить доверенные библиотеки в конфигурацию.
Уязвимый путь существовал с появления логического декодирования в PostgreSQL 9.4. В подробном разборе PostGREShell команда Cyera рекомендует не ограничиваться обновлением: проверить все аккаунты с REPLICATION, убрать лишние права, ограничить разрешённые адреса в pg_hba.conf и закрыть исходящие соединения к SMB и NFS там, где они не нужны. Официальные исправления выпущены для поддерживаемых веток PostgreSQL 14–18, поэтому старые версии 9.4–13 требуют перехода на актуальную ветку.