pgAdmin 4 v9.19: 15 CVE, command injection w Import/Export i pułapka SERVER_PASSEXEC_COMMANDS

pgAdmin Development Team wydał 31 października 2026 r. wersję pgAdmin 4 v9.19, która zawiera poprawki 15 podatności bezpieczeństwa oznaczonych jako CVE-2026-116238 do CVE-2026-116252 oraz 136 poprawek błędów i nowych funkcji. Wśród nich jest OS command injection w narzędziu Import/Export Data (CVE-2026-116241), który jest niepełną poprawką wcześniejszego CVE-2026-17566, a także błędy uwierzytelniania LDAP i Kerberos pozwalające zalogować się na inne konto o tej samej nazwie użytkownika, w tym na początkowe konto administratora (CVE-2026-116239).

Wydanie dotyczy przede wszystkim organizacji, które utrzymują pgAdmin w trybie serwerowym — czyli tam, gdzie wielu użytkowników korzysta z jednej instancji działającej pod wspólnym kontem usługi. W tym modelu pracy kilka z opisanych błędów pozwalało przejąć uprawnienia innego użytkownika albo wykorzystać poświadczenia konta usługi pgAdmin. Osobno ważna jest zmiana łamiąca kompatybilność: dowolne Password Exec Commands w trybie serwerowym zastąpiono allowlistą SERVER_PASSEXEC_COMMANDS, którą trzeba skonfigurować przed pierwszym startem po aktualizacji. Bez tego istniejące automatyzacje przestaną działać.

Co dokładnie zawiera wydanie

Oficjalne ogłoszenie wymienia 136 poprawek i nowych funkcji. Część z nich ma znaczenie operacyjne, część to zmiany funkcjonalne. Poniżej rozdzielam deklaracje producenta od wniosków, które wynikają z opisu samych mechanizmów.

Deklaracje producenta — podatności

Wszystkie 15 pozycji pochodzi z noty wydania. Producent opisuje mechanizm i skutek, nie publikuje natomiast w tym miejscu wektorów ataku ani kodu. Zestawienie:

CVE	Obszar	Opisany skutek
CVE-2026-116241	Import/Export Data	OS command injection; eksport oparty na zapytaniu mógł przemycić aktywną klauzulę TO PROGRAM obok zabezpieczenia nawiasów w copy przez backslash w dwucudzysłowowym identyfikatorze i uruchomić dowolną komendę na hoście pgAdmin. Niepełna poprawka CVE-2026-17566.
CVE-2026-116239	LDAP / Kerberos	Logowanie użytkownika na inne konto o tej samej nazwie, w tym na początkowe konto administratora.
CVE-2026-116238	Uwierzytelnianie	Obejście limitu nieudanych logowań oraz własnych kontroli logowania, zmiany hasła i resetu hasła pgAdmin — przez widoki Flask-Security oraz przez obsługę wielkości liter w nazwie użytkownika i drugiego źródła.
CVE-2026-116249	Ścieżki plików połączeń	Ścieżki plików połączeń i klucze parametrów wychodzące poza katalog użytkownika; możliwość połączenia się poświadczeniami lub kluczem innego użytkownika.
CVE-2026-116247	libpq / konto usługi	libpq korzystał z pliku haseł i certyfikatu klienta konta usługi pgAdmin w trybie serwerowym.
CVE-2026-116245	Connection services	Usługi połączeń w trybie serwerowym ograniczono do allowlisty SERVER_MODE_ALLOWED_SERVICES.
CVE-2026-116244	libpq / Kerberos	libpq używał poświadczeń Kerberos konta usługi pgAdmin w trybie serwerowym.
CVE-2026-116242	Tunele SSH	Tunele SSH używały tożsamości SSH konta usługi pgAdmin.
CVE-2026-116243	Guard ścieżki binariów	Guard ścieżki binariów akceptował ścieżkę w SHARED_STORAGE, co pozwalało użytkownikowi doprowadzić do wykonania przez pgAdmin pliku, który tam umieścił.
CVE-2026-116246	Środowisko procesu	Hasła serwerów pozostawały w środowisku procesu pgAdmin, gdzie mogła je odziedziczyć sesja innego użytkownika lub narzędzie pomocnicze.
CVE-2026-116248	Udostępnianie serwerów	Każdy użytkownik mogący zarejestrować serwer mógł udostępnić go wszystkim innym użytkownikom w trybie serwerowym.
CVE-2026-116240	File Manager	File Manager i narzędzia ścieżek działały na innej ścieżce niż ta, która została sprawdzona.
CVE-2026-116250	Wyścigi TOCTOU	Wyścigi typu time-of-check to time-of-use na symlinkach, hard-linkach i FIFO w File Manager, Import/Export Servers, Backup, Restore i Import/Export Data.
CVE-2026-116251	Sesje użytkownika	Inne sesje użytkownika przeżywały zmianę hasła lub reset wykonany przez administratora.
CVE-2026-116252	Odświeżanie widoku zmaterializowanego	Przekierowanie połączenia: spreparowana nazwa bazy była rozwijana przez libpq do pełnego connection stringa.

Deklaracje producenta — zmiany funkcjonalne

Poza poprawkami bezpieczeństwa wydanie wprowadza m.in.: węzeł Statistics do zarządzania statystykami rozszerzonymi, edycję danych przez proste widoki auto-updatable w View/Edit Data, zapis wyników Query Tool do JSON i XML obok CSV (z wyborem kodowania, opcjonalnym BOM i opcją kopiowania z nagłówkami), obsługę łańcuchów i zadań pg_timetable, pgEdge Starfleet w kreatorze Deploy Cloud Instance oraz pomijanie strony logowania, gdy OAuth2 jest jedynym źródłem uwierzytelniania.

Lista poprawek obejmuje też m.in. liczne problemy Schema Diff (konwersje SERIAL/BIGSERIAL, zmienione nazwy argumentów funkcji, powtarzane komentarze kolumn i opcje identity, fałszywe różnice po usunięciu kolumny w tabeli referencyjnej), obsługę kolumn generowanych w View/Edit Data, po cichu gubione uprawnienie MAINTAIN dla widoków i widoków zmaterializowanych na PostgreSQL 17 i nowszych, błędy logowania Kerberos zwracające JSON 500 oraz odrzucanie pierwszorazowych automatycznie tworzonych loginów Kerberos, zapis plików wczytanych jako latin-1 lub inne nie-UTF-8 z powrotem jako UTF-8 w Query Tool, a także zbędną kopię Pythona w pakietach linuksowych, która blokowała instalację pakietu DEB na Ubuntu 26.04.

Dostępne są buildy dla Windows i macOS, Python Wheel, kontener Docker, pakiety RPM i DEB oraz tarball źródeł.

Tło techniczne prostym językiem

pgAdmin to graficzne narzędzie do zarządzania PostgreSQL. Można je uruchomić jako aplikację desktopową na własnym komputerze albo w trybie serwerowym — jako usługę sieciową, do której loguje się wielu użytkowników przez przeglądarkę. W drugim modelu cała instancja działa pod jednym kontem systemowym, nazywanym kontem usługi pgAdmin. To konto ma dostęp do plików konfiguracyjnych, kluczy SSH, plików haseł libpq, biletów Kerberos i katalogów roboczych.

Granica bezpieczeństwa w trybie serwerowym powinna przebiegać między użytkownikami. Każdy użytkownik ma widzieć tylko swoje serwery, swoje pliki i swoje poświadczenia. Kilka z opisanych podatności dotyczy właśnie tej granicy: libpq sięgał po plik haseł i certyfikat konta usługi (CVE-2026-116247), po bilety Kerberos tego konta (CVE-2026-116244), tunele SSH korzystały z tożsamości SSH konta usługi (CVE-2026-116242), a hasła serwerów zostawały w środowisku procesu, skąd mogła je odziedziczyć sesja innego użytkownika (CVE-2026-116246). W każdym z tych przypadków skutek jest podobny: użytkownik o niskich uprawnieniach może uzyskać dostęp do zasobów, które powinny być poza jego zasięgiem.

Command injection w Import/Export Data (CVE-2026-116241) działa na innej zasadzie. Narzędzie buduje polecenie copy na podstawie zapytania użytkownika. Poprawka CVE-2026-17566 miała blokować wstrzyknięcie klauzuli TO PROGRAM, która w psql pozwala uruchomić dowolny program systemowy. Według opisu producenta obejście polegało na użyciu backslashu w dwucudzysłowowym identyfikatorze, co pozwalało przemycić aktywną klauzulę obok zabezpieczenia nawiasów. Skutek: dowolna komenda wykonywana na hoście pgAdmin. To najpoważniejsza pozycja na liście, bo nie wymaga przejęcia konta administratora — wystarczy dostęp do narzędzia Import/Export.

Osobna grupa to błędy uwierzytelniania. CVE-2026-116239 opisuje sytuację, w której LDAP lub Kerberos logował użytkownika na inne konto o tej samej nazwie — w tym na początkowe konto administratora. CVE-2026-116238 pozwalał obejść limit nieudanych logowań oraz kontrole logowania, zmiany hasła i resetu hasła. CVE-2026-116251 sprawiał, że inne sesje użytkownika przeżywały zmianę hasła lub reset przez administratora. Razem te trzy błędy osłabiają podstawowe mechanizmy reakcji na incydent: jeśli nie można skutecznie zablokować konta ani unieważnić sesji, procedura „zmień hasło i wyloguj wszędzie” przestaje działać.

Realne konsekwencje dla organizacji

Skala ryzyka zależy od modelu wdrożenia. Aplikacja desktopowa na pojedynczym komputerze ma zupełnie inny profil zagrożeń niż współdzielona instancja serwerowa z wieloma użytkownikami i zintegrowanym uwierzytelnianiem katalogowym. Poniższa tabela porządkuje priorytety.

Obszar	Kto jest narażony	Dlaczego to ważne
Command injection (CVE-2026-116241)	Każda instancja z dostępem do Import/Export Data	Wykonanie dowolnej komendy na hoście pgAdmin; niepełna poprzednia poprawka oznacza, że wcześniejsze obejścia mogły nie wystarczyć.
LDAP/Kerberos (CVE-2026-116239)	Instancje z LDAP lub Kerberos	Możliwe zalogowanie na cudze konto, w tym początkowe konto administratora.
Uwierzytelnianie i sesje (CVE-2026-116238, CVE-2026-116251)	Wszystkie instancje serwerowe	Obejście limitów logowań i przetrwanie sesji po resecie hasła utrudniają reagowanie na incydent.
Poświadczenia konta usługi (CVE-2026-116242, CVE-2026-116244, CVE-2026-116247)	Instancje serwerowe	Użytkownik może użyć kluczy SSH, biletów Kerberos lub plików haseł konta usługi.
Środowisko procesu (CVE-2026-116246)	Instancje serwerowe	Hasła serwerów mogły wyciec do sesji innego użytkownika lub narzędzia.
Ścieżki i pliki (CVE-2026-116240, CVE-2026-116243, CVE-2026-116249, CVE-2026-116250)	Instancje z File Manager, Backup, Restore, Import/Export	Wyścigi TOCTOU i obejścia guardów pozwalały działać na innej ścieżce niż sprawdzona.
Udostępnianie serwerów (CVE-2026-116248)	Instancje serwerowe z rejestracją serwerów przez użytkowników	Jeden użytkownik mógł udostępnić serwer wszystkim.
Przekierowanie połączenia (CVE-2026-116252)	Instancje z widokami zmaterializowanymi	Spreparowana nazwa bazy rozwijana przez libpq do pełnego connection stringa.

Interpretacja: największe znaczenie mają CVE-2026-116241 i CVE-2026-116239, ponieważ pierwsze pozwala na wykonanie kodu, a drugie na przejęcie konta administracyjnego. Grupa związana z kontem usługi jest groźna wtedy, gdy konto usługi ma szerokie uprawnienia — na przykład może łączyć się z wieloma serwerami bazodanowymi lub ma klucze SSH do innych hostów. To nie jest ustalenie producenta, tylko wniosek z opisu mechanizmów.

Scenariusze ryzyka

Scenariusz 1: użytkownik z dostępem do Import/Export

Osoba z kontem w pgAdmin, ale bez uprawnień administracyjnych, korzysta z Import/Export Data. Jeśli wersja jest starsza niż 9.19, według opisu producenta może doprowadzić do wykonania dowolnej komendy na hoście pgAdmin. Konsekwencje zależą od uprawnień konta usługi: od odczytu plików po dalsze ruchy w sieci. To scenariusz, który powinien być traktowany jako priorytetowy, bo nie wymaga przejęcia konta administratora.

Scenariusz 2: kolizja nazw użytkowników w LDAP lub Kerberos

W środowisku z LDAP lub Kerberos dwie osoby mogą mieć tę samą nazwę użytkownika w różnych źródłach lub różnej wielkości liter. Według opisu CVE-2026-116239 pgAdmin mógł zalogować jedną z nich na konto drugiej, w tym na początkowe konto administratora. To ryzyko dotyczy organizacji, które korzystają z więcej niż jednego źródła tożsamości albo mają historię kont o zbliżonych nazwach.

Scenariusz 3: przejęcie poświadczeń konta usługi

Jeśli użytkownik może wpłynąć na parametry połączenia, narzędzia pomocnicze lub pliki w katalogu roboczym, w starszych wersjach mógł według producenta doprowadzić do użycia przez libpq pliku haseł, certyfikatu, biletów Kerberos lub tożsamości SSH konta usługi. Skutek zależy od tego, do czego to konto ma dostęp. W typowym wdrożeniu serwerowym konto usługi ma dostęp do konfiguracji i może łączyć się z bazami — to wystarcza, by eskalować uprawnienia.

Scenariusz 4: incydent w trakcie reakcji

Zespół wykrywa podejrzaną aktywność, resetuje hasło i liczy na unieważnienie sesji. Według opisu CVE-2026-116251 inne sesje użytkownika przeżywały zmianę hasła lub reset przez administratora, a CVE-2026-116238 pozwalał obejść limit nieudanych logowań. To oznacza, że standardowa procedura reakcji mogła nie zadziałać zgodnie z oczekiwaniem.

Jak sprawdzić, czy problem dotyczy Twojej instancji

1. Ustal wersję. Sprawdź numer wersji pgAdmin w interfejsie lub w metadanych wdrożenia (kontener, pakiet, wheel). Wszystko poniżej 9.19 jest według producenta narażone na co najmniej część opisanych błędów.
2. Ustal tryb pracy. Sprawdź, czy instancja działa w trybie serwerowym, czy desktopowym. Większość pozycji z listy dotyczy trybu serwerowego; command injection w Import/Export dotyczy narzędzia jako takiego.
3. Sprawdź źródła uwierzytelniania. Jeśli używasz LDAP lub Kerberos, przejrzyj konta o tej samej nazwie użytkownika lub różniące się tylko wielkością liter. Sprawdź, czy początkowe konto administratora ma odpowiednik w katalogu.
4. Sprawdź konfigurację Password Exec Commands. Jeśli w trybie serwerowym korzystasz z dowolnych komend haseł, zapisz ich listę przed aktualizacją — po aktualizacji będą działać tylko wpisy z allowlisty.
5. Sprawdź connection services. Jeśli używasz usług połączeń, zanotuj, które są potrzebne. Po aktualizacji będą ograniczone do SERVER_MODE_ALLOWED_SERVICES.
6. Sprawdź, czy konto usługi ma szerokie uprawnienia. Przejrzyj pliki haseł libpq, klucze SSH, konfigurację Kerberos i uprawnienia sieciowe konta, pod którym działa pgAdmin.
7. Sprawdź logi. Poszukaj nietypowych logowań, prób przekroczenia limitu nieudanych logowań, operacji Import/Export i odświeżeń widoków zmaterializowanych w okresie przed aktualizacją.

Plan reakcji krok po kroku

Krótkoterminowo (przed aktualizacją)

1. Zinwentaryzuj instancje pgAdmin w organizacji — także te uruchomione lokalnie przez administratorów baz danych, kontenery deweloperskie i instalacje w chmurze.
2. Zapisz aktualne ustawienia Password Exec Commands i connection services. To warunek konieczny, by po aktualizacji odtworzyć działające automatyzacje.
3. Ogranicz dostęp do Import/Export Data i File Manager do osób, które realnie z nich korzystają. To działanie osłonowe, nie zastępuje aktualizacji.
4. Przejrzyj konta LDAP i Kerberos pod kątem kolizji nazw. Jeśli to możliwe, czasowo ogranicz logowanie przez te źródła do zweryfikowanych kont.
5. Zabezpiecz konto usługi pgAdmin: minimalne uprawnienia, osobne pliki haseł, brak zbędnych kluczy SSH i biletów Kerberos.

W trakcie aktualizacji

1. Zatrzymaj instancję i wykonaj kopię zapasową konfiguracji oraz katalogu danych pgAdmin.
2. Przygotuj konfigurację SERVER_PASSEXEC_COMMANDS i SERVER_MODE_ALLOWED_SERVICES przed pierwszym startem nowej wersji. Producent wprost wskazuje, że allowlistę Password Exec Commands trzeba skonfigurować przed pierwszym uruchomieniem po aktualizacji.
3. Wdróż nową wersję z oficjalnego źródła: Windows, macOS, Python Wheel, Docker, RPM, DEB lub tarball źródeł. Upewnij się, że pobierasz build 9.19, a nie starszy.
4. Uruchom instancję i sprawdź logi pod kątem błędów konfiguracji allowlisty.

Po aktualizacji

1. Przetestuj logowanie przez wszystkie skonfigurowane źródła: lokalne, LDAP, Kerberos, OAuth2.
2. Przetestuj Import/Export Data, Backup, Restore, File Manager i tunele SSH na wybranych, nieprodukcyjnych serwerach.
3. Sprawdź, czy Password Exec Commands i connection services działają zgodnie z nową allowlistą.
4. Zweryfikuj, że zmiana hasła i reset przez administratora unieważniają inne sesje użytkownika.
5. Przejrzyj logi po aktualizacji i porównaj z okresem przed nią.

Typowe błędy

• Aktualizacja bez przygotowania allowlisty. Najczęstszy błąd: zespół aktualizuje pgAdmin, a po restarcie okazuje się, że automatyzacje haseł nie działają, bo SERVER_PASSEXEC_COMMANDS nie zostało ustawione przed pierwszym startem.
• Traktowanie poprawki CVE-2026-17566 jako wystarczającej. CVE-2026-116241 jest opisany jako niepełna poprawka wcześniejszego błędu. Wdrożenia, które opierały się na obejściach zamiast na aktualizacji, mogły nie być chronione.
• Pomijanie instancji desktopowych i kontenerów deweloperskich. Inwentaryzacja często obejmuje tylko produkcję, a pomija lokalne instalacje administratorów.
• Zbyt szerokie uprawnienia konta usługi. Nawet po aktualizacji konto usługi z nadmiarowymi kluczami SSH i plikami haseł pozostaje atrakcyjnym celem.
• Brak weryfikacji LDAP/Kerberos po aktualizacji. Kolizje nazw użytkowników mogą pozostać w konfiguracji katalogu, nawet jeśli pgAdmin je poprawia.
• Przekonanie, że reset hasła wystarczy. Przed aktualizacją inne sesje mogły przetrwać reset; po aktualizacji warto to zweryfikować, a nie zakładać.
• Ignorowanie błędów Schema Diff i MAINTAIN. To nie podatności, ale poprawki mogą zmienić wyniki porównań schematów i uprawnienia widoków — warto je uwzględnić w testach regresji.

Działania długoterminowe

• Wprowadź politykę aktualizacji pgAdmin z określonym oknem wdrożenia dla wydań bezpieczeństwa.
• Utrzymuj inwentarz instancji pgAdmin wraz z trybem pracy, źródłami uwierzytelniania i właścicielami.
• Stosuj zasadę minimalnych uprawnień do konta usługi pgAdmin i regularnie przeglądaj jego pliki haseł, klucze SSH i konfigurację Kerberos.
• Utrzymuj allowlisty SERVER_PASSEXEC_COMMANDS i SERVER_MODE_ALLOWED_SERVICES jako element konfiguracji zarządzanej, a nie ręcznie edytowany plik.
• Testuj procedurę reakcji na incydent: czy reset hasła i unieważnienie sesji działają zgodnie z oczekiwaniem.
• Monitoruj logi pod kątem nietypowych operacji Import/Export, odświeżeń widoków zmaterializowanych i prób logowania przez wiele źródeł.

Praktyczna checklista

• ☐ Znam numer wersji każdej instancji pgAdmin w organizacji.
• ☐ Wiem, które instancje działają w trybie serwerowym.
• ☐ Zapisałem aktualne Password Exec Commands i connection services.
• ☐ Przygotowałem SERVER_PASSEXEC_COMMANDS przed pierwszym startem po aktualizacji.
• ☐ Przygotowałem SERVER_MODE_ALLOWED_SERVICES przed pierwszym startem po aktualizacji.
• ☐ Sprawdziłem kolizje nazw użytkowników w LDAP i Kerberos.
• ☐ Ograniczyłem uprawnienia konta usługi pgAdmin.
• ☐ Wykonałem kopię zapasową konfiguracji przed aktualizacją.
• ☐ Przetestowałem logowanie przez wszystkie źródła po aktualizacji.
• ☐ Przetestowałem Import/Export, Backup, Restore, File Manager i tunele SSH.
• ☐ Zweryfikowałem, że reset hasła unieważnia inne sesje.
• ☐ Przejrzałem logi przed i po aktualizacji.

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

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

• Potwierdzić, kto w organizacji odpowiada za pgAdmin i czy inwentarz obejmuje wszystkie instancje.
• Zatwierdzić okno wdrożenia 9.19 z uwzględnieniem czasu na przygotowanie allowlist przed pierwszym startem.
• Upewnić się, że zespół rozumie różnicę między poprawką CVE-2026-17566 a CVE-2026-116241 — wcześniejsze obejścia nie zastępują aktualizacji.
• Zlecić przegląd uprawnień konta usługi pgAdmin i ograniczenie go do niezbędnego minimum.
• Wymagać raportu z testów po aktualizacji: logowanie, Import/Export, Backup, Restore, File Manager, tunele SSH, reset hasła.

Administrator powinien:

• Wykonać kroki z planu reakcji w kolejności: inwentaryzacja, zapis konfiguracji, kopia zapasowa, przygotowanie allowlist, aktualizacja, testy, przegląd logów.
• Nie uruchamiać nowej wersji bez przygotowanej konfiguracji SERVER_PASSEXEC_COMMANDS.
• Sprawdzić, czy w środowisku występują kolizje nazw użytkowników LDAP/Kerberos, i odpowiednio skorygować mapowania.
• Po aktualizacji zweryfikować, że zmiana hasła i reset przez administratora unieważniają inne sesje.
• Utrzymywać allowlisty jako element zarządzanej konfiguracji i dokumentować każdą zmianę.

Podsumowanie

pgAdmin 4 v9.19 to wydanie bezpieczeństwa o szerokim zakresie: 15 CVE, w tym command injection w Import/Export Data i błędy uwierzytelniania LDAP/Kerberos, a także zmiana łamiąca kompatybilność w postaci allowlisty SERVER_PASSEXEC_COMMANDS. Dla organizacji z trybem serwerowym priorytetem jest aktualizacja połączona z przygotowaniem konfiguracji przed pierwszym startem oraz przeglądem uprawnień konta usługi. Dla organizacji z LDAP lub Kerberos dodatkowym krokiem jest weryfikacja kolizji nazw użytkowników. Fakty w tym artykule pochodzą z oficjalnego ogłoszenia wydania; wnioski dotyczące priorytetów i scenariuszy ryzyka są interpretacją opartą na opisanych mechanizmach.

Ź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. pgAdmin 4 v9.19 Released (www.postgresql.org)

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