E-Maj 5.0.1: krytyczna łata w rozszerzeniu PostgreSQL — eskalacja do superusera

E-Maj 5.0.1 to wydanie rozszerzenia PostgreSQL, które naprawia podatność obecną we wszystkich wcześniejszych wersjach projektu. Według ogłoszenia opublikowanego 31 października 2026 r. na portalu postgresql.org przez Philippe’a Beaudoina luka pozwala „niektórym użytkownikom” uzyskać uprawnienia superusera „w pewnych okolicznościach”. Producent zaleca aktualizację „tak szybko, jak to możliwe”.

Informacja dotyczy wyłącznie organizacji, które mają zainstalowane rozszerzenie E-Maj w swojej instancji PostgreSQL — nie całej populacji użytkowników PostgreSQL. To zawężenie jest istotne: E-Maj służy do szczegółowego logowania zapisów i odtwarzania stanu danych („time travel”) na wybranych podzbiorach bazy, więc trafia głównie do środowisk, w których liczy się audytowalność i możliwość cofnięcia zmian. W takich wdrożeniach eskalacja do superusera jest groźna, bo superuser w PostgreSQL omija mechanizmy kontroli dostępu — może czytać i modyfikować dowolne dane, tworzyć role i instalować kod w bazie.

Co dokładnie wiadomo, a czego źródło nie mówi

Materiał źródłowy jest krótki i celowo ogólny. Podaje cztery fakty: istnieje podatność, dotyczy wszystkich wcześniejszych wersji, w określonych warunkach prowadzi do eskalacji uprawnień do superusera, a wersja 5.0.1 ją naprawia. Nie podaje identyfikatora CVE, wektora ataku, listy funkcji ani wymaganych uprawnień po stronie atakującego.

To rozróżnienie trzeba mocno podkreślić: brak publicznego opisu technicznego w materiale źródłowym nie oznacza, że luka jest mało groźna. Oznacza, że nie da się dziś rzetelnie ocenić, jak trudno ją wykorzystać i czy istnieją warunki wstępne poza samą instalacją rozszerzenia. Poniższa analiza opiera się wyłącznie na tym, co producent potwierdził, oraz na ogólnej wiedzy o modelu uprawnień PostgreSQL. Wszędzie, gdzie wychodzę poza treść ogłoszenia, zaznaczam to jako interpretację.

Tło techniczne prostym językiem

Czym jest E-Maj

E-Maj to rozszerzenie do PostgreSQL. Rozszerzenie to paczka obiektów bazy danych — funkcji, tabel, typów — instalowana do instancji i działająca w jej wnętrzu z uprawnieniami bazy. E-Maj rejestruje zmiany w wyznaczonych tabelach w sposób bardziej szczegółowy niż standardowy log transakcyjny, a następnie pozwala odtworzyć stan danych z wybranego momentu. W praktyce używa się go tam, gdzie potrzebne jest precyzyjne cofanie operacji wsadowych, audyt zmian lub odtwarzanie danych po błędnym przetworzeniu.

Dlaczego eskalacja do superusera jest poważna

W PostgreSQL uprawnienia są warstwowe. Zwykły użytkownik widzi tylko to, do czego ma granty. Superuser widzi wszystko i może wszystko: czytać dowolne tabele, wyłączać mechanizmy bezpieczeństwa na poziomie wiersza, tworzyć funkcje działające z podwyższonymi prawami, instalować kolejne rozszerzenia. Jeśli luka pozwala przejść ze zwykłej roli do superusera, to zabezpieczenia na poziomie aplikacji i grantów przestają mieć znaczenie.

Rozszerzenia takie jak E-Maj są tu szczególnie wrażliwe, bo często instaluje się je z uprawnieniami wysokimi, a ich funkcje bywają oznaczane jako wykonywane z prawami właściciela (SECURITY DEFINER). To standardowy mechanizm, ale właśnie on bywa źródłem błędów, gdy funkcja nie sprawdza wystarczająco starannie, kto ją wywołuje. Zastrzeżenie: ogłoszenie nie wskazuje, czy problem dotyczy funkcji SECURITY DEFINER, więc to hipoteza mechanizmu, nie potwierdzony opis luki.

Zakres wersji

Producent podaje dwie informacje o zgodności, które trzeba czytać osobno:

• E-Maj 5.0.1 działa z PostgreSQL w wersjach 14–19.
• Emaj_web 5.0 (klient webowy) jest zgodny z rozszerzeniem emaj w wersjach 3.0–5.0.

Pierwsze zdanie dotyczy wersji samego PostgreSQL, drugie — zgodności klienta z rozszerzeniem. To nie to samo i mylenie tych osi jest częstym błędem przy planowaniu aktualizacji.

Realne konsekwencje dla organizacji

Skutki trzeba rozpatrywać w dwóch warstwach: technicznej i organizacyjnej.

Warstwa techniczna

• Utrata granicy zaufania między rolami. Jeśli użytkownik aplikacji lub analityk z ograniczonymi prawami może stać się superuserem, cały model uprawnień w instancji przestaje obowiązywać.
• Dostęp do danych poza zakresem. Superuser czyta wszystkie schematy, także te, do których dana rola nie powinna mieć dostępu.
• Trwałe następstwa. Superuser może zmienić dane, role i konfigurację. Samo cofnięcie uprawnień nie usuwa śladów, jeśli nie ma niezależnego audytu.

Warstwa organizacyjna

• Obowiązki regulacyjne. Instancje z danymi osobowymi lub danymi objętymi wymogami audytowymi wymagają udokumentowanej reakcji na podatność. Samo „załatamy później” jest trudne do obrony przy kontroli.
• Zależność od dostawcy. Jeśli PostgreSQL jest usługą zarządzaną, aktualizacja rozszerzenia może zależeć od operatora chmury, a nie od zespołu wewnętrznego. To trzeba ustalić, a nie zakładać.

Scenariusze ryzyka

Poniższe scenariusze to interpretacja możliwych konsekwencji, nie opis potwierdzonych wektorów ataku.

Scenariusz	Kto jest narażony	Możliwy skutek
Wielodostępowa instancja z wieloma rolami	Organizacje z aplikacjami różnych zespołów na jednej instancji	Przejęcie kontroli nad całą instancją przez rolę o niskich uprawnieniach
Środowisko analityczne z szerokim dostępem	Zespoły BI z kontami do odczytu	Dostęp do danych poza zakresem analityki
Instancja współdzielona z dostawcą zewnętrznym	Firmy oddające część administracji na zewnątrz	Trudność w ustaleniu, kto i kiedy może wykorzystać lukę
Brak monitoringu uprawnień	Wszystkie wdrożenia z E-Maj	Eskalacja może pozostać niewykryta przez długi czas

Nie ma podstaw w materiale źródłowym, by twierdzić, że luka jest aktywnie wykorzystywana. Nie ma też podstaw, by twierdzić, że nie jest. Brak danych to brak danych.

Jak sprawdzić, czy problem dotyczy Twojej infrastruktury

Sprawdzenie jest proste i nie wymaga dostępu do kodu rozszerzenia. Wystarczy ustalić, czy E-Maj jest zainstalowany i w jakiej wersji.

1. Połącz się z każdą instancją PostgreSQL, którą utrzymujesz, i wykonaj zapytanie o zainstalowane rozszerzenia: SELECT extname, extversion FROM pg_extension; — szukaj wiersza z nazwą emaj.
2. Jeśli rozszerzenie jest obecne, porównaj wersję z 5.0.1. Wszystko poniżej 5.0.1 jest według producenta narażone.
3. Sprawdź, czy w katalogu rozszerzeń są pliki E-Maj, nawet jeśli nie jest aktywowany w bieżącej bazie: SELECT * FROM pg_available_extensions WHERE name = 'emaj';
4. Ustal, czy używasz klienta emaj_web, i zanotuj jego wersję. Producent podaje zgodność emaj_web 5.0 z rozszerzeniem 3.0–5.0.
5. Zapisz wynik w rejestrze inwentarza razem z datą sprawdzenia.

Uwaga praktyczna: w klastrach z wieloma bazami rozszerzenie może być zainstalowane tylko w części z nich. Sprawdzenie trzeba powtórzyć dla każdej bazy, nie tylko dla bazy domyślnej.

Plan reakcji krok po kroku

Krok 1: Inwentaryzacja

Ustal listę instancji, baz i wersji E-Maj. Bez tego lista działań będzie niepełna. Uwzględnij środowiska testowe i staging — często to one zostają zapomniane, a mają kopie danych produkcyjnych.

Krok 2: Ocena ekspozycji

Dla każdej instancji oceń, ilu rolom przyznano dostęp i czy w instancji obowiązuje zasada minimalnych uprawnień. Instancja z jedną rolą aplikacyjną i brakiem dostępu człowiekiego ma inną ekspozycję niż instancja z dziesiątkami kont analitycznych.

Krok 3: Aktualizacja

Zaktualizuj rozszerzenie do 5.0.1 zgodnie z dokumentacją projektu. Producent wskazuje pgxn.org jako źródło instalacji i github.org jako miejsce rozwoju. Kolejność: najpierw środowisko testowe, potem produkcyjne. Przy aktualizacji rozszerzeń PostgreSQL trzeba sprawdzić, czy wymagane jest wykonanie ALTER EXTENSION ... UPDATE oraz czy zmiany nie wymagają restartu instancji.

Krok 4: Weryfikacja

Po aktualizacji ponownie sprawdź extversion i potwierdź, że w każdej bazie widnieje 5.0.1. Sprawdź też, czy klient emaj_web nadal komunikuje się z rozszerzeniem.

Krok 5: Kontrola uprawnień

Przejrzyj role i granty w instancjach, które były narażone. Szukaj ról z uprawnieniami wyższymi, niż wynika to z ich funkcji. To działanie niezależne od łatki, ale przy eskalacji uprawnień konieczne.

Typowe błędy przy reakcji na tę podatność

• Aktualizacja tylko bazy domyślnej. Rozszerzenie może być zainstalowane w kilku bazach tej samej instancji.
• Pominięcie środowisk nieprodukcyjnych. Staging z kopią danych produkcyjnych jest tak samo istotny.
• Mylenie wersji PostgreSQL z wersją rozszerzenia. „Mamy PostgreSQL 16” nie mówi nic o wersji E-Maj.
• Brak weryfikacji po aktualizacji. Bez sprawdzenia extversion nie wiadomo, czy aktualizacja faktycznie się powiodła.
• Zakładanie, że usługa zarządzana aktualizuje rozszerzenia automatycznie. To trzeba potwierdzić u dostawcy, a nie przyjąć.
• Traktowanie braku CVE jako sygnału niskiego ryzyka. Ogłoszenie nie podaje identyfikatora, ale zaleca pilną aktualizację.

Działania krótkoterminowe

1. Zinwentaryzuj instancje i wersje E-Maj w ciągu jednego dnia roboczego.
2. Zaplanuj aktualizację do 5.0.1 na najbliższe okno serwisowe, zaczynając od środowiska testowego.
3. Ogranicz do minimum liczbę ról z dostępem do instancji objętych ryzykiem do czasu wdrożenia łatki.
4. Włącz lub sprawdź logowanie zdarzeń administracyjnych — zmian ról, grantów i instalacji rozszerzeń.
5. Powiadom właściciela usługi i, jeśli dotyczy, dostawcę zarządzanego PostgreSQL.

Działania długoterminowe

• Rejestr rozszerzeń. Utrzymuj wykaz rozszerzeń i ich wersji dla każdej instancji, aktualizowany przy każdym wdrożeniu.
• Polityka aktualizacji. Ustal, kto odpowiada za śledzenie ogłoszeń bezpieczeństwa PostgreSQL i rozszerzeń oraz w jakim terminie reakcja jest obowiązkowa.
• Zasada minimalnych uprawnień. Regularny przegląd ról i grantów, szczególnie w instancjach współdzielonych.
• Monitoring uprawnień. Alerty na nadanie uprawnień superusera i na zmiany w rolach.
• Testy zgodności. Przy każdej aktualizacji rozszerzenia sprawdzaj działanie klienta emaj_web i procesów, które zależą od E-Maj.

Checklista operacyjna

Punkt kontrolny	Status	Odpowiedzialny
Lista instancji PostgreSQL i baz	☐
Wersja E-Maj w każdej bazie	☐
Wersja emaj_web i zgodność z rozszerzeniem	☐
Aktualizacja środowiska testowego do 5.0.1	☐
Aktualizacja produkcji do 5.0.1	☐
Weryfikacja extversion po aktualizacji	☐
Przegląd ról z uprawnieniami superusera	☐
Potwierdzenie u dostawcy usługi zarządzanej	☐
Wpis w rejestrze inwentarza z datą	☐

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy lub osoba odpowiedzialna za systemy:

• Ustal, czy w organizacji w ogóle używa się E-Maj. Jeśli nie — problem nie dotyczy Twoich instancji, ale warto to potwierdzić zapisem, a nie pamięcią.
• Jeśli E-Maj jest używany, potraktuj aktualizację jako zadanie o wysokim priorytecie i wyznacz osobę odpowiedzialną z terminem.
• Zapytaj dostawcę usługi zarządzanej PostgreSQL, czy rozszerzenie jest zainstalowane i w jakiej wersji oraz kiedy zostanie zaktualizowane. Odpowiedź uzyskaj na piśmie.
• Upewnij się, że reakcja jest udokumentowana — data sprawdzenia, wynik, podjęte działania. To przydaje się przy audycie i przy kolejnych podatnościach.

Administrator bazy danych:

• Wykonaj inwentaryzację z sekcji „Jak sprawdzić”.
• Zaplanuj i przeprowadź aktualizację do 5.0.1, zaczynając od środowiska testowego.
• Po aktualizacji zweryfikuj wersję i działanie klienta emaj_web.
• Przejrzyj role i uprawnienia w instancjach, które były narażone.
• Uruchom lub sprawdź logowanie zmian administracyjnych.

Ograniczenia tej analizy

Materiał źródłowy nie zawiera identyfikatora CVE, opisu wektora ataku ani listy warunków koniecznych do wykorzystania luki. Nie wiadomo, czy wymagane jest konto w bazie, jakie uprawnienia musi mieć atakujący ani czy luka dotyczy konkretnych funkcji E-Maj. Nie wiadomo też, czy istnieją doniesienia o aktywnym wykorzystaniu. Wszystkie stwierdzenia o mechanizmie działania luki w tej analizie są oznaczone jako interpretacja i nie powinny być traktowane jako potwierdzony opis techniczny. Jednoznaczne i wystarczające do działania jest zalecenie producenta: zaktualizować do 5.0.1.

Weryfikacja praktyczna po wdrożeniu aktualizacji do 5.0.1

Weryfikacja to nie formalność. Bez niej nie wiadomo, czy aktualizacja objęła wszystkie bazy, czy klient emaj_web nadal działa i czy wersja widoczna w katalogu odpowiada temu, co zostało zainstalowane. Poniższe sekcje opisują wyłącznie czynności sprawdzające, które można wykonać natychmiast po wdrożeniu, oraz sposób dokumentowania wyników.

Weryfikacja wersji rozszerzenia w każdej bazie

Po aktualizacji wróć do zapytania o zainstalowane rozszerzenia i porównaj wynik z oczekiwaną wersją 5.0.1. Wykonaj to dla każdej bazy w każdej instancji, nie tylko dla bazy domyślnej — rozszerzenie może być zainstalowane tylko w części baz tego samego klastra.

• Uruchom zapytanie o extname i extversion z pg_extension i potwierdź, że wiersz emaj wskazuje 5.0.1.
• Powtórz sprawdzenie dla każdej bazy osobno i zanotuj wynik przy nazwie bazy, nie przy nazwie instancji.
• Jeśli w którejkolwiek bazie widnieje wersja niższa niż 5.0.1, traktuj to jako nieudaną aktualizację tej bazy i wróć do kroku aktualizacji.
• Zapisz datę i godzinę weryfikacji obok wyniku — bez znacznika czasu wpis w rejestrze traci wartość dowodową.

Weryfikacja klienta emaj_web

Producent podaje, że emaj_web 5.0 jest zgodny z rozszerzeniem w wersjach 3.0–5.0. Po aktualizacji rozszerzenia sprawdź, czy klient nadal komunikuje się z bazą i wykonuje swoje podstawowe operacje.

1. Zanotuj wersję klienta emaj_web używaną w organizacji.
2. Potwierdź, że wersja ta mieści się w zakresie zgodności podanym przez producenta dla rozszerzenia 5.0.1.
3. Wykonaj testowe połączenie klienta z bazą po aktualizacji i sprawdź, czy operacje zależne od E-Maj przebiegają bez błędów.
4. Zapisz wynik testu wraz z wersją klienta i wersją rozszerzenia w tym samym wpisie rejestru.

Weryfikacja środowisk nieprodukcyjnych

Środowiska testowe i staging często pozostają pominięte, a mają kopie danych produkcyjnych. Po aktualizacji produkcji wróć do listy instancji i baz i potwierdź, że żadne środowisko nie zostało pominięte.

• Porównaj listę baz objętych aktualizacją z pełną listą baz z inwentaryzacji.
• Dla każdej pozycji z listy odnotuj status: zaktualizowano do 5.0.1 albo wyłączone z eksploatacji z podaniem przyczyny.
• Nie zostawiaj pozycji bez statusu — brak wpisu jest traktowany jak brak działania.

Monitoring po wdrożeniu

Monitoring po wdrożeniu ma dwa cele: potwierdzić, że stan po aktualizacji się utrzymuje, oraz wychwycić sytuacje, które mogłyby świadczyć o próbie wykorzystania eskalacji uprawnień. Materiał źródłowy nie opisuje mechanizmu luki ani warunków jej wykorzystania, dlatego monitoring należy oprzeć na obserwacji uprawnień i zmian administracyjnych, a nie na sygnaturach technicznych.

Co obserwować w uprawnieniach

• Nadania uprawnień superusera — każde takie zdarzenie powinno być widoczne i możliwe do wyjaśnienia.
• Zmiany w rolach, w tym tworzenie nowych ról i modyfikacje istniejących.
• Zmiany grantów, szczególnie w instancjach współdzielonych przez wiele zespołów.
• Instalacje i aktualizacje rozszerzeń — każda zmiana wersji E-Maj powinna mieć odzwierciedlenie w rejestrze inwentarza.

Rejestr zdarzeń administracyjnych

Logowanie zdarzeń administracyjnych — zmian ról, grantów i instalacji rozszerzeń — jest wskazane jako działanie krótkoterminowe jeszcze przed pełnym wdrożeniem łatki. Po aktualizacji upewnij się, że logowanie działa i że zdarzenia są zapisywane.

1. Sprawdź, czy logowanie zmian administracyjnych jest włączone na instancjach objętych ryzykiem.
2. Wygeneruj kontrolnie jedno zdarzenie administracyjne w środowisku testowym i potwierdź, że zostało zapisane.
3. Ustal, kto przegląda zapisy i z jaką częstotliwością — sam zapis bez przeglądu nie daje wykrywalności.
4. Odnotuj w rejestrze inwentarza, że monitoring został uruchomiony, wraz z datą.

Przegląd ról po aktualizacji

Kontrola uprawnień jest działaniem niezależnym od łatki, ale przy eskalacji uprawnień koniecznym. Po aktualizacji przejrzyj role i granty w instancjach, które były narażone, i szukaj ról z uprawnieniami wyższymi, niż wynika to z ich funkcji.

• Wypisz role z uprawnieniami superusera i przypisz każdej uzasadnienie biznesowe.
• Oznacz role, których uprawnienia nie odpowiadają ich funkcji, i zaplanuj ich ograniczenie.
• Powtórz przegląd w instancjach współdzielonych częściej niż w tych z jedną rolą aplikacyjną.

Checklista weryfikacji po wdrożeniu

Poniższa lista uzupełnia checklistę operacyjną o punkty sprawdzające wykonywane po aktualizacji. Każdy punkt wymaga statusu i osoby odpowiedzialnej.

• Wersja 5.0.1 potwierdzona w każdej bazie każdej instancji — ☐
• Bazy z wersją niższą niż 5.0.1 zidentyfikowane i objęte ponowną aktualizacją — ☐
• Wersja emaj_web odnotowana i zgodna z zakresem 3.0–5.0 — ☐
• Test połączenia klienta emaj_web z bazą po aktualizacji wykonany — ☐
• Środowiska testowe i staging ujęte w weryfikacji — ☐
• Logowanie zdarzeń administracyjnych sprawdzone i potwierdzone — ☐
• Przegląd ról z uprawnieniami superusera wykonany — ☐
• Wyniki weryfikacji wpisane do rejestru inwentarza z datą — ☐
• Potwierdzenie od dostawcy usługi zarządzanej uzyskane na piśmie — ☐

Checklista utrzymania po aktualizacji

Utrzymanie to powtarzalne czynności, które zapobiegają powrotowi do stanu sprzed aktualizacji i pozwalają szybko reagować na kolejne ogłoszenia bezpieczeństwa.

1. Rejestr rozszerzeń aktualizowany przy każdym wdrożeniu, z wersją i datą dla każdej instancji i bazy.
2. Polityka aktualizacji określająca, kto śledzi ogłoszenia bezpieczeństwa PostgreSQL i rozszerzeń oraz w jakim terminie reakcja jest obowiązkowa.
3. Regularny przegląd ról i grantów, szczególnie w instancjach współdzielonych.
4. Alerty na nadanie uprawnień superusera i na zmiany w rolach.
5. Testy zgodności klienta emaj_web i procesów zależnych od E-Maj przy każdej aktualizacji rozszerzenia.
6. Potwierdzanie u dostawcy usługi zarządzanej, czy rozszerzenie jest zainstalowane, w jakiej wersji i kiedy zostanie zaktualizowane — z odpowiedzią na piśmie.

Dokumentowanie i dowody dla audytu

Reakcja na tę podatność powinna być udokumentowana: data sprawdzenia, wynik, podjęte działania. Materiał wskazuje, że przydaje się to przy audycie i przy kolejnych podatnościach. Poniżej zestawienie elementów, które warto gromadzić.

• Data i godzina sprawdzenia wersji E-Maj w każdej bazie wraz z wynikiem zapytania.
• Lista instancji i baz objętych aktualizacją oraz tych wyłączonych z eksploatacji z przyczyną.
• Wersja klienta emaj_web i wynik testu zgodności z rozszerzeniem.
• Zapis potwierdzenia od dostawcy usługi zarządzanej, jeśli organizacja z niego korzysta.
• Wynik przeglądu ról i grantów w instancjach, które były narażone.
• Potwierdzenie włączenia logowania zdarzeń administracyjnych.

Warto przy tym pamiętać o ograniczeniach materiału źródłowego: ogłoszenie nie podaje identyfikatora CVE, opisu wektora ataku ani listy warunków koniecznych do wykorzystania luki. Nie wiadomo, czy wymagane jest konto w bazie, jakie uprawnienia musi mieć atakujący ani czy luka dotyczy konkretnych funkcji E-Maj. Nie ma też doniesień o aktywnym wykorzystaniu — i równie dobrze nie ma podstaw, by twierdzić, że go nie ma. Jednoznaczne i wystarczające do działania pozostaje zalecenie producenta: zaktualizować do 5.0.1 i potwierdzić ten stan weryfikacją oraz monitoringiem.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. E-Maj 5.0.1 : Major Security Update. (www.postgresql.org)

Zdjęcie wyróżniające: panumas nikhomkhai / Pexels.