Wydania systemu PostgreSQL od 2014 roku zawierają poważną lukę w zabezpieczeniach, umożliwiającą atakującemu z niskimi uprawnieniami przejęcie kontroli nad bazami danych i serwerami – informuje Cyera, firma zajmująca się cyberbezpieczeństwem.

Autor: 5 min czytania

PostgreSQL – system bazodanowy typu open source, obsługujący zarówno zapytania relacyjne (SQL), jak i nierelacyjne (JSON) – jest jedną z najpopularniejszych baz danych, wykorzystywaną przez dziesiątki tysięcy firm, w tym duże przedsiębiorstwa.

Zidentyfikowana niedawno luka, oznaczona jako CVE-2026-6471 (z wynikiem 7,2 w skali CVSS) i określana mianem PostGREShell, może zostać wykorzystana do zdalnego wykonania kodu oraz eskalacji uprawnień.

Problem wynika z braku odpowiedniej autoryzacji w mechanizmie dekodowania logicznego bazy danych. Atakujący posiadający uprawnienia do replikacji (replication privileges) mogą wykorzystać go do wczytania dowolnego pliku dostępnego dla konta systemowego uruchamiającego serwer, korzystając z wtyczki dekodowania logicznego.

Jak wyjaśnia firma Cyera, PostgreSQL wykorzystuje dedykowany protokół replikacji do synchronizacji wielu kopii zapasowych (replik) głównej bazy danych na potrzeby backupu i odzyskiwania danych. Wymaga to posiadania konta z atrybutem replikacji; takie konto jest udostępniane wszelkim podłączonym narzędziom do tworzenia kopii zapasowych, serwerom, potokom danych oraz systemom monitorowania.

Zmiany są rejestrowane przez lokalny mechanizm replikacji jako zdarzenia dotyczące tabel, co umożliwia ich odczyt przez narzędzia zewnętrzne. Odbywa się to poprzez utworzenie slotu replikacji logicznej i wskazanie wtyczki wyjściowej, ładowanej przez PostgreSQL w celu sformatowania strumienia danych.

Po załadowaniu wtyczki PostgreSQL uruchamia jej funkcję inicjującą z uprawnieniami procesu serwera. Aby zapobiec nadużyciom, użytkownicy niebędący superużytkownikami mogą ładować wtyczki wyłącznie z katalogu kontrolowanego przez administratora.

Cyera odkryła, że nazwa wtyczki jest przekazywana bezpośrednio do modułu ładującego bez walidacji czy oczyszczania danych wejściowych. Pozwala to atakującemu na podanie pełnej ścieżki w systemie plików, która jest następnie przekazywana do funkcji `dlopen()` – funkcji języka C/C++ służącej do dynamicznego ładowania bibliotek współdzielonych.

„Parser protokołu replikacji akceptuje niemal każdy znak w nazwie wtyczki ujętej w cudzysłów: ukośniki, odwrotne ukośniki, kropki, sekwencje nawigacji po katalogach (np. `../`), a nawet ścieżki UNC systemu Windows” – zauważają badacze Cyera.

Umożliwia to atakującemu załadowanie i wykonanie dowolnego pliku za pośrednictwem funkcji `dlopen()`, przy czym plik ten jest uruchamiany z uprawnieniami użytkownika systemowego `postgres`. „Kod wczytany za pomocą funkcji dlopen() działa w tej samej przestrzeni adresowej co PostgreSQL, bez żadnego mechanizmu izolacji (sandbox) czy kontroli wywołań wewnętrznego API. Serwer po prostu ufa każdemu wczytanemu kodowi” – wyjaśnia Cyera.

„Wtyczka wywołuje więc funkcję wewnętrzną, aby uzyskać uprawnienia superużytkownika typu »bootstrap« dla danej sesji, a następnie zapisuje dane bezpośrednio w tabeli katalogowej pg_authid (określającej, kto jest superużytkownikiem) i ustawia wszystkie flagi uprawnień na wartość »true«” – tłumaczą specjaliści.

Na tym etapie atakujący uzyskuje stałe uprawnienia superużytkownika: może uzyskać dostęp do każdej tabeli w każdej bazie danych, wykonywać polecenia systemu operacyjnego, odczytywać klucze prywatne oraz zapisywać pliki w dowolnej lokalizacji dostępnej dla procesu postgres.

Według Cyera wtyczka może również instalować mechanizmy typu backdoor: umożliwia nawiązywanie połączeń bez hasła, kopiuje się do trwałej lokalizacji i rejestruje tak, aby być automatycznie wczytywana przy każdym nowym procesie obsługi klienta (backendzie). Ponadto potrafi ponownie nadać uprawnienia superużytkownika, nawet jeśli zostały one cofnięte.

„PostGREShell przekształca pozornie niegroźne poświadczenia służące do replikacji w narzędzie umożliwiające wykonanie kodu, uzyskanie uprawnień superużytkownika oraz utworzenie trwałego backdooru w bazie danych obsługującej znaczną część Internetu. Problem dotyczy wszystkich wersji od 9.4 do 18 (potwierdziliśmy to w wersji 18.2), a ponieważ replikacja logiczna jest obecnie standardowym elementem infrastruktury produkcyjnej, podatność ta występuje niemal wszędzie tam, gdzie działa PostgreSQL” – zauważa Cyera.

Luka CVE-2026-6471 została usunięta w wersjach PostgreSQL: 18.6, 17.11, 16.15, 15.19 oraz 14.24. Organizacjom zaleca się jak najszybszą aktualizację instancji, przeprowadzenie audytu kont wykorzystywanych do replikacji oraz usunięcie atrybutu replikacji z kont, które go nie wymagają.