PostgreSQL: 28 CVE w jednym wydaniu, w tym wiele dróg do wykonania kodu

PostgreSQL Global Development Group opublikował 13 sierpnia 2026 roku aktualizacje 18.6, 17.11, 16.15, 15.19 i 14.24. Oficjalny komunikat wymienia 28 naprawionych podatności oraz ponad 110 innych błędów. To nie jest zwykły kwartalny zestaw kosmetycznych korekt: kilkanaście pozycji ma ocenę 8,8 i może prowadzić do wykonania kodu jako systemowy użytkownik bazy, jeśli atakujący spełni warunki danego CVE.

Wydanie PostgreSQL 18 przeskakuje z 18.4 do 18.6, ponieważ 18.5 nie zostało udostępnione z powodu regresji. Strony poszczególnych CVE mogą wskazywać 18.5 jako pierwotny punkt naprawy, ale dla wdrożenia należy użyć opublikowanej wersji 18.6. Pozostałe bezpieczne progi to 17.11, 16.15, 15.19 i 14.24. PostgreSQL 14 kończy wsparcie 12 listopada 2026 roku, więc jego aktualizacja powinna iść w parze z planem migracji do nowszej gałęzi.

Dlaczego liczba 28 nie mówi wszystkiego

Podatności obejmują serwer, rozszerzenia contrib oraz narzędzia klienckie. Nie tworzą jednego anonimowego exploita dostępnego przez port 5432. Wiele wymaga prawidłowego konta bazy, własności obiektu, uprawnienia do tworzenia funkcji, roli REPLICATION albo kontroli nad serwerem źródłowym używanym przez pg_dump. Priorytet zależy więc od modelu uprawnień i od tego, czy organizacja traktuje użytkowników bazy oraz źródła backupu jako w pełni zaufane.

Najszerszy sygnał daje CVE-2026-14680. Luka type confusion w argumentach typu internal pozwala dowolnemu użytkownikowi bazy wywołać niekompatybilną funkcję i potencjalnie wykonać kod jako konto systemowe PostgreSQL. Typ internal miał nie być dostępny bezpośrednio z SQL, ale zabezpieczenie nie obejmowało wszystkich przypadków. Ocena 8,8 odzwierciedla zmianę z nisko uprzywilejowanego konta SQL do procesu serwera.

CVE-2026-14664 dotyczy przepełnienia bufora na stercie w obsłudze wyrażeń regularnych, CVE-2026-14669 — długiej POSIX-owej nazwy strefy czasowej przekazywanej do to_char(timestamptz), a CVE-2026-14662 — integer wraparound w typach tsvector i tsquery. Każdy z tych błędów może prowadzić do zapisu poza buforem i wykonania kodu, ale wejście pochodzi z innych miejsc. Skan wersji wskazuje potrzebę poprawki; analiza osiągalności decyduje, które aplikacje były najbardziej narażone.

Niebezpieczne granice backupu i narzędzi klienckich

CVE-2026-18408 pokazuje, że kopia bazy jest aktywnym artefaktem. Złośliwy superuser serwera źródłowego może wprowadzić dane, które przy odtwarzaniu plain-text dumpa zostaną potraktowane przez psql jako metapolecenia. Poprzednia ochrona oparta na \restrict i \unrestrict okazała się niepełna. Dotknięte są pg_dump, pg_dumpall oraz ścieżka, w której pg_restore generuje format tekstowy.

CVE-2026-19385 to odrębne przepełnienie bufora podczas pg_dump długich list transformacji funkcji. CVE-2026-15741 pozwala właścicielowi obiektu wstrzyknąć SQL przez deparsowanie argumentu EXTRACT(), co może dotknąć pg_dump, polecenia psql takie jak \sf i narzędzia korzystające z tego samego mechanizmu. CVE-2026-6464 dotyczy wczesnej porażki COPY FROM STDIN, po której linie danych mogą zostać zinterpretowane jako polecenia psql.

Wniosek operacyjny jest ważny: backup pobrany z nieufnego albo przejętego serwera należy odtwarzać w izolowanym środowisku, nawet jeśli jest tekstem. Narzędzie klienckie działa jako użytkownik wykonujący restore i może mieć klucze chmurowe, prawa do filesystemu oraz dostęp sieciowy. Aktualizacja zamyka znane drogi, ale zasada izolacji chroni przed kolejnym błędem parsera.

Rozszerzenia i mniej oczywiste powierzchnie

Kilka CVE dotyczy komponentów, które nie są włączone w każdej bazie. CVE-2026-14670 obejmuje zwracanie tied hash z funkcji PL/Perl. CVE-2026-14671 dotyczy modułu refint, CVE-2026-15742 — ekstremalnych wejść funkcji Levenshteina w fuzzystrmatch, a CVE-2026-14676 — pg_stat_statements w PostgreSQL 18. CVE-2026-6471 pozwala użytkownikowi z REPLICATION wskazać bibliotekę logicznego dekodowania i doprowadzić do jej załadowania przez dlopen.

To argument przeciwko prostemu pytaniu „czy mamy PostgreSQL?”. Trzeba wiedzieć, które rozszerzenia są zainstalowane, kto może tworzyć funkcje i obiekty, jakie role mają REPLICATION, jakie języki proceduralne działają oraz z jakich serwerów przyjmowane są dumpy. Usunięcie nieużywanego rozszerzenia zmniejsza powierzchnię, lecz nie zastępuje aktualizacji core.

Zestaw zawiera również błędy poufności i autoryzacji: cache polityk row-level security może przez pewien czas honorować stare prawa po zmianie członkostwa roli; ctid może ujawniać pochodne wartości pamięci; SCRAM z niestandardowym scram_iterations umożliwia odróżnienie istniejącego użytkownika; konfiguracja GSSAPI w połączeniu z bezpośrednim TLS może zapewnić słabszą ochronę niż sugeruje pg_hba.conf. Nie wszystkie prowadzą do RCE, ale są istotne w środowiskach wielotenantowych i regulowanych.

Plan aktualizacji bez utraty dowodów i dostępności

1. Zidentyfikuj każdą instancję, kontener, usługę zarządzaną, klienta administracyjnego i obraz używany przez zadania backupu.
2. Przypisz gałąź do opublikowanej wersji: 18.6, 17.11, 16.15, 15.19 lub 14.24. Nie wdrażaj nieopublikowanej 18.5.
3. Ustal, czy dostawca chmurowy już zastosował poprawkę i czy wymagany jest restart, failover lub wybór nowego maintenance window.
4. Przejrzyj role SQL, REPLICATION, języki proceduralne, rozszerzenia, źródła dumpów oraz usługi przyjmujące surowe zapytania lub typy wyszukiwania pełnotekstowego.
5. Przetestuj aktualizację na reprezentatywnej replice, w tym sterowniki, rozszerzenia natywne, replikację, backup i restore.
6. Wdróż według klastra i potwierdź efektywny numer binariów na każdym primary, standby, workerze i hoście narzędziowym.
7. Przeanalizuj okres przed poprawką, jeśli nieufni użytkownicy mieli konto SQL, własność obiektów, REPLICATION albo możliwość dostarczenia dumpa.

Aktualizacje minor PostgreSQL są kumulatywne i nie wymagają pg_upgrade ani pełnego dump/reload; standardowo wystarczy zatrzymanie procesu i wymiana binariów. Nie oznacza to jednak braku planu. Rozszerzenia skompilowane natywnie muszą być zgodne, a system HA musi przejść przez kontrolowany failover lub restart.

Trzy działania po aktualizacji

Komunikat projektu wskazuje dodatkowe kroki związane z wcześniejszymi błędami danych. Po pierwsze, tabele z indeksami GIN mogą mieć nieprawidłowe reltuples, nawet Infinity lub NaN, co blokuje autovacuum i autoanalyze; po aktualizacji trzeba je znaleźć i wykonać ANALYZE. Po drugie, indeksy btree_gist na typach float zawierających NaN oraz na bit lub bit varying mogą wymagać REINDEX. Po trzecie, bardzo długie wartości ltree mogły prowadzić do błędnych porównań i uszkodzonego indeksu B-tree, który również wymaga przebudowy.

Samo zgłoszenie poprawnej wersji przez package manager nie dowodzi ukończenia pracy. Kryterium zamknięcia powinno obejmować aktywny proces z nowymi binariami, zdrową replikację, pomyślny restore testowy, zgodność rozszerzeń i wykonanie właściwych działań naprawczych dla indeksów. Dla wersji 14 potrzebny jest również właściciel migracji przed EOL.

Hunting i weryfikacja naruszenia

Nie ma w oficjalnym komunikacie informacji o masowej kampanii. Jeżeli jednak środowisko miało nisko zaufane konta SQL, przegląd powinien objąć tworzenie oraz modyfikacje funkcji, rozszerzeń, publikacji logicznych i obiektów z nietypowymi definicjami. Na hoście warto szukać procesów potomnych postgres, nowych bibliotek, plików w katalogach wykonywalnych, zmian mechanizmów startowych i połączeń wychodzących niepasujących do normalnego profilu.

W przypadku narzędzi klienckich przejrzyj hosty, na których wykonywano dump lub restore z obcego źródła. Zdarzenie może dotyczyć operatora albo automatu CI, nie samego serwera bazy. Koreluj pochodzenie dumpa, czas uruchomienia, konto systemowe i docelowe zasoby. Aktualizacja zamyka lukę, ale nie usuwa trwałości utworzonej wcześniej.

Fakty o liczbie CVE, wersjach, trzech działaniach po aktualizacji i warunkach poszczególnych luk pochodzą z komunikatu PostgreSQL oraz stron projektu. Priorytetyzacja, izolacja backupów i telemetria są rekomendacjami Breachroad. Złożone wydanie warto przełożyć na wspólne ćwiczenie zespołu podczas szkoleń cyberbezpieczeństwa dla organizacji. Niezależną ocenę ról, ekspozycji i procesu aktualizacji zapewnia audyt bezpieczeństwa IT.