Podatności pgAdmin 4

pgAdmin 4 przed wersją 9.19 zawiera obejście poprawki CVE-2026-17566 w narzędziu Import/Export Data. Nieprawidłowa walidacja ukośnika w podwójnie cytowanym identyfikatorze pozwala ukryć nawias zamykający i wykonać klauzulę TO PROGRAM przez psql na hoście pgAdmin z uprawnieniami konta systemowego.

W pgAdmin 4 źródło uwierzytelniania 'webserver' miało podatność polegającą na tym, że funkcja WebserverAuthentication.get_user() w przypadku braku wartości w środowisku WSGI/CGI odczytywała nazwę użytkownika bezpośrednio z nagłówków HTTP przesyłanych przez klienta. W efekcie każdy klient mogący połączyć się z pgAdmin mógł podać własny nagłówek i zalogować się jako dowolny użytkownik, w tym istniejący Administrator, bez hasła. Problem dotyczy wersji od 6.2 do 9.18 i występuje tylko gdy w AUTHENTICATION_SOURCES włączone jest 'webserver'.

Podatność w pgAdmin 4 umożliwia zdalne wykonanie kodu (RCE) poprzez wstrzyknięcie polecenia do narzędzia Import/Export Data. Funkcja walidująca zapytania SQL błędnie interpretuje znaki backslasha w ciągach znaków, co pozwala na ominięcie zabezpieczeń i dodanie klauzuli TO PROGRAM do polecenia psql.

Podatność w pgAdmin 4 (wersje 9.13 do 9.16) pozwala na ominięcie zabezpieczenia CVE-2026-12045 poprzez wstrzyknięcie zapytania SQL do asystenta AI. Atakujący może umieścić złośliwy ładunek w obiekcie odczytywanym przez asystenta, co prowadzi do wykonania wielu instrukcji SQL, w tym zapisu lub zdalnego wykonania kodu.

W funkcji adhoc_connect_server w pgAdmin 4 9.0-9.16, podczas klonowania serwera przez niebędącego właścicielem użytkownika, kopiowane są wszystkie kolumny, w tym dane uwierzytelniające (hasła) oraz flagi własności. Pozwala to atakującemu na przejęcie sklonowanego serwera i korzystanie z haseł bazy danych należących do innego użytkownika (np. administratora).

W pgAdmin 4 w wersjach od 6.0 do 9.15 wykryto podatność na trwałe ataki XSS. Tekst zwracany przez serwer PostgreSQL (np. nazwy obiektów w błędach czy pola EXPLAIN) był przekazywany bezpośrednio do html-react-parser, co pozwalało na wstrzyknięcie dowolnego HTML, w tym ramek iframe. Atakujący może kontrolować serwer lub stworzyć obiekt o złośliwej nazwie, co prowadzi do przejęcia sesji użytkownika pgAdmin.

W pgAdmin 4 w wersjach od 6.9 do 9.15 brakuje dekoratora uwierzytelniania na dwóch endpointach SQL Editor, co pozwala nieuwierzytelnionym atakującym na wywołanie deserializacji pickle z sesji serwera. Luka wymaga jednak dodatkowych warunków (znajomość SECRET_KEY i dostęp do katalogu sesji), aby doprowadzić do zdalnego wykonania kodu.

Podatność w asystencie AI pgAdmin 4 umożliwia atakującemu, który może wpływać na treść odczytywaną przez asystenta, wykonanie dowolnego SQL z uprawnieniami roli użytkownika pgAdmin. Luka wynika z braku walidacji zapytań generowanych przez LLM, co pozwala na ominięcie trybu tylko do odczytu poprzez wstrzyknięcie poleceń takich jak COMMIT czy ROLLBACK.

W trybie serwera pgAdmin 4 wiele punktów końcowych pobierało obiekty należące do użytkownika bez filtrowania po tożsamości żądającego, co pozwalało uwierzytelnionemu użytkownikowi na dostęp do prywatnych serwerów, grup serwerów, procesów w tle i argumentów debuggera innych użytkowników poprzez zgadywanie identyfikatorów. Funkcja Shared Servers miała dodatkowe problemy, w tym wyciek poświadczeń, eskalację uprawnień przez zapisywalne passexec_cmd umożliwiające wykonanie dowolnych poleceń oraz uszkodzenie danych właściciela.

pgAdmin do wersji 9.10 jest podatny na zdalne wykonanie kodu (RCE) podczas pracy w trybie serwera i wykonywania przywracania z plików zrzutu w formacie PLAIN. Podatność pozwala atakującemu na wstrzyknięcie i wykonanie dowolnych poleceń na serwerze hostującym pgAdmin.

pgAdmin w wersjach do 9.9 jest podatny na zdalne wykonanie kodu (RCE) podczas przywracania baz danych z plików dump w formacie PLAIN, gdy działa w trybie serwera. Atakujący może wstrzyknąć i wykonać dowolne polecenia na serwerze hostującym pgAdmin.

W pgAdmin 4 odświeżanie widoku zmaterializowanego przekazywało nazwę bazy danych do argumentu --dbname programu psql bez zmian. libpq traktuje wartość zawierającą "=" lub URI postgresql:// jako pełny ciąg połączenia, co pozwalało przekierować połączenie na wybrany host i port oraz ujawnić zapisane hasło serwera.

W pgAdmin 4 zmiana hasła użytkownika (przez niego samego lub administratora) nie unieważniała istniejących sesji. Sesja ustanowiona przed zmianą, np. na innym urządzeniu lub przez osobę znającą stare hasło, pozostawała zalogowana aż do wygaśnięcia.

W trybie serwera pgAdmin 4 sprawdzał uprawnienia do pliku w katalogu przechowywania za pomocą check_access_permission(), a następnie otwierał plik po nazwie zwykłym open() lub przekazywał ścieżkę narzędziom (pg_dump, pg_dumpall, pg_restore, psql) oraz funkcjom eksportu/importu servers.json. Podmiana dowiązania symbolicznego lub twardego albo FIFO między sprawdzeniem a otwarciem pozwalała wyjść poza katalog przechowywania i zapisać, nadpisać lub odczytać plik, albo załadować go do tabeli, z uprawnieniami konta systemowego pgAdmin. Luka dotyczy wersji pgAdmin 4 przed 9.19.

W trybie serwera pgAdmin 4 przed wersją 9.19 funkcja get_complete_file_path() usuwała tylko wiodące ukośniki przed połączeniem ścieżki, więc ścieżka typu ../<inny użytkownik>/.pgpass mogła wskazać plik innego użytkownika. Parametr sslkeylogfile był przekazywany do libpq bez zmian, a make_conninfo() nie cytowało nazw parametrów, co pozwalało przemycić dodatkowe pary klucz=wartość.

W pgAdmin 4 w trybie serwera punkty końcowe API serwera przechowywały flagę "shared" i nazwę użytkownika, pozwalając każdemu użytkownikowi mogącemu zarejestrować serwer na udostępnienie go wszystkim. Import servers.json miał podobną lukę, ponieważ wpisy "Shared" nieadministratora usuwano dopiero po walidacji.

W pgAdmin 4 przed wersją 9.19, gdy serwer nie miał skonfigurowanego pliku haseł, certyfikatu klienta lub klucza klienta albo wskazany plik nie istniał, pgAdmin pomijał parametr w połączeniu, a libpq używał domyślnych plików konta systemowego uruchamiającego pgAdmin. W trybie serwera każdy użytkownik mógł więc łączyć się z serwerem przy użyciu zapisanych haseł lub certyfikatu konta usługi.

W pgAdmin 4 hasło serwera było zapisywane w środowisku procesu pgAdmin (jako PGPASSWORD dla narzędzia PSQL oraz pod zmienną per-proces dla narzędzia) i nigdy nie usuwane. W trybie serwera środowisko jest współdzielone przez żądania wszystkich użytkowników i kopiowane do uruchamianych procesów, więc inny użytkownik mógł odziedziczyć hasło i użyć go do połączenia.

W pgAdmin 4 w trybie serwera libpq wyszukuje usługi połączeń w pliku usług konta systemowego, co pozwala użytkownikom na użycie poświadczeń lub plików certyfikatów tego konta. Podatność dotyczy wersji przed 9.19 i może prowadzić do nieautoryzowanego dostępu do serwerów baz danych.

W pgAdmin 4 w trybie serwera usunięcie KRB5CCNAME powodowało, że biblioteka Kerberos używała domyślnego cache poświadczeń konta systemowego, umożliwiając każdemu użytkownikowi połączenie jako principal usługi. Podatność dotyczy wersji przed 9.19 i obejmuje również obejście gssencmode=disable oraz zachowanie SSPI w Windows.

W pgAdmin 4 w trybie serwera ścieżka binarna ustawiona przez użytkownika nie była weryfikowana względem katalogów SHARED_STORAGE, co pozwalało na przesłanie pliku wykonywalnego i uruchomienie go jako konto systemowe pgAdmin. Podatność jest szczególnie istotna w Windows, gdzie pliki mogą być wykonywalne, i dotyczy wersji przed 9.19.

W pgAdmin 4 w trybie serwera biblioteka sshtunnel zawsze ładowała niezaszyfrowane klucze prywatne z ~/.ssh konta systemowego i czytała jego konfigurację SSH, umożliwiając każdemu użytkownikowi skonfigurowanie tunelu z użyciem tożsamości konta usługi. Podatność dotyczy wersji przed 9.19.

W trybie serwera pgAdmin 4 występuje luka w walidacji ścieżek: funkcja check_access_permission() sprawdzała jedną ścieżkę, a wywołujący używali innej, co pozwalało na odczyt, zapis, usuwanie lub przenoszenie plików poza katalogiem przechowywania użytkownika. Dodatkowo podwójne dekodowanie ścieżek folderów i brak separatora przy łączeniu ścieżek umożliwiały dostęp do katalogów innych użytkowników lub całego systemu. Podatność dotyczy wersji pgAdmin 4 przed 9.19 i nie występuje w trybie desktop.

W trybie serwera pgAdmin 4 prowadzi osobne konta dla każdego źródła uwierzytelniania, więc ta sama nazwa użytkownika może istnieć jako konto wewnętrzne i LDAP. Po uwierzytelnieniu przez LDAP lub Kerberos pgAdmin wybierał konto do zalogowania wyłącznie na podstawie nazwy użytkownika, bez sprawdzenia źródła uwierzytelnienia, co pozwalało na przejęcie sesji innego konta wraz z jego rolami, serwerami i zapisanymi hasłami do baz danych.

W trybie serwerowym pgAdmin 4 mechanizm blokady konta wewnętrznego po przekroczeniu limitu nieudanych logowań (domyślnie 3) można obejść na kilka sposobów. Luki w widokach Flask-Security, w dopasowywaniu nazwy użytkownika (wielkość liter) oraz w interakcji z innymi źródłami uwierzytelniania (LDAP, webserver, Kerberos) pozwalają nieuwierzytelnionemu atakującemu na nieograniczone zgadywanie haseł do dowolnego konta wewnętrznego, w tym administratora. Dodatkowo możliwe są nieautoryzowane resetowania haseł i ujawnienie konfiguracji serwera w oknie About.

W narzędziu Backup w pgAdmin 4 nazwa bazy danych pochodząca z żądania była przekazywana do pg_dump jako pozycyjny argument bez walidacji. Ponieważ pg_dump używa getopt_long z permutacją argumentów, wartość zaczynająca się od myślnika (np. --file=/ścieżka) była interpretowana jako opcja, co pozwalało nadpisać wcześniej ustawiony parametr --file i zapisywać pliki poza katalogiem File Manager. To samo pole umożliwiało również wstrzyknięcie ciągu połączenia, przekierowując pg_dump na serwer atakującego wraz z hasłem bazy z zmiennej PGPASSWORD.

Podatność w pgAdmin 4 dotyczy narzędzi Restore i Maintenance, które przekazują pole 'database' bezpośrednio jako argument --dbname do pg_restore i psql. Wartość zawierająca znak równości jest rozwijana przez libpq do pełnego ciągu połączenia, co pozwala na przekierowanie połączenia na serwer wybrany przez atakującego. W wyniku tego może dojść do ujawnienia odszyfrowanego hasła bazy danych oraz możliwości nawiązywania połączeń wychodzących z hosta pgAdmin do dowolnych adresów sieciowych.

W pgAdmin 4 endpoint save_file w File Managerze sprawdzał uprawnienia do ścieżki za pomocą Filemanager.check_access_permission(), a następnie otwierał plik do zapisu zwykłym wywołaniem open(), bez flagi O_NOFOLLOW. W efekcie, jeśli w oknie czasowym między sprawdzeniem a zapisem podmieniono ostatni element ścieżki na dowiązanie symboliczne, zapis podążał za tym dowiązaniem i mógł utworzyć lub nadpisać dowolny plik z uprawnieniami konta systemowego pgAdmin. Luka dotyczy wersji pgAdmin 4 od wprowadzenia sprawdzania zawartości w ścieżce zapisu File Managera do wersji 9.18.

W systemie uprawnień opartych na rolach w pgAdmin 4 (wersje 9.3-9.17) brakowało spójnego egzekwowania uprawnień dla narzędzi. Dekorator permissions_required był stosowany tylko do głównej trasy każdego narzędzia, podczas gdy pozostałe trasy backendowe i procedury obsługi Socket.IO sprawdzały jedynie uwierzytelnienie, a nie konkretne uprawnienie do narzędzia. Umożliwiło to uwierzytelnionemu użytkownikowi bez wymaganego uprawnienia pełne korzystanie z narzędzia (np. psql, backup, restore) poprzez alternatywne ścieżki.

pgAdmin 4 w trybie SERVER ma podatność polegającą na braku wymaganego uwierzytelnienia dla niektórych tras. Niezautoryzowany klient sieciowy może wyliczać metadane ograniczeń, usuwać ograniczenia tabel, odczytywać wartości preferencji oraz wymuszać zamykanie sesji debuggera lub porównywania schematów należących do innych użytkowników.

W pgAdmin 4 od wersji 7.2 do 9.17, ustawienie MASTER_PASSWORD_HOOK pozwalało na wstrzyknięcie poleceń powłoki przez nazwę użytkownika zawierającą znaki specjalne (np. ';', '$()', backticks). Nazwa użytkownika pochodząca z zewnętrznych źródeł autoryzacji (OAuth, Kerberos) mogła być wykorzystana do wykonania dowolnych poleceń jako konto usługi pgAdmin.

Podatność w pgAdmin 4 pozwala na wstrzyknięcie SQL przez niepoprawne escapowanie nazw obiektów w szablonach zapytań. Niskouprzywilejowany użytkownik może utworzyć obiekt z apostrofem w nazwie, co po otwarciu zakładki Statystyki lub Zależności przez innego użytkownika prowadzi do wykonania dowolnego polecenia SQL w sesji bazy danych.

Podatność SQL injection w pgAdmin 4 w punkcie końcowym nazwanego punktu przywracania (POST /browser/server/restore_point/{gid}/{sid}). Wartość dostarczona przez użytkownika w polu 'value' była bezpośrednio interpolowana do zapytania SQL za pomocą str.format() zamiast przekazana jako parametr związany, co pozwalało uwierzytelnionemu użytkownikowi pgAdmin z aktywną sesją PostgreSQL na wstrzyknięcie dodatkowych instrukcji przez ten punkt końcowy.

Podatność typu open redirect w mechanizmie uwierzytelniania wieloskładnikowego (MFA) pgAdmin 4. Punkty końcowe walidacji i rejestracji MFA honorowały dostarczony przez użytkownika parametr 'next' bez weryfikacji, czy cel wskazuje z powrotem na pgAdmin, co umożliwiało przekierowanie uwierzytelnionego użytkownika na zewnętrzną, złośliwą stronę.

Podatność HTML injection w module chmurowym pgAdmin 4 umożliwia wstrzyknięcie kodu HTML przez sfałszowane dane uwierzytelniające. Błąd występuje w punktach końcowych /rds/, /azure/, /google/ oraz /cloud/, gdzie komunikaty błędów z SDK AWS/Azure/Google są zwracane w JSON bez kodowania HTML, a następnie renderowane przez frontend Cloud Wizard. Uwierzytelniony użytkownik może wstrzyknąć złośliwy iframe, który przekierowuje ofiarę na zewnętrzną stronę.

Podatność SQL injection w pgAdmin 4 występuje w szesnastu szablonach Jinja, gdzie opis użytkownika jest bezpośrednio wstawiany do literału SQL bez odpowiedniego escapowania. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania obiektów (domeny, tabele zewnętrzne, języki, wyzwalacze zdarzeń) może wstrzyknąć dowolne polecenia SQL, a w przypadku roli z uprawnieniami superużytkownika PostgreSQL doprowadzić do wykonania poleceń systemu operacyjnego.

W pgAdmin 4 limit MAX_LOGIN_ATTEMPTS jest egzekwowany tylko w widoku /authenticate/login. Domyślny widok /login Flask-Security nie sprawdza pola locked, co pozwala obejść blokadę konta i przeprowadzać nieograniczone zgadywanie hasła dla kont INTERNAL.

W pgAdmin 4 File Manager występuje podatność na atak typu traversal ścieżki z wykorzystaniem dowiązań symbolicznych. Użytkownik z autoryzacją może stworzyć dowiązanie symboliczne w swoim katalogu, które wskazuje na zewnętrzny zasób, co pozwala na zapis danych w dowolnej lokalizacji dostępnej dla procesu pgAdmin.

W pgAdmin 4 FileBackedSessionManager występuje podatność na deserializację niezaufanych danych, co może prowadzić do zdalnego wykonania kodu na poziomie systemu operacyjnego. Problem ten wynika z braku odpowiednich kontroli integralności przed deserializacją zawartości plików sesji.

W pgAdmin 4 endpointy konfiguracji LLM API pozwalają na lokalne włączenie plików (LFI) i server-side request forgery (SSRF). Uwierzytelniony użytkownik może odczytać dowolne pliki serwera przez api_key_file lub wymusić żądania do celów wewnętrznych przez api_url.

W pgAdmin 4 przed wersją 9.15 występuje podatność na wstrzykiwanie poleceń systemowych (CWE-78) w funkcji importu/eksportu zapytań. Użytkownik uwierzytelniony może wstrzyknąć złośliwe polecenia, co prowadzi do wykonania dowolnych komend na serwerze pgAdmin lub zapisu plików w dowolnej lokalizacji.

Podatność typu SQL injection w narzędziu pgAdmin 4 Maintenance Tool pozwala uwierzytelnionemu użytkownikowi z uprawnieniami tools_maintenance na wykonanie dowolnych poleceń SQL na serwerze PostgreSQL. Wykorzystanie tej luki może prowadzić do eskalacji uprawnień i wykonania poleceń systemowych na hoście bazy danych.

W pgAdmin 4 przed wersją 9.15 w modułach Browser Tree i Explain Visualizer występuje podatność przechowywanego XSS. Nazwy obiektów PostgreSQL kontrolowane przez użytkownika były przypisywane do elementów DOM przez innerHTML, co pozwalało na wykonanie złośliwego JavaScriptu w przeglądarce użytkownika pgAdmin.

pgAdmin w wersji 9.9 i wcześniejszych jest dotknięty podatnością w mechanizmie uwierzytelniania LDAP, która umożliwia obejście weryfikacji certyfikatu TLS.

pgAdmin w wersji <= 9.9 jest podatny na wstrzyknięcie LDAP w przepływie uwierzytelniania LDAP. Atakujący może wstrzyknąć specjalne znaki LDAP w nazwie użytkownika, powodując przetwarzanie nietypowej ilości danych przez serwer DC/LDAP i klienta, co prowadzi do ataku DoS.

pgAdmin 4 w wersjach do 9.9 jest podatny na wstrzyknięcie poleceń w systemach Windows. Problem wynika z użycia shell=True podczas operacji tworzenia kopii zapasowej i przywracania, co umożliwia atakującym wykonanie dowolnych poleceń systemowych poprzez podanie specjalnie spreparowanej ścieżki pliku.