CVE-2026-17566
KrytyczneCVSS 9.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 34 - wyżej niż 34% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący z uprawnieniami tools_import_export_data może wykonać dowolne polecenia systemowe na serwerze pgAdmin, co prowadzi do pełnego przejęcia kontroli nad aplikacją i potencjalnie nad bazą danych.
Rekomendacja
Należy natychmiast zaktualizować pgAdmin 4 do wersji 9.18 lub nowszej, która zawiera poprawkę odrzucającą zapytania z backslashem w ciągach znaków.
Inne podatności w pgAdmin 4
Zobacz wszystkie- CVE-2026-7819Wysokie
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.
- CVE-2026-7818Wysokie
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.
- CVE-2026-7816Wysokie
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.
- CVE-2026-7815Wysokie
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.
- CVE-2026-17351Krytyczne
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.
- CVE-2026-17349Krytyczne
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).
- CVE-2026-12048Krytyczne
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.
- CVE-2026-12046Krytyczne
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.
- CVE-2026-12045Krytyczne
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.
- CVE-2026-7813Krytyczne
Podatność autoryzacji w trybie serwera pgAdmin 4 umożliwia dostęp do prywatnych obiektów innych użytkowników bez odpowiedniego filtrowania. Użytkownik uwierzytelniony może uzyskać dostęp do prywatnych serwerów, grup serwerów oraz procesów w tle innych użytkowników poprzez odgadnięcie identyfikatorów obiektów.
Oryginalny opis (angielski, źródło NVD)
pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor). The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing. This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.