PostgreSQL CVE-2026-6460: użytkownicy bazy danych, którzy mogą tworzyć obiekty, mogą uruchamiać kod na serwerze

Co się stało

12 listopada 2026 roku PostgreSQL Global Development Group opublikowała PostgreSQL 18.7, 17.12, 16.16, 15.20 i 14.25. Według The Hacker News te wydania usuwają 52 luki bezpieczeństwa. Najpoważniejsza z nich to CVE-2026-6460 (CVSS 8.8), błąd typu type confusion w rdzeniu serwera.

Użytkownik bazy danych, który może tworzyć obiekty, może użyć ALTER ... SET DATA TYPE, aby zmusić serwer do odczytania nieaktualnej wartości tak, jakby miała nowy typ. Ten sam efekt mogą osiągnąć inne instrukcje DDL, na przykład ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Pozwala to użytkownikowi uruchomić dowolny kod jako użytkownik systemu operacyjnego, na którym działa PostgreSQL. Poprawka dodaje kontrole wersji, dzięki którym serwer może wykryć wartości niezgodne ze swoim typem.

Badacz bezpieczeństwa Mehmet Ince opublikował szczegółowy opis techniczny z działającym exploitem, który zademonstrował na PostgreSQL 18.6. Opis zawiera kod SQL powodujący awarię niezaktualizowanego serwera oraz krok ujawniający adresy pamięci. Nie zawiera końcowego kroku uruchamiającego polecenie. Badacz napisał, że mógł wywołać awarię na koncie logowania o najniższych uprawnieniach. Źródła nie podają, czy konto z wyłącznie domyślnymi uprawnieniami może pójść dalej i uruchomić kod. Red Hat wskazuje, że atakujący potrzebuje loginu do bazy, który może tworzyć lub modyfikować obiekty.

Projekt PostgreSQL nie zgłosił żadnych ataków wykorzystujących tę lukę, a CISA nie umieszcza jej na liście aktywnie wykorzystywanych.

Te same wydania usuwają także inne luki, w tym CVE-2026-116322, która pozwala nieuwierzytelnionemu klientowi wymusić ponowne uruchomienie serwerów PostgreSQL 18. Naprawiono też luki w narzędziach klienckich: spreparowane archiwum może spowodować uruchomienie kodu przez pg_restore z uprawnieniami użytkownika, który go uruchamia, a przejęty serwer źródłowy może sprawić, że psql uruchomi kod za pośrednictwem skryptu odtwarzania w wyjściu tar z pg_dump.

Kogo to dotyczy

• PostgreSQL 18 przed 18.7, 17 przed 17.12, 16 przed 16.16, 15 przed 15.20 i 14 przed 14.25.
• Starsze główne wersje również są podatne i nie otrzymają aktualizacji. PostgreSQL 14 osiągnął koniec wsparcia, a 14.25 jest jego ostatnim wydaniem.
• Ryzyko jest największe na serwerach, na których osoby, którym nie w pełni ufamy, mają login do bazy pozwalający tworzyć lub zmieniać obiekty. Dotyczy to hostingu współdzielonego, baz udostępnianych klientom oraz aplikacji webowych, których konto bazodanowe jest właścicielem ich schematu. Jeśli atakujący przejmie taką aplikację, na przykład przez SQL injection, może być w stanie wykorzystać jej konto bazodanowe w ten sposób.
• Usługi zarządzane: badacz przekazał dowody koncepcji firmom AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks i Ubicloud. Ich aktualny stan poprawek nie jest znany. Warto sprawdzić komunikaty dostawcy.
• Serwery, na których nie działa PostgreSQL, nie są podatne. MySQL i MariaDB nie są podatne.

Co zrobić teraz

1. Wykonaj kopię zapasową konfiguracji PostgreSQL (na przykład postgresql.conf i pg_hba.conf) i upewnij się, że masz aktualną kopię zapasową bazy danych.
2. Zaktualizuj serwer do wydania naprawiającego dla swojej głównej wersji: 18.7, 17.12, 16.16, 15.20 lub 14.25. Jeśli korzystasz z pakietów dystrybucji (Debian, Ubuntu, RHEL i klony), zainstaluj poprawione pakiety wymienione w komunikacie bezpieczeństwa swojej dystrybucji, gdy tylko będą dostępne. Następnie użyj menedżera pakietów jak zwykle (apt update && apt upgrade lub dnf upgrade).
3. Zaktualizuj lub przebuduj każde rozszerzenie w języku C równocześnie z serwerem. Opiekunowie pakietów RPM projektu ostrzegają, że rozszerzenia zbudowane dla starszych wydań nadal się ładują, ale mogą nie być chronione. Niektóre rozszerzenia wymagają również zmian w kodzie źródłowym. Pakiety rozszerzeń w repozytoriach RPM PostgreSQL wymagają teraz nowego wydania poprawkowego.
4. Uruchom ponownie PostgreSQL. Jeśli działa poza jednostką usługi swojego pakietu, na przykład pod Patroni, uruchom go ponownie ręcznie zaraz po aktualizacji.
5. Postępuj zgodnie z krokami reindeksacji podanymi w oficjalnym ogłoszeniu wydania. Jeśli korzystasz z przyrostowych kopii zapasowych, wykonaj nową pełną kopię zapasową i na niej opieraj kolejne przyrostowe kopie.
6. Zaktualizuj narzędzia klienckie, takie jak pg_dump, pg_restore, psql, reindexdb i vacuumdb, na każdej maszynie, która z nich korzysta, w tym na hostach kopii zapasowych i stacjach administratorskich.
7. Nie używaj nowego ustawienia composite_type_mismatch do wyłączania nowych kontroli. Projekt zaznacza, że takie działanie niesie ze sobą zagrożenia dla bezpieczeństwa.
8. Jeśli nie możesz od razu zaktualizować, pamiętaj, że projekt nie oferuje obejścia. Do czasu aktualizacji sprawdź, które konta mogą tworzyć lub zmieniać obiekty, szczególnie konta używane przez aplikacje webowe lub udostępniane klientom, i upewnij się, że PostgreSQL nie jest dostępny z internetu, o ile nie musi być.
9. Jeśli nadal używasz PostgreSQL 14 lub starszej wersji, zaplanuj aktualizację do wspieranej wersji głównej.

Jak sprawdzić, czy jesteś narażony

• Sprawdź wersję działającego serwera poleceniem psql -c 'SELECT version();' lub SHOW server_version;. Wersje poniżej 18.7, 17.12, 16.16, 15.20 lub 14.25 w obrębie swojej serii głównej są podatne.
• Sprawdź zainstalowane pliki binarne i pakiety poleceniami postgres -V, dpkg -l | grep postgresql lub rpm -qa | grep postgresql. Jeśli działająca wersja jest starsza niż zainstalowana, uruchom serwer ponownie.
• Wylistuj zainstalowane rozszerzenia poleceniem SELECT extname, extversion FROM pg_extension; w każdej bazie danych. Upewnij się, że każde rozszerzenie w języku C zostało zaktualizowane lub przebudowane dla nowego wydania.
• Sprawdź logi PostgreSQL pod kątem nieoczekiwanych awarii procesów backendu, na przykład procesów serwera zakończonych sygnałem. Opublikowany exploit powoduje awarię niezaktualizowanych serwerów, dlatego takie awarie warto dokładniej przeanalizować.

Źródła

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/