Kurzfassung

In pgAdmin 4 steckt mit CVE-2026-86863 eine kritische Schwachstelle, die unter bestimmten Konfigurationen eine Anmeldung als beliebiger Benutzer ohne Passwort erlaubt. Betroffen sind Versionen von 6.2 bis vor 9.18, allerdings nur, wenn in der Konfiguration die Authentifizierungsquelle webserver aktiviert ist. Der Schweregrad liegt bei CVSS 9.3 und ist damit technisch kritisch.

Was ist passiert?

Die Schwachstelle betrifft die Anmeldung über einen vorgeschalteten Webserver oder Reverse Proxy. Dieser Modus ist dafür gedacht, dass die Identität eines bereits extern authentifizierten Benutzers an pgAdmin 4 weitergereicht wird.

Genau an dieser Stelle lag der Fehler: pgAdmin 4 hat die erwartete Benutzerkennung nicht nur aus vertrauenswürdigen CGI- oder WSGI-Umgebungsvariablen gelesen, sondern unter bestimmten Umständen auch direkt aus eingehenden HTTP-Headern übernommen. Solche Header kann ein Angreifer selbst setzen, wenn er die Anwendung direkt oder über den Proxy erreichen kann.

Dadurch konnte sich ein Angreifer als beliebiger Benutzer ausgeben, auch als vorhandener Administrator. Ein Passwort oder andere Zugangsdaten waren dafür nicht nötig.

Technische Details

Betroffen ist die Funktion zur Webserver-Authentifizierung in pgAdmin 4. Wenn AUTHENTICATION_SOURCES den Wert webserver enthält, erwartet die Anwendung eine Benutzeridentität aus einer vom Webserver bereitgestellten Variablen. Die verwundbare Logik griff jedoch ersatzweise auf HTTP-Header zurück, wenn der erwartete Wert nicht wie vorgesehen vorlag.

Besonders kritisch wurde das bei Konfigurationen, in denen WEBSERVER_REMOTE_USER auf Namen wie HTTP_X_FORWARDED_USER oder X-Forwarded-User gesetzt war. Solche Bezeichner können über eingehende Header in der Anwendungsumgebung auftauchen und damit vom Client beeinflusst werden.

Der CVSS-Basiswert liegt bei 9.3 nach CVSS 4.0. Der Vektor beschreibt einen Angriff über das Netzwerk mit geringer Komplexität, ohne erforderliche Berechtigungen und ohne Nutzerinteraktion: Jeder, der pgAdmin erreichen kann, kann die Schwachstelle unter den genannten Voraussetzungen direkt ausnutzen. Der Wert beschreibt die technische Schwere, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

Die Korrektur trennt nun sauber zwischen echten CGI- beziehungsweise WSGI-Variablen und Headern, die vom Client stammen können. Eine Identität aus Headern wird nur noch akzeptiert, wenn Administratoren dies ausdrücklich aktivieren, die Anfrage von einer vertrauenswürdigen Proxy-Adresse kommt und optional ein gemeinsames Geheimnis korrekt mitgeliefert wird. Zusätzlich lehnt der Login nun Konten ab, deren Anmeldequelle nicht auf webserver steht.

Wer ist betroffen?

Betroffen sind pgAdmin-4-Versionen ab 6.2 bis einschließlich 9.17. Nicht jede Installation ist automatisch angreifbar.

Entscheidend ist die Konfiguration: Verwundbar sind Deployments nur dann, wenn die Authentifizierungsquelle webserver aktiviert wurde. Wer pgAdmin 4 ausschließlich mit lokaler Anmeldung oder anderen Anmeldemechanismen betreibt und keine Webserver-Authentifizierung nutzt, ist nach den bekannten Informationen nicht betroffen.

Für Unternehmen im DACH-Raum ist das vor allem dort relevant, wo pgAdmin 4 intern über Reverse Proxys, Single-Sign-on-Konstrukte oder vorgelagerte Webserver betrieben wird. Gerade in Admin-Netzen wird oft angenommen, dass Header vom Proxy vertrauenswürdig sind. Diese Annahme war hier riskant.

Empfohlene Maßnahmen

Erstens: Prüfen Sie sofort, ob in Ihrer pgAdmin-4-Konfiguration AUTHENTICATION_SOURCES den Eintrag webserver enthält. Wenn nicht, ist diese konkrete Schwachstelle für Ihre Instanz nach aktuellem Stand nicht relevant.

Zweitens: Aktualisieren Sie betroffene Installationen auf Version 9.18 oder neuer. Wer den Webserver-Authentifizierungsmodus benötigt, sollte das Update mit hoher Priorität einspielen.

Drittens: Falls ein sofortiges Update nicht möglich ist, deaktivieren Sie vorübergehend die Authentifizierungsquelle webserver, sofern der Betrieb das zulässt. Ist das nicht möglich, beschränken Sie den Zugriff strikt auf vertrauenswürdige Netze und vorgelagerte Systeme.

Viertens: Prüfen Sie Reverse-Proxy- und Webserver-Konfigurationen auf Header wie X-Forwarded-User oder ähnliche Benutzerkennungen. Diese dürfen nicht ungeprüft aus dem Client-Verkehr an Verwaltungsanwendungen durchgereicht werden.

Fünftens: Kontrollieren Sie, welche Konten in pgAdmin 4 Administratorrechte besitzen. Da die Schwachstelle eine Anmeldung als beliebiger Benutzer erlauben konnte, sollten Sie verdächtige Logins, Konfigurationsänderungen und neu angelegte Serververbindungen rückwirkend prüfen.

Offizielle technische Details und die NVD-Referenz finden Sie unter https://nvd.nist.gov/vuln/detail/CVE-2026-86863.

Einschätzung von CyberSecurity-News.de

Die Lücke ist technisch gravierend, aber nicht pauschal für jede pgAdmin-Installation brisant. Die reale Gefährdung hängt vollständig daran, ob der spezielle Authentifizierungsmodus überhaupt aktiviert wurde. Für viele Standardinstallationen dürfte das Problem deshalb keine akute Rolle spielen.

Anders sieht es in professionellen Umgebungen mit Reverse Proxy, SSO-Vorstufen oder zentraler Zugriffskontrolle aus. Dort ist der Fehler besonders unangenehm, weil er genau eine Vertrauenskette unterläuft, auf die Administratoren sich im Betrieb verlassen. Wer pgAdmin 4 in solchen Architekturen nutzt, sollte das Thema nicht aufschieben.

Die Informationslage ist für die technische Einordnung gut genug, weil Ursache, Auswirkungen und Abgrenzung der betroffenen Konfiguration klar beschrieben sind. Was noch fehlt, ist eine belastbare Aussage dazu, ob die Schwachstelle bereits aktiv ausgenutzt wurde; die NVD nennt dazu derzeit nichts.

Fazit

Wenn Sie pgAdmin 4 mit aktivierter Webserver-Authentifizierung betreiben, sollten Sie unverzüglich auf 9.18 oder neuer aktualisieren und die Proxy-Vertrauenskette überprüfen. Ohne diesen Modus ist die Relevanz gering, mit diesem Modus dagegen ist die Lücke wegen möglicher Admin-Übernahme hochkritisch.

Quellenangabe

Weiterführende Informationen bietet der NVD-Eintrag zu CVE-2026-86863.