Podatność PostgreSQL CVE-2026-6460 pozwala osobie, która może tworzyć obiekty w bazie, wykonywać kod z uprawnieniami użytkownika systemowego uruchamiającego bazę. Poprawka jest dostępna w PostgreSQL 18.7, 17.12, 16.16, 15.20 i 14.25. Dla małego zespołu SaaS najważniejszy jest jednak szczegół: sama aktualizacja serwera może nie wystarczyć. PostgreSQL podaje, że pełna ochrona wymaga również ponownej kompilacji rozszerzeń napisanych w C, a w niektórych trzeba zmienić kod źródłowy. Zanim zamkniesz zadanie, sprawdź działające wdrożenie i jego rozszerzenia. ([Komunikat bezpieczeństwa](https://www.postgresql.org/support/security/CVE-2026-6460/), [informacje o wydaniu](https://www.postgresql.org/docs/17/release-17-12.html).)

Inżynier aktualizuje obraz bazy, usługa znów się łączy i zadanie wygląda na gotowe do zamknięcia. To dobry początek, ale pozostaje pytanie: czy wdrożony system zawiera wszystkie elementy poprawki?

W tym wydaniu ma ono bardzo konkretne znaczenie. Serwer sprawdza teraz wartości złożone, których układ nie odpowiada już typowi używanemu do ich interpretacji. Rozszerzenia natywne uczestniczą w tym mechanizmie. Udany restart i oczekiwany numer wersji nie dowodzą, że zostały poprawnie skompilowane ponownie.

Trzeba więc zebrać dowody pozwalające ustalić, co zaktualizowano, co rzeczywiście działa i czego nadal nie wiadomo. Można to zrobić bez zamieniania aktualizacji bezpieczeństwa w zbędną migrację bazy danych.

## Ustal, jakiego dostępu wymaga wykorzystanie podatności

Ocenę narażenia oprzyj na warunku z komunikatu: atakujący musi mieć możliwość tworzenia obiektów w bazie. Ktoś z takimi uprawnieniami ma inny dostęp do PostgreSQL niż klient korzystający wyłącznie z formularzy twojego produktu.

Sprawdź, kto w twoim wdrożeniu może łączyć się z bazą i tworzyć obiekty: role używane przez usługę, role migracyjne, programiści, automatyzacje oraz klienci, którym udostępniasz SQL. Uwzględnij uprawnienia wynikające z członkostwa w innych rolach. Jeśli takie możliwości mają mniej zaufani użytkownicy, powinna o tym wiedzieć osoba planująca wdrożenie poprawki.

To przegląd dostępu, a nie kompletne zabezpieczenie. Nie zakładaj, że zablokowanie jednej operacji SQL rozwiązuje problem: PostgreSQL opisuje kilka ścieżek wykorzystujących operacje definiowania danych, czyli DDL.

Podobnie sam numer podatnej wersji nie dowodzi, że nieuwierzytelniony odwiedzający może zaatakować twój produkt SaaS. Potrzebne są dowody, jak mógłby uzyskać wymagane możliwości w bazie. ([Komunikat PostgreSQL](https://www.postgresql.org/support/security/CVE-2026-6460/).)

Precyzyjnie określ też możliwe skutki. Wykonywanie kodu jako użytkownik systemowy PostgreSQL jest poważnym zagrożeniem. Dostęp do administracji hostem, danych innego klienta czy kolejnej usługi zależy jednak od otoczenia bazy. Bez dowodów żaden z tych dodatkowych skutków nie powinien trafić do dokumentacji incydentu jako ustalony fakt.

Małemu zespołowi może wystarczyć krótka notatka: która baza, jakie role, kto odpowiada za aktualizację i jakie dostępy są jeszcze sprawdzane. Gdy trzeba przejść od prac utrzymaniowych do reagowania na incydent, [jednostronicowy plan reagowania](/blog/solo-founder-incident-response-plan) pomaga jasno przypisać odpowiedzialność.

## Wybierz poprawioną wersję z obecnej gałęzi

Komunikat projektu wymienia następujące pierwsze poprawione wersje z poszczególnych gałęzi, opublikowane 12 listopada 2026 r.:

| Gałąź PostgreSQL | Pierwsza poprawiona wersja projektu |
| --- | --- |
| 18 | 18.7 |
| 17 | 17.12 |
| 16 | 16.16 |
| 15 | 15.20 |
| 14 | 14.25 |

Źródło: [komunikat CVE-2026-6460](https://www.postgresql.org/support/security/CVE-2026-6460/).

Zacznij od wydania dla obecnej głównej wersji. PostgreSQL rozróżnia aktualizację w obrębie gałęzi od zmiany głównej wersji. Ta pierwsza zachowuje format przechowywania danych i zwykle wymaga zatrzymania serwera, instalacji nowych plików binarnych oraz ponownego uruchomienia. Zmiana głównej wersji ma osobny proces migracji.

Zawsze czytaj informacje o wydaniach, aby sprawdzić dodatkowe kroki, również dla pominiętych aktualizacji. ([Zasady wersjonowania](https://www.postgresql.org/support/versioning/).)

Przykładowo aktualizacja PostgreSQL 17 do 17.12 to inne zadanie niż przejście na PostgreSQL 18. Oddziel pilną poprawkę od planowanej zmiany głównej wersji i ustal osobne kryteria odbioru.

Dostawca usługi zarządzanej lub dystrybucji może przenieść poprawkę do starszej wersji, nadając jej inny identyfikator kompilacji. Poproś wtedy o dowód, że wdrożona kompilacja zawiera poprawkę tej CVE. Numer różniący się od poprawionego wydania projektu wymaga wyjaśnienia; sam nie wystarcza, by uznać usługę za poprawioną albo podatną.

## Uwzględnij rozszerzenia natywne w aktualizacji

Wymaganie dotyczące rozszerzeń najłatwiej zgubić między komunikatem bezpieczeństwa, zadaniem wdrożeniowym a komentarzem zamykającym sprawę.

Informacje o wydaniu PostgreSQL mówią wprost, że pełna ochrona wymaga ponownej kompilacji rozszerzeń napisanych w C, a niektóre będą wymagały zmian w kodzie źródłowym. Opisują również parametr serwera `composite_type_mismatch`, który pozwala wyłączyć nowe sprawdzenia, co wiąże się z ryzykiem dla bezpieczeństwa. Zgodność rozszerzeń i konfiguracja ochrony muszą więc znaleźć się w dokumentacji poprawki. ([Informacje o PostgreSQL 17.12](https://www.postgresql.org/docs/17/release-17-12.html).)

Przed wdrożeniem zapytaj opiekuna obrazu, dostawcę pakietów lub operatora bazy, jak jego kompilacje rozszerzeń uwzględniają tę zmianę. Jeśli zespół sam kompiluje rozszerzenia, wyznacz osobę odpowiedzialną za sprawdzenie zgodności i przygotowanie nowych plików binarnych.

Nie zakładaj, że instalacja najnowszego pakietu serwera zastępuje też każdy ładowany przez niego komponent natywny. Wstępny przegląd możesz wykonać zapytaniami SQL tylko do odczytu:

```sql
SELECT version();
SHOW server_version;
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
```

Wykonaj je na punkcie dostępu do bazy, który chcesz zweryfikować. PostgreSQL opisuje informacje o wersji serwera w [funkcjach informacji o systemie](https://www.postgresql.org/docs/17/functions-info.html). Wersja klienta zainstalowanego na laptopie odpowiada na inne pytanie.

Lista rozszerzeń pomaga ustalić dalsze prace, lecz widoczne numery wersji nie dowodzą, że ponownie skompilowano pliki binarne. Dołącz dokumentację pakietu, obrazu, kompilacji lub potwierdzenie dostawcy dotyczące tego wymagania.

Jeżeli ktoś wyłączył nowe sprawdzenia, aby uruchomić rozszerzenie, zapisz tę nierozstrzygniętą decyzję dotyczącą bezpieczeństwa wprost.

## Oddziel działania operatora od dowodów zbieranych przez zespół

Gdy samodzielnie utrzymujesz PostgreSQL, zespół może odpowiadać za artefakt serwera, rozszerzenia, restart i sprawdzenie działania produktu. W usłudze zarządzanej większość tych operacji może należeć do dostawcy. Po twojej stronie nadal musi być osoba odpowiedzialna za zebranie dowodów.

Zadaj dostawcy pytanie odnoszące się do konkretnego wdrożenia: czy obecna kompilacja tej usługi zawiera poprawkę CVE-2026-6460 i jak uwzględniono rozszerzenia natywne? Zapytaj też, czy klient musi wykonać prace utrzymaniowe i czy nowa ochrona jest włączona. Zachowaj odpowiedź wraz z identyfikatorem usługi i zapisem wykonanych prac.

[Techniczny opis badacza](https://mehmetince.net/part-3-6-how-i-ended-up-turning-a-22-year-old-postgresql-type-confusion-primitive-into-rce-cve-2026-6460/) wyjaśnia, dlaczego badał również zarządzane usługi PostgreSQL. Nie ustala jednak obecnego stanu poprawek u twojego dostawcy ani na twojej instancji. Daje kontekst; do zamknięcia zadania potrzebujesz dowodów dotyczących własnego wdrożenia.

Ta sama zasada dotyczy infrastruktury utrzymywanej przez zespół. Zmiana wskazanego obrazu pokazuje zamiar wdrożenia. Zapis wdrożenia i zapytanie do działającego serwera pomagają ustalić wynik.

Powtórz sprawdzenie dla odpowiednich instancji i punktów dostępu. Jedno udane połączenie nie dowodzi, że cały zestaw serwerów jest zaktualizowany.

## Zamknij zadanie, dołączając zwięzły zestaw dowodów

Rzeczowy komentarz przy zamknięciu pozwala innemu inżynierowi zrozumieć wynik bez odtwarzania przebiegu wdrożenia z wiadomości na czacie.

| Pytanie przed zamknięciem | Dowody do dołączenia |
| --- | --- |
| Co zaktualizowaliśmy? | Usługa lub punkt dostępu do bazy, poprzednia wersja, docelowy artefakt lub kompilacja dostawcy |
| Co działa teraz? | Wynik zapytania o wersję serwera oraz zapis zakończonego wdrożenia lub prac utrzymaniowych |
| Czy uwzględniono rozszerzenia natywne? | Lista rozszerzeń oraz dowód zgodnej ponownej kompilacji lub potwierdzenie dostawcy |
| Czy nowa ochrona jest aktywna? | Przegląd konfiguracji, w tym decyzji dotyczących `composite_type_mismatch` |
| Czy produkt nadal działa? | Wyniki reprezentatywnych sprawdzeń odpowiednich dla produktu |
| Co pozostaje otwarte? | Wyznaczona osoba i kolejne działanie dla każdego nierozwiązanego punktu |

Dobierz sprawdzenia do rzeczywistego działania produktu: łączenia z bazą, odczytu i zapisu reprezentatywnych danych oraz ważnych funkcji zależnych od rozszerzeń. Są to kryteria odbioru zmiany, a nie dowód zachowania wszystkich właściwości bezpieczeństwa.

Jeśli nie wiadomo, jak skompilowano rozszerzenie, pozostaw ten punkt otwarty. Gdy dostawca potwierdza przeniesienie poprawki do starszej wersji, zachowaj dokładny identyfikator kompilacji. To zasada znana z [weryfikacji napraw w systemach zależnych](/blog/revoked-certificates-downstream-remediation): znaczenie ma zarówno wprowadzona zmiana, jak i systemy, które od niej zależą.

Jeśli śledzisz podatność w Kit, [proces triażu zgłoszeń](/docs/triaging-reports) pozwala zebrać w jednym miejscu odpowiedzialność za zgłoszenie, korespondencję i decyzję człowieka o zweryfikowaniu poprawki. Zespół infrastruktury lub dostawca dostarcza dowody uzasadniające tę decyzję.

## Nie pomijaj dalszych prac związanych z wydaniem

Listopadowe wydanie zawiera też poprawki wymagające osobnych prac utrzymaniowych. Sprawdź informacje o migracji dla swojej gałęzi: naprawa indeksów i działania dotyczące kopii zapasowych zależą od konkretnych warunków.

Zespołom korzystającym z przyrostowych kopii zapasowych PostgreSQL zaleca wykonanie nowej pełnej kopii po aktualizacji i używanie jej jako podstawy kolejnych kopii przyrostowych. To dalsze działania związane z wydaniem; nie oznaczają, że CVE-2026-6460 uszkodziła indeksy lub kopie zapasowe. ([Ogłoszenie wydania](https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/).)

PostgreSQL 14 wymaga kolejnej decyzji: 14.25 jest ostatnim wydaniem tej gałęzi, a projekt ogłosił koniec jej utrzymania. Wdróż dostępną poprawkę i równolegle zaplanuj przejście na utrzymywaną główną wersję. Wyznacz odpowiedzialną osobę i termin migracji zamiast dołączać ją bez wyraźnego ustalenia do pilnej poprawki.

Zakończ dokumentację jasnym zestawieniem dowodów: wdrożona kompilacja serwera, stan ponownej kompilacji rozszerzeń, konfiguracja ochrony i pozostałe prace. Kolejny inżynier dostanie konkretne materiały do przeglądu, a zespół będzie miał uzasadnioną podstawę do zamknięcia zadania.