CVE-2026-12044
WysokieCVSS 8.8Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 53 - wyżej niż 53% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko polega na możliwości eskalacji uprawnień w bazie danych i potencjalnym przejęciu kontroli nad hostem PostgreSQL przez użytkownika z dostępem do pgAdmin. Atakujący może ominąć warstwę aplikacyjną i wykonać dowolne zapytania SQL, co zagraża poufności i integralności danych.
Rekomendacja
Należy niezwłocznie zaktualizować pgAdmin 4 do wersji 9.16 lub nowszej, która zawiera poprawki usuwające podatność. Dodatkowo warto ograniczyć uprawnienia użytkowników pgAdmin oraz monitorować logi pod kątem nietypowych zapytań SQL.
Inne podatności w pgAdmin 4
Zobacz wszystkie- CVE-2026-116241Krytyczne
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.
- CVE-2026-86863Krytyczne
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'.
- CVE-2026-17566Krytyczne
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.
- 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
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.
- CVE-2025-13780Krytyczne
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.
Oryginalny opis (angielski, źródło NVD)
SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '<description>'`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin's Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured. The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgstattuple('{{schema}}.{{table}}')`` and the matching pgstatindex shape -- where ``qtIdent`` escapes embedded double quotes inside the identifier but not apostrophes, so a user with CREATE privilege on a schema could plant a table or index named ``foo'bar`` and a later stats viewer would render an unbalanced literal. Fix is layered: 1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plumb ``conn=self.conn`` through every ``render_template`` call that loads one of these templates. Also corrects a ``{ % elif`` Jinja typo in the foreign-table schema diff (dead branch). Rewrite the ten pgstattuple/pgstatindex stats sites to address the relation via OID + ``::oid::regclass`` cast (e.g. ``pgstattuple({{ tid }}::oid::regclass)``), eliminating the embedded literal-call form entirely so that bug-class can no longer recur there. 2. Driver hardening: ``qtLiteral`` (in ``utils/driver/psycopg3/__init__.py``) used to silently return the raw unescaped value when its ``conn`` argument was falsy. It now raises ``ValueError`` -- surfacing the entire bug class going forward. The change immediately uncovered eight latent plumbing bugs (in ``schemas/__init__.py``, ``schemas/functions/__init__.py``, ``schemas/tables/utils.py``, ``foreign_servers/__init__.py``, and seven sites in ``roles/__init__.py``) -- all fixed as part of this patch. The inner ``except`` block that swallowed adapter-level failures and returned the raw value is also removed, so unadaptable inputs raise instead of leaking unescaped values. 3. Regression tests: a per-template behavioural test renders each previously-vulnerable template with an apostrophe-injection payload and asserts the escaped fragment is present and the vulnerable fragment absent; a lint test walks every ``*.sql`` template flagging any ``'{{ ... }}'`` single-quote-wrapped interpolation against an explicit allowlist; unit tests cover the new qtLiteral fail-fast and inner-except raise paths. This issue affects pgAdmin 4: from 1.0 before 9.16.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

