PostGREShell: помилка в PostgreSQL перетворила резервні облікові записи на бекдори

**Помилка, що існувала з 2014 року в реплікації PostgreSQL, могла перетворити звичайний резервний обліковий запис на виконання коду, доступ суперкористувача та постійну бекдору. Проблема вже була виправлена в уражених гілках, але широта її використання зобов'язує перевірити облікові дані, налаштування та мережеві з'єднання.

• Вразливість CVE-2026-6471 впливає на версії до PostgreSQL 18.5, 17.11, 16.15, 15.19 та 14.24, відповідно до доступних повідомлень про безпеку.
• Обліковий запис з атрибутом REPLICATION міг завантажити шкідливу бібліотеку та виконати код у процесі бази даних.
• Cyera Research виявила 114 шкідливих доповнень PostgreSQL в обігу, хоча не пов'язала їх з експлуатацією цієї вразливості.

Вразливість, яка залишалася протягом більше десяти років у PostgreSQL, могла перетворити звичайний резервний обліковий запис на шлях для контролю бази даних і сервера. Помилка, ідентифікована як CVE-2026-6471 і названа PostGREShell дослідженням Cyera, впливає на функціональність логічної реплікації та дозволяє завантажувати довільний код з обліковим записом, що має атрибут REPLICATION, без вимоги привілеїв суперкористувача.

Потенційний обсяг є широким, оскільки PostgreSQL підтримує системи резервного копіювання, репліки, міграції, захоплення змінених даних та аналіз в реальному часі для тисяч організацій. Дослідження вказало, що понад 39 000 перевірених компаній використовують базу даних у виробництві, серед яких Netflix, Instagram, Spotify та Uber, а також сервіси, такі як AWS RDS, Azure Database, Google Cloud SQL, Supabase та Neon.

Схована помилка в реплікації

У виробничій установці основна база даних зазвичай працює разом з однією або кількома репліками, які підтримують синхронізовані копії. Ця архітектура дозволяє підтримувати резервні копії, відновлення після катастроф та масштабування читання, тому облікові записи реплікації зазвичай вважаються компонентами з низьким ризиком, хоча вони підтримують пряме з'єднання з чутливими функціями сервера.

PostgreSQL використовує специфічний протокол для синхронізації цих систем і вимагає атрибут REPLICATION для запуску реплікації в потоковому режимі. Ті ж облікові дані з'являються в інструментах резервного копіювання, серверах очікування, каналах захоплення змін та системах моніторингу, які читають журнал запису, так що обліковий запис, що здається обмеженим, може бути присутнім у численних критичних середовищах.

Проблема полягала в доповненнях виходу, які формують зміни логічної реплікації. Коли клієнт створює простір реплікації, він також вказує ім'я доповнення, яке може бути бібліотекою, скомпільованою з розширеннями, такими як .so, .dll або .dylib, і яку PostgreSQL завантажує в основний процес бази даних.

Система вже мала захист під назвою check_restricted_library_name(), призначений для запобігання завантаженню бібліотек з абсолютних шляхів або за допомогою технік обходу директорій не суперкористувачами. Однак шлях, що використовувався реплікацією, не викликав цю перевірку, тому ім'я доповнення потрапляло безпосередньо до завантажувача операційної системи без валідації, що застосовується до SQL-команди LOAD.

Від шкідливої бібліотеки до контролю сервера

Парсер протоколу реплікації приймав численні символи в імені доповнення, включаючи слеші, крапки, послідовності, такі як ../, та UNC-шляхи Windows. Зловмисник, який зміг передати спеціально маніпульоване ім'я, міг змусити PostgreSQL запитати бібліотеку, розташовану в довільному шляху, активуючи функції, такі як dlopen() в Linux та macOS або LoadLibrary() в Windows.

Завантаження бібліотеки негайно виконує свою функцію ініціалізації в процесі PostgreSQL. Оскільки плагін працює в тому ж адресному просторі і немає ізоляції коду C, звичайні захисти моделі дозволів SQL перестають бути достатніми, як тільки шкідлива бібліотека починає виконуватися.

Умови експлуатації змінюються залежно від операційної системи. У Windows обліковий запис з REPLICATION, сервер, налаштований з wal_level = logical, та доступ до мережі до порту SMB 445 могли бути достатніми для того, щоб PostgreSQL завантажив DLL, розміщену на віддаленому сервері через UNC-шлях, без необхідності копіювати файл на цільовий комп'ютер.

У Linux та macOS дослідження описало сценарії, засновані на автоматичних монтуваннях NFS, особливо коли був активний autofs, а також випадки, коли зловмисник вже міг записати бібліотеку на диск. У стандартних середовищах, контейнерах Docker або кластерах Kubernetes експлуатація вимагала цього додаткового каналу для локального розміщення шкідливого файлу, тоді як Windows пропонував повністю віддалений шлях за зазначених умов.

Підвищення прав суперкористувача та стійкість

Початковий доступ як користувача системи postgres не був кінцем атаки, згідно з опублікованим аналізом. Завантажений код міг маніпулювати внутрішніми структурами PostgreSQL, ставати суперкористувачем сеансу та безпосередньо змінювати pg_authid, каталог, що визначає привілеї ролей.

Працюючи поза SQL-виконавцем, ця зміна не проходила звичайні перевірки списків контролю доступу та правил дозволів. Зловмисник міг активувати індикатори суперкористувача та додати механізм, щоб подальші перевірки повертали позитивну відповідь, тоді як зміна реєструвалася подібно до звичайної зміни каталогу.

З привілеями суперкористувача зловмисник міг читати таблиці всіх баз даних, включаючи дані клієнтів, фінансові записи, секрети додатків та збережені облікові дані. Він також міг використовувати функції, такі як COPY ... TO PROGRAM, для виконання команд, читати чутливі файли за допомогою pg_read_file() або записувати в доступні для користувача системи місця за допомогою інструментів, таких як lo_export().

Дослідження також описало кілька механізмів стійкості, які могли пережити перезавантаження та ускладнити очищення. Серед них були зміни в pg_hba.conf, щоб дозволити підключення без пароля, копії плагіна в стабільному шляху та його реєстрація в shared_preload_libraries, разом із повторним застосуванням привілею суперкористувача, якщо адміністратор намагався його скасувати.

Виправлення, обсяг та термінові заходи

Команда безпеки PostgreSQL отримала звіт у лютому 2026 року та підтвердила вразливість 27 лютого, перш ніж координувати виправлення для незначного оновлення. CSO Online повідомила, що патчі були опубліковані 13 серпня для версій 18.6, 17.11, 16.15, 15.19 та 14.24. Повідомлення про безпеку ідентифікують як уражені версії, що передують цим випускам, тоді як збій походить з гілок, які почалися з PostgreSQL 9.4, випущеного в 2014 році.

Хоча CVE-2026-6471 отримала оцінку CVSS 7,2, описаний вплив поєднує виконання коду, підвищення привілеїв, доступ до інформації та стійкість. Практична серйозність залежить від експозиції облікових записів реплікації, налаштувань мережі та платформи, але наявність цих облікових даних в основних операціях робить недостатнім покладатися лише на те, що це не облікові записи адміністратора.

Огляд загроз Cyera Research у VirusTotal виявив 114 шкідливих плагінів PostgreSQL, включаючи трояни, майнери криптовалют та зворотні оболонки. Компанія не пов'язала ці файли з експлуатацією CVE-2026-6471, тому виявлення демонструє, що плагіни вже приваблюють шкідливу активність, але не підтверджує, що ця вразливість була використана цими зразками.

Адміністратори повинні спочатку встановити відповідне оновлення та провести аудит усіх облікових записів з атрибутом REPLICATION. Також доцільно видалити цей привілей, коли він не є строго необхідним, обмежити з'єднання в pg_hba.conf до відомих адрес і уникати правил реплікації, відкритих для всього Інтернету, таких як 0.0.0.0/0.

Ускладнення повинно включати блокування непотрібних вихідних з'єднань до SMB на порту 445 та NFS на порту 2049 з серверів бази даних, а також деактивацію autofs, коли це не потрібно. Команди безпеки повинні шукати команди CREATE_REPLICATION_SLOT з несподіваних адрес, імена плагінів з косими рисками або послідовностями шляху та незвичайні простори реплікації.

Цей випадок також виявляє повторювану проблему в розширюваних системах: шлях завантаження плагінів може бути відокремлений від моделі безпеки, яка захищає основні операції. PostgreSQL захистив один шлях завантаження, але шлях реплікації не з'єднав цю оборону з тим самим контролем, залишаючи протягом років вторинний вхід, який міг перетворити рутинну інфраструктуру на повну компрометацію.

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.