Уязвимость PostGREShell в PostgreSQL за 12 лет превратила репликацию в RCE

Двенадцать лет. Именно столько CVE-2026-6471, получившая прозвище PostGREShell, находилась внутри подсистемы логического декодирования PostgreSQL, пока исследователи из Cyera Research не обнаружили и не сообщили о ней. Исправления охватывают пять мажорных версий (18.6, 17.11, 16.15, 15.19, 14.24) — это наглядно отражает масштаб потенциальной уязвимости парка развёрнутых экземпляров Postgres: фактически каждый production-сервер, использующий логическую репликацию начиная с релиза 9.4 в 2014 году.

Неприятность не в возрасте уязвимости, а в уровне привилегий. Это не баг суперпользователя. Учётная запись без прав суперпользователя, обладающая атрибутом REPLICATION — именно такую роль выдают агенту резервного копирования или CDC-пайплайну, — достаточна для выполнения кода от имени процесса Postgres на уровне операционной системы.

Что произошло

7 сентября 2026 года, как сообщило CyberSecurityNews, проект PostgreSQL выпустил исправления CVE-2026-6471 для всех поддерживаемых веток. Уязвимость, обнаруженная Cyera Research, находится в подсистеме логического декодирования и обусловлена недостаточными ограничениями на пути к библиотекам в рабочем процессе логической репликации. В уязвимых версиях PostgreSQL не выполнял надлежащей проверки пути к библиотеке, передаваемого в качестве имени выходного плагина при запросе от клиента репликации.

Практическое следствие: учётная запись с атрибутом REPLICATION (суперпользователь не требуется) может указать PostgreSQL на контролируемую злоумышленником разделяемую библиотеку, доступную из OS-аккаунта сервера. После этого PostgreSQL передаёт этот путь нативному загрузчику библиотек операционной системы — dlopen() в Linux и macOS, LoadLibrary() в Windows — и выполняет код с правами процесса сервера базы данных.

Исправление включено в PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24. Всё, что старше в этих ветках, уязвимо. Первопричина, по данным отчёта, восходит к релизу 9.4 от 2014 года, в котором логическое декодирование было введено как полноценная функция. Это примерно двенадцать лет production-кода, в котором аутентифицированная роль репликации могла теоретически получить доступ к оболочке системы.

Источник не раскрывает — а это важно — наблюдала ли Cyera или команда безопасности Postgres эксплуатацию уязвимости в реальных условиях до публичного раскрытия. Временной интервал эксплуатации пока неизвестен, однако верхняя граница риска ограничена датой выхода патча: любой организации, ведущей журналы попыток создания слотов репликации, следует ретроактивно проверить активность за последние 30–90 дней, чтобы установить нижнюю границу риска для своей среды.

Техническая анатомия

Чтобы понять, почему эта уязвимость существовала так долго, полезно проследить реальный путь выполнения кода. Логическое декодирование позволяет внешним инструментам читать изменения базы данных из журнала упреждающей записи (WAL) PostgreSQL. Вместо передачи сырых байт WAL физической реплике логическое декодирование пропускает WAL через выходной плагин — разделяемую библиотеку, которая форматирует каждое изменение в нужный потребителю формат: JSON для CDC в стиле Debezium, protobuf для собственного пайплайна, test_decoding для отладки, pgoutput для нативной логической репликации.

Когда клиент репликации запрашивает у Postgres создание слота логической репликации, он указывает имя выходного плагина. Сервер загружает этот плагин с помощью загрузчика библиотек ОС. В уязвимом коде имя плагина передавалось загрузчику без должного ограничения на ожидаемый каталог плагинов. Укажите путь, ведущий к контролируемому злоумышленником файлу .so или .dll, и сервер послушно загрузит его и выполнит конструктор.

Здесь особо важно инвертирование модели доверия. Исторически атрибут REPLICATION считался привилегией более низкого уровня, чем SUPERUSER: он позволяет потоково передавать WAL, но не выполнять произвольный SQL от имени владельца базы данных. Выдача роли REPLICATION сервису резервного копирования или Debezium-коннектору казалась безопасной именно потому, что предполагаемая поверхность атаки была узкой. CVE-2026-6471 устраняет это различие. Как только можно указать имя выходного плагина и сервер выполнит dlopen() для любого переданного пути, REPLICATION функционально эквивалентен выполнению кода от имени OS-пользователя postgres.

Злоумышленнику по-прежнему необходимы два условия. Первое — действительные учётные данные роли с REPLICATION. Второе — возможность разместить файл по пути, доступному на чтение процессу postgres. Именно здесь SMB- и NFS-монтирования становятся интересным вектором: разделяемая файловая система, доступный для записи временный каталог или скомпрометированный кэш пакетов — всё это может удовлетворить второе условие. Именно поэтому в раскрытии информации особо упоминается ограничение исходящего трафика SMB и NFS с хостов баз данных: удалённые UNC-пути в Windows и сетевые монтирования в Linux значительно расширяют поверхность эксплуатации.

Кто пострадает

В зоне риска все, кто использует Debezium, Kafka Connect JDBC sinks с логической репликацией, AWS DMS против самостоятельно управляемого Postgres, pglogical, источник Postgres для Airbyte, Fivetran или любой самописный CDC-пайплайн. А также каждый инструмент резервного копирования, использующий роль REPLICATION вместо pg_dump. Умножьте это на двенадцать лет выпускаемых версий — и поверхность воздействия окажется колоссальной.

Отраслевой срез имеет значение. Fintech- и iGaming-платформы, как правило, активно используют CDC в аналитические хранилища и пайплайны по борьбе с мошенничеством: именно в таких средах десятки микросервисов хранят учётные данные с атрибутом REPLICATION в разных хранилищах, config map и (к сожалению) переменных окружения. Ad-tech-компании и криптовалютные биржи нередко используют логическую репликацию для наполнения дашбордов в реальном времени. Команды корпоративной инфраструктуры сталкиваются с наихудшим сценарием: в мультитенантных Postgres-средах радиус поражения от одной скомпрометированной учётной записи репликации теперь включает доступ к оболочке хоста.

Управляемые сервисы усложняют ситуацию. RDS, Aurora, Cloud SQL и Azure Database for PostgreSQL — все они предоставляют пользовательским ролям доступ к логической репликации. Источник не уточняет, какие управляемые сервисы уже выпустили патчи, а это один из наиболее значимых неизвестных факторов на ближайшие две недели. Разумная оценка: провайдеры на ветках 16.x или 15.x обычно выпускают патчи безопасности в течение 7–21 дня после выхода upstream-релиза, поэтому рекомендуемся ожидать уведомлений от провайдеров до конца сентября.

Картина ближайших 90 дней для затронутых команд выглядит так. Первая неделя: экстренное применение патчей на самостоятельно управляемых экземплярах, аудит держателей ролей REPLICATION, ротация любых учётных данных, использовавшихся на непропатченных хостах. Вторая–четвёртая недели: поиск в журналах подозрительных попыток создания слотов. Второй и третий месяцы: архитектурный анализ того, кому на самом деле нужен REPLICATION, и проверка того, действительно ли pg_hba.conf выполняет свою работу или является формальностью с 0.0.0.0/0 в конце.

Руководство для инженерных команд

Сначала патч, потом обсуждения. Перейдите на 18.6, 17.11, 16.15, 15.19 или 14.24 в зависимости от вашей ветки. Если вы используете версию старше 14, эта уязвимость — одна из нескольких причин, по которым обновление следовало выполнить раньше.

Во-вторых, выполните запрос. Перечислите все роли с атрибутом REPLICATION (SELECT rolname FROM pg_roles WHERE rolreplication) и сверьте с теми, кому он действительно необходим. Инструментам резервного копирования, использующим pg_basebackup, он нужен. Пользователю для построения отчётов — нет. Снимите атрибут везде, где он не является обязательным.

В-третьих, ужесточьте pg_hba.conf. Соединения репликации должны быть ограничены конкретными исходными IP-адресами или CIDR-диапазонами, а не разрешаться для всего хоста. Если ваши клиенты репликации находятся в известной подсети, зафиксируйте это.

В-четвёртых, проведите расследование. Проверьте активность логической репликации на предмет попыток создания слотов с подозрительными именами плагинов: всё, что содержит пути к файловой системе, последовательности обхода каталогов или имена библиотек, не входящие в ваш известный набор (pgoutput, wal2json, test_decoding, что именно использует ваш стек). Настройте постоянное оповещение об этом в дальнейшем.

В-пятых, заблокируйте исходящий трафик SMB и NFS с хостов баз данных, если нет документально подтверждённой необходимости. Это закрывает вектор удалённой доставки библиотек даже для будущих вариаций уязвимости.

Мой проверяемый прогноз: если применение патчей затянется, как это обычно бывает с CVE для баз данных, первый публичный отчёт об эксплуатации на самостоятельно управляемом Postgres-сервере следует ожидать в течение 60 дней, и как минимум один разбор инцидента, упоминающий скомпрометированные учётные данные CDC как начальный вектор, появится к концу первого квартала 2027 года. Если этого не произойдёт, либо эксплуатация сложнее, чем предполагает описание, либо защитники сработали быстрее обычного. Оба исхода поучительны.

Ключевые выводы

• CVE-2026-6471 (PostGREShell) даёт учётным записям REPLICATION без прав суперпользователя путь к выполнению кода от имени процесса Postgres на уровне ОС, разрушая границу доверия, которая считалась безопасной с 2014 года.
• Исправленные версии: 18.6, 17.11, 16.15, 15.19 и 14.24. Всё более раннее в этих ветках уязвимо.
• Первопричина — недостаточная проверка пути к библиотеке при загрузке выходного плагина логического декодирования через dlopen() или LoadLibrary().
• Неизвестный фактор для отслеживания: предшествовала ли эксплуатация публичному раскрытию. Проверьте историю создания слотов за последние 30–90 дней, чтобы установить нижнюю границу риска для своей среды.
• Помимо применения патча: снимите REPLICATION с ролей, которым это не нужно, ограничьте соединения репликации в pg_hba.conf и заблокируйте исходящий SMB/NFS с хостов баз данных.