AI analysis
CVE-2026-86863 is a critical authentication bypass (CVSS 4.0: 9.3) in the Webserver authentication source of pgAdmin 4, the standard web-based administration tool for PostgreSQL. When 'webserver' is enabled in AUTHENTICATION_SOURCES, pgAdmin accepted an identity from the WSGI/CGI environment and, when that was empty, fell back to reading the configured identity header directly from the inbound HTTP request, so any client who could reach the pgAdmin interface could supply a header such as X-Forwarded-User (or the name configured in WEBSERVER_REMOTE_USER, e.g. HTTP_X_FORWARDED_USER) and be logged in as any named user, including an existing Administrator, without a password. An attacker therefore gains full control of pgAdmin, including access to the PostgreSQL servers and stored connection details it manages. Only deployments running pgAdmin 4 from version 6.2 up to (but not including) 9.18 with the 'webserver' authentication source enabled are affected; deployments using only internal, LDAP, or OAuth2 authentication are not. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is currently known.
What to do: Upgrade to pgAdmin 4 9.18 or later, which only trusts genuine WSGI/CGI variables and adds the WEBSERVER_TRUSTED_PROXIES (real socket peer check), WEBSERVER_REMOTE_USER_FROM_HEADER opt-in, and WEBSERVER_SHARED_SECRET controls. As interim mitigation, remove 'webserver' from AUTHENTICATION_SOURCES, or ensure the fronting proxy overwrites/strips the identity header and that pgAdmin is not directly reachable bypassing the proxy. Review pgAdmin logs for logins to webserver-authenticated accounts, especially Administrator, from unexpected source addresses.
Affected
| pgAdmin Project (PostgreSQL) pgAdmin 4 | from 6.2 before 9.18 (only when 'webserver' is enabled in AUTHENTICATION_SOURCES) |
Estimated exposure
moderate≈10,000–100,000 deployments (the opt-in 'webserver' auth subset of pgAdmin's multi-million-user installed base) — pgAdmin 4 ships with mainstream PostgreSQL installers, giving a very large overall user base, but the flaw requires the non-default AUTHENTICATION_SOURCES='webserver' configuration typical of reverse-proxy/SSO setups, shrinking the…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
pgAdmin 4's Webserver authentication source is intended to accept an identity asserted by the web server or reverse proxy in front of pgAdmin, delivered through the WSGI/CGI environment. WebserverAuthentication.get_user() read config.WEBSERVER_REMOTE_USER from request.environ and, when that returned nothing, fell back to reading the same name directly from the inbound HTTP request headers via request.headers.get(). An inbound HTTP header is written by whoever sends the request, so any client able to reach pgAdmin could supply that header itself and be authenticated as any username it named, including an existing Administrator, without presenting a password or any other credential. The environment lookup could also be satisfied by a client-supplied header whenever WEBSERVER_REMOTE_USER was configured to an HTTP_-prefixed or hyphenated name such as HTTP_X_FORWARDED_USER or X-Forwarded-User, since WSGI servers place inbound headers into the environment under exactly those names. Deployments are affected only when 'webserver' is enabled in AUTHENTICATION_SOURCES. The fix distinguishes a genuine CGI/WSGI variable from a header-derived one and implicitly trusts only the former. A header-asserted identity is now accepted only when the operator explicitly opts in via WEBSERVER_REMOTE_USER_FROM_HEADER, the request arrives from a peer listed in WEBSERVER_TRUSTED_PROXIES, and, when configured, a shared secret supplied in WEBSERVER_SHARED_SECRET_HEADER matches WEBSERVER_SHARED_SECRET under a constant-time comparison. The trusted-peer check deliberately reads the real socket peer address rather than request.remote_addr, because ProxyFix rewrites the latter from the client-controlled X-Forwarded-For header and would otherwise allow an attacker to claim to be the trusted proxy. As defence in depth, login() now refuses any account whose auth_source is not 'webserver', so a misconfigured trust gate cannot be used to assume an internal or LDAP account. This issue affects pgAdmin 4: from 6.2 before 9.18.