Ocena 7.2 w skali CVSS (Common Vulnerability Scoring System) 1 została przypisana nowej luce w popularnym systemie baz danych PostgreSQL. Problem, zidentyfikowany jako CVE-2026-6476, to klasyczne wstrzyknięcie SQL (Structured Query Language), które w specyficznych warunkach pozwala na pełne przejęcie kontroli nad serwerem bazy danych. Luka dotyczy wyłącznie najnowszych głównych gałęzi rozwojowych: 17 oraz 18 2. Starsze wersje nie są podatne 3.

Podatność tkwi w funkcji pg_createsubscriber 4. Atakujący, który posiada już relatywnie wysokie uprawnienia pg_create_subscription, może spreparować złośliwy ciąg znaków, który zostanie wykonany z uprawnieniami superużytkownika. To scenariusz eskalacji uprawnień, gdzie konto o ograniczonym dostępie zyskuje najwyższy możliwy poziom kontroli. Dla wielu polskich firm, które używają PostgreSQL do przechowywania danych klientów, danych transakcyjnych czy informacji wrażliwych, konsekwencje mogą być poważne.

TL;DR

  • Produkt: PostgreSQL, wersje główne 17 i 18 5.
  • Wektor: Wstrzyknięcie SQL (SQL Injection) w funkcji pg_createsubscriber 4.
  • Identyfikator: CVE-2026-6476.
  • Wpływ: Atakujący z uprawnieniami pg_create_subscription może wykonać dowolny kod SQL jako superużytkownik bazy danych 6.
  • Kogo dotyczy: Organizacje, w tym polskie firmy z sektora e-commerce i fintech, korzystające z PostgreSQL w wersjach 17.x poniżej 17.10 oraz 18.x poniżej 18.4 2.
  • Pierwszy ruch reagowania: Identyfikacja podatnych instancji i natychmiastowa aktualizacja do wersji 17.10 lub 18.4 7 8.

Wektor ataku

Luka oznaczona jako CVE-2026-6476 to klasyczny przykład wstrzyknięcia SQL. Jest to technika ataku, w której złośliwy kod jest „wstrzykiwany” do zapytania bazy danych poprzez dane wejściowe od użytkownika, które nie zostały odpowiednio oczyszczone. W tym konkretnym przypadku, podatny jest komponent kliencki 9 i funkcja pg_createsubscriber 4.

Scenariusz ataku wymaga spełnienia dwóch warunków:

  1. Posiadanie uprawnień: Atakujący musi dysponować kontem w bazie danych z nadanym uprawnieniem pg_create_subscription 6. Nie jest to domyślne uprawnienie dla standardowego użytkownika, co ogranicza wektor ataku do osób z wewnątrz organizacji lub do scenariuszy, gdzie atakujący przejął już konto uprzywilejowanego użytkownika.
  2. Opóźniona egzekucja: Wstrzyknięty kod nie jest wykonywany natychmiast. Atak staje się skuteczny dopiero przy następnym uruchomieniu procesu pg_createsubscriber 10 11. To opóźnienie może utrudnić korelację ataku z działaniami konkretnego użytkownika.

Po spełnieniu tych warunków, spreparowane przez atakującego polecenie SQL jest wykonywane z uprawnieniami superużytkownika. W kontekście PostgreSQL superużytkownik ma nieograniczony dostęp. Może odczytać, zmodyfikować i usunąć dowolne dane, zmienić konfigurację serwera, a w niektórych konfiguracjach systemu operacyjnego nawet wykonać dowolny kod na serwerze hostującym bazę danych. To najwyższy poziom kompromitacji instancji bazodanowej.

Podatne są następujące wersje 5:

  • Wszystkie wersje PostgreSQL 17 przed 17.10.
  • Wszystkie wersje PostgreSQL 18 przed 18.4.

Co istotne, wersje PostgreSQL starsze niż 17 nie są dotknięte tą konkretną luką 12. Organizacje korzystające ze starszych, ale wciąż wspieranych gałęzi (np. 16, 15) nie muszą podejmować natychmiastowych działań w odpowiedzi na ten konkretny alert, choć regularne aktualizacje pozostają kluczową praktyką bezpieczeństwa.

Wskaźniki kompromitacji

Ta podatność nie generuje typowych wskaźników kompromitacji (IoC — Indicators of Compromise), takich jak hashe plików, adresy IP czy domeny serwerów C2 (Command and Control). Atak odbywa się wewnątrz logiki samej bazy danych. Zamiast szukać zewnętrznych artefaktów, zespoły bezpieczeństwa powinny skupić się na analizie logów samej bazy danych.

Rekomendujemy przegląd logów audytowych PostgreSQL pod kątem następujących aktywności:

  • Wszelkie użycie funkcji pg_createsubscriber.
  • Próby nadania uprawnienia pg_create_subscription nowym lub istniejącym rolom.
  • Nietypowe lub podejrzanie wyglądające zapytania wykonywane przez procesy związane z replikacją i subskrypcjami.

Brak nietypowych wpisów nie gwarantuje jednak, że system nie został skompromitowany, zwłaszcza jeśli poziom logowania nie był wystarczająco szczegółowy.

Co zrobić w 24-48h

Rekomendowane podejście zakłada działanie w trzech krokach. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią fundament reakcji na incydent.

  1. Identyfikacja i weryfikacja (2 godziny):

    • Przeprowadź pilny audyt wszystkich instancji PostgreSQL w swojej infrastrukturze. Użyj zapytania SELECT version(); na każdej instancji, aby zidentyfikować te, które działają na podatnych wersjach (17.x < 17.10, 18.x < 18.4) 2.
    • Stwórz listę priorytetową serwerów, zaczynając od tych przechowujących najbardziej krytyczne dane — dane klientów, dane finansowe, dane objęte regulacjami RODO (Rozporządzenie o Ochronie Danych Osobowych).

  2. Aktualizacja (24 godziny):

    • Zastosuj poprawki bezpieczeństwa wydane przez projekt PostgreSQL 14 maja 2026 roku 7 8. Zaktualizuj podatne instancje do wersji 18.4 lub 17.10 (lub nowszych).
    • W środowiskach produkcyjnych, gdzie wymagana jest wysoka dostępność, postępuj zgodnie z wewnętrzną procedurą zarządzania zmianą. Pamiętaj o wykonaniu kopii zapasowej przed aktualizacją. 3. Weryfikacja i utwardzanie (48 godzin):
    • Po aktualizacji, przeprowadź audyt uprawnień w bazie danych. Zweryfikuj, które role i którzy użytkownicy posiadają uprawnienie pg_create_subscription. Zgodnie z zasadą najmniejszych uprawnień (Principle of Least Privilege), odbierz to prawo wszystkim kontom, które go bezwzględnie nie potrzebują.
    • Przeanalizuj logi bazodanowe z ostatnich tygodni pod kątem podejrzanych prób użycia pg_createsubscriber. Dla polskich firm MŚP, które często nie posiadają dedykowanego zespołu SOC (Security Operations Center), może to być trudne. Warto rozważyć wdrożenie podstawowego monitoringu logów. ## Atrybucja

Problem został odpowiedzialnie zgłoszony do twórców oprogramowania. Projekt PostgreSQL publicznie podziękował badaczowi bezpieczeństwa Yu Kunpengowi za zidentyfikowanie i zgłoszenie tej luki 13.

Źródła

Zobacz też

Footnotes

  1. Ogólny wynik CVSS dla tej luki wynosi 7.2. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩

  2. Dotknięte są wersje PostgreSQL 17 i 18, a konkretnie wersje mniejsze niż 18.4 i 17.10. — https://nvd.nist.gov/vuln/detail/CVE-2026-6476 ↩ ↩2 ↩3

  3. Wersje PostgreSQL wcześniejsze niż 17 nie są dotknięte. — https://nvd.nist.gov/vuln/detail/CVE-2026-6476 ↩

  4. Luka SQL injection w PostgreSQL pg_createsubscriber umożliwia atakującemu z uprawnieniami pg_create_subscription wykonanie dowolnego kodu SQL jako superużytkownik. — https://nvd.nist.gov/vuln/detail/CVE-2026-6476 ↩ ↩2 ↩3

  5. Wersje główne 17 i 18, a konkretnie wersje mniejsze niż PostgreSQL 18.4 i 17.10, są dotknięte. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩ ↩2

  6. Luka SQL injection w PostgreSQL pg_createsubscriber pozwala atakującemu z uprawnieniami pg_create_subscription na wykonanie dowolnego kodu SQL jako superużytkownik. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩ ↩2

  7. Wersja 18 została naprawiona w wersji 18.4, a poprawka została opublikowana 14 maja 2026 roku. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩ ↩2

  8. Wersja 17 została naprawiona w wersji 17.10, a poprawka została opublikowana 14 maja 2026 roku. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩ ↩2

  9. Komponentem, którego dotyczy luka, jest ‘client’. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩

  10. Atak z wykorzystaniem tej luki staje się skuteczny, gdy pg_createsubscriber zostanie uruchomiony ponownie. — https://nvd.nist.gov/vuln/detail/CVE-2026-6476 ↩

  11. Atak staje się skuteczny, gdy pg_createsubscriber zostanie uruchomiony ponownie. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩

  12. Wersje wcześniejsze niż PostgreSQL 17 nie są dotknięte. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩

  13. Projekt PostgreSQL dziękuje Yu Kunpengowi za zgłoszenie tego problemu. — https://www.postgresql.org/support/security/CVE-2026-6476/ ↩