Вразливість PostgreSQL PostGREShell: 12 років у коді, реплікація перетворюється на RCE

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

Найбільш незручним є не вік вразливості, а рівень привілеїв. Це не помилка суперкористувача. Облікового запису без прав суперкористувача, але з атрибутом REPLICATION — саме такого типу ролі надають агентам резервного копіювання або CDC-пайплайнам — достатньо для виконання коду від імені OS-процесу 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 року, яка вперше запровадила логічне декодування як повноцінну функцію. Це приблизно дванадцять років реального коду, де автентифікована роль реплікації могла, теоретично, отримати доступ до командного рядка.

Те, чого джерело не розкриває — а це суттєво — це чи спостерігали Cyera або команда безпеки Postgres активне використання вразливості до публічного розголошення. Часова шкала експлуатації наразі невідома, але верхня межа ризику від виявлення до розголошення обмежена датою патча: будь-яка організація, що веде журнали спроб створення слотів реплікації, повинна ретроактивно перевірити активність за останні 30–90 днів, щоб встановити нижню межу для свого середовища.

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

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

Коли клієнт реплікації просить Postgres створити слот логічної реплікації, він вказує ім'я вихідного плагіна. Сервер потім завантажує цей плагін за допомогою OS-завантажувача бібліотек. У вразливому коді ім'я плагіна передавалося завантажувачу без належного обмеження до очікуваного каталогу плагінів. Якщо вказати шлях, що веде до контрольованого зловмисником файлу .so або .dll, сервер послухняно завантажить його та виконає конструктор.

Цікавою особливістю тут є інверсія моделі довіри. Історично атрибут REPLICATION вважався привілеєм нижчого рівня, ніж SUPERUSER: він дозволяє передавати WAL, але не дозволяє виконувати довільний SQL від імені власника бази даних. Надання ролі REPLICATION сервісу резервного копіювання або конектору Debezium здавалося безпечним саме тому, що поверхня атаки мала бути вузькою. CVE-2026-6471 руйнує це розмежування. Щойно ви можете вказати вихідний плагін, а сервер виконає dlopen() за будь-яким наданим шляхом, REPLICATION функціонально еквівалентний виконанню коду від імені OS-користувача postgres.

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

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

У зоні ризику перебувають усі, хто використовує Debezium, Kafka Connect JDBC sinks з логічною реплікацією, AWS DMS проти самостійно керованого Postgres, pglogical, Postgres source у 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 дня після виходу апстрім-версії, тому очікуйте рекомендацій від провайдерів до кінця вересня.

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 без прав суперкористувача шлях до виконання коду від імені OS-процесу Postgres, руйнуючи межу довіри, яка вважалася безпечною з 2014 року.
• Виправлені версії: 18.6, 17.11, 16.15, 15.19 та 14.24. Усе, що передує цим номерам у відповідних гілках, є вразливим.
• Першопричина — недостатня перевірка шляху до бібліотеки під час завантаження вихідного плагіна логічним декодуванням через dlopen() або LoadLibrary().
• Невизначеність, за якою слід стежити: чи передувала експлуатація публічному розголошенню. Перевірте історію створення слотів за останні 30–90 днів, щоб встановити власну нижню межу.
• Окрім патчування, приберіть REPLICATION у ролей, яким він не потрібен, обмежте з'єднання реплікації у pg_hba.conf та заблокуйте вихідні SMB/NFS від хостів баз даних.