CVE-2026-86863 in pgAdmin
Zusammenfassung
von VulDB • 17.09.2026
Die Authentifizierungsquelle des Webservers von pgAdmin 4 ist dafür vorgesehen, eine Identität zu akzeptieren, die vom Webserver oder Reverse-Proxy vor pgAdmin behauptet wird und über die WSGI/CGI-Umgebung bereitgestellt wird. `WebserverAuthentication.get_user()` las `config.WEBSERVER_REMOTE_USER` aus `request.environ`, und wenn dies nichts zurückgab, fiel es darauf zurück, denselben Namen direkt aus den eingehenden HTTP-Request-Headers via `request.headers.get()` zu lesen. Ein eingehender HTTP-Header wird von demjenigen geschrieben, der die Anfrage sendet; daher könnte jeder Client, der pgAdmin erreichen kann, diesen Header selbst bereitstellen und sich als beliebiger Benutzername authentifizieren, einschließlich eines bestehenden Administrators, ohne ein Passwort oder andere Anmeldeinformationen vorzulegen. Die Umgebungsabfrage konnte auch durch einen vom Client bereitgestellten Header erfüllt werden, wenn `WEBSERVER_REMOTE_USER` so konfiguriert war, dass es einem HTTP-präfixierten oder Bindestrich-gesetzten Namen wie `HTTP_X_FORWARDED_USER` oder `X-Forwarded-User` entsprach, da WSGI-Server eingehende Header genau unter diesen Namen in die Umgebung aufnehmen. Bereitstellungen sind nur betroffen, wenn 'webserver' in `AUTHENTICATION_SOURCES` aktiviert ist.
Die Korrektur unterscheidet eine echte CGI/WSGI-Variablen von einer header-abgeleiteten und vertraut implizit nur erstere. Eine durch Header behauptete Identität wird nun nur akzeptiert, wenn der Betreiber dies explizit über `WEBSERVER_REMOTE_USER_FROM_HEADER` zulässt, die Anfrage von einem in `WEBSERVER_TRUSTED_PROXIES` aufgeführten Peer stammt und – falls konfiguriert – ein gemeinsames Geheimnis, das in `WEBSERVER_SHARED_SECRET_HEADER` bereitgestellt wird, unter Verwendung eines konstanten Vergleichs mit `WEBSERVER_SHARED_SECRET` übereinstimmt. Die Überprüfung des vertrauenswürdigen Peers liest absichtlich die echte Socket-Peer-Adresse anstelle von `request.remote_addr`, da ProxyFix letzteres aus dem vom Client kontrollierten `X-Forwarded-For`-Header umschreibt und andernfalls einem Angreifer ermöglichen würde, sich als der vertrauenswürdige Proxy auszugeben. Als Defense-in-Depth-Maßnahme verweigert `login()` nun jedes Konto, dessen `auth_source` nicht 'webserver' ist, sodass ein falsch konfigurierter Vertrauenspunkt nicht verwendet werden kann, um ein internes oder LDAP-Konto zu übernehmen.
Dieses Problem betrifft pgAdmin 4: von Version 6.2 bis vor 9.18.
VulDB is the best source for vulnerability data and more expert information about this specific topic.