Skip to main content

pgAdmin 4 EUVDEUVD-2026-81895

| CVE-2026-86863 CRITICAL
Authentication Bypass by Spoofing (CWE-290)
2026-09-17 PostgreSQL GHSA-rc4w-fwh9-f5j9
Authentication Bypass Python Pgadmin 4 Pgadmin Org
9.3
CVSS 4.0 · Vendor: PostgreSQL
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach pgAdmin webserver-auth endpoint
  2. Delivery
    Add spoofed WEBSERVER_REMOTE_USER / X-Forwarded-User header
  3. Exploit
    Server trusts header as asserted identity
  4. Execution
    Authenticate as existing Administrator
  5. Impact
    Full pgAdmin and database control

Vulnerability Assessment

Weakness
CWE
CWE-290
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK

1 technique across 1 tactic: Defense Evasion

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Sign in to read
Exploitation Conditions

Exploitable only when 'webserver' is enabled in AUTHENTICATION_SOURCES (non-default; pgAdmin defaults to internal password authentication). Given that, no credentials or user interaction are needed: any client able to reach pgAdmin over the network supplies the identity header itself - either config.WEBSERVER_REMOTE_USER sent as an inbound header (the vulnerable get_user() fallback via request.headers.get()), or, when WEBSERVER_REMOTE_USER is set to an HTTP_-prefixed/hyphenated name like HTTP_X_FORWARDED_USER or X-Forwarded-User, the request.environ path since WSGI places inbound headers there. The limiting factor is purely that non-default webserver-auth mode; deployments using default internal or LDAP-only auth are unaffected, and versions 9.18+ require explicit opt-in (WEBSERVER_REMOTE_USER_FROM_HEADER), a trusted socket peer (WEBSERVER_TRUSTED_PROXIES), and optionally a shared-secret header.
Impact

This is a genuine high-priority vulnerability, not an inflated-CVSS artifact. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H) describes a remote, unauthenticated, low-complexity bypass yielding full compromise, and the description supports it: an inbound HTTP header trusted as an asserted identity lets any client reaching pgAdmin authenticate as an existing Administrator with no password. The single, decisive caveat the raw score does not capture is a configuration gate - it is exploitable ONLY when 'webserver' is enabled in AUTHENTICATION_SOURCES, which is NOT the default (pgAdmin defaults to internal password auth). So the effective PR:N/AC:L applies only to that subset of deployments; for the rest the vulnerability is inert. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis' - the 9.3 reflects potential impact and ease against affected configs, not observed exploitation. Signals are consistent rather than conflicting; the only tension is high theoretical severity versus a real-world footprint narrowed by the non-default webserver-auth requirement.
Exploit ScenarioDerived

An organization runs pgAdmin 4 with 'webserver' enabled in AUTHENTICATION_SOURCES behind (or intended to be behind) a reverse proxy that asserts the user identity. An attacker who can reach the pgAdmin HTTP endpoint sends a normal request but adds the identity header themselves (e.g. WEBSERVER_REMOTE_USER, or X-Forwarded-User which WSGI maps into the environ), naming an existing Administrator, and is logged in with no password. No public exploit is known, but the technique is trivial curl-level header injection given AV:N/AC:L/PR:N.
Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – Sep 17, 2026

Authentication bypass in pgAdmin 4 (versions 6.2 through 9.17) lets any client that can reach the pgAdmin web interface assume an arbitrary identity - including an existing Administrator account - without supplying a password or any other credential, when the non-default 'webserver' authentication source is enabled. The flaw, a spoofing-based authentication bypass (CWE-290), arises because the WebserverAuthentication class fell back to reading config.WEBSERVER_REMOTE_USER directly from client-controlled inbound HTTP request headers when the WSGI/CGI environment lookup returned nothing, and because headers named with an HTTP_ prefix or hyphens (for example HTTP_X_FORWARDED_USER or X-Forwarded-User) are placed into the WSGI environment by the server itself, satisfying the 'trusted' environment path. Per the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H the attack is unauthenticated and requires no user interaction, so unpatched deployments in webserver-auth mode should be treated as fully compromised by any network-reachable client; no public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV).

Earlier versions of this analysis (1)
v1 Sep 17, 2026 - 16:04 CVSS 9.8

Authentication bypass in pgAdmin 4 (from 6.2 before 9.18) lets any unauthenticated client who can reach the pgAdmin web interface log in as an arbitrary existing account, including an Administrator, without supplying a password - but only when the 'webserver' authentication source is enabled in AUTHENTICATION_SOURCES, which is not the default configuration. The flaw is a header-trust confusion (CWE-290): WebserverAuthentication.get_user() reads the asserted identity from config.WEBSERVER_REMOTE_USER in the WSGI/CGI environment, and when that yields nothing it falls back to the same name read straight from the inbound HTTP request headers, which the client itself controls. CVSS 3.1 rates this 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H); no public exploit code has been identified at time of analysis and there is no confirmed active exploitation, and the vendor-released patch is pgAdmin 4 9.18.

RemediationAI

The primary fix is to upgrade to pgAdmin 4 9.18 or later, the first release outside the affected 'before 9.18' range, which is the vendor-released patched version; no backports to earlier 6.x/7.x/8.x branches are indicated in the available data, so upgrading across major versions may be required. If upgrading immediately is not possible, the highest-value compensating control is to remove 'webserver' from AUTHENTICATION_SOURCES entirely and rely on pgAdmin's internal password store, LDAP, OAuth, or Kerberos sources - this fully eliminates the exposure because the vulnerable code path is only reachable in webserver-auth mode, at the cost of losing single-sign-on via your reverse proxy. A second containment option is to guarantee that no client-supplied identity header can reach pgAdmin: configure the reverse proxy to strip inbound X-Forwarded-User, HTTP_X_FORWARDED_USER, HTTP_-prefixed variants and any header matching the configured WEBSERVER_REMOTE_USER value, and firewall pgAdmin so that only the proxy's address can connect - this is fragile, however, because the vulnerable fallback also accepted the plain WEBSERVER_REMOTE_USER name as a header, so any gap in the header-stripping rules reopens the bypass. Do not rely on X-Forwarded-For based filtering as a mitigation: ProxyFix rewrites request.remote_addr from that client-controlled header, which is exactly why the patched code checks the real socket peer address instead. After upgrading, review the new hardening parameters - WEBSERVER_REMOTE_USER_FROM_HEADER must be explicitly enabled for header-asserted identities, WEBSERVER_TRUSTED_PROXIES must list the actual proxy peers, and WEBSERVER_SHARED_SECRET_HEADER/WEBSERVER_SHARED_SECRET should be set to a strong shared secret so the assertion is cryptographically bound rather than merely address-bound; because all three conditions must be satisfied, a missing trusted-proxy entry or secret will cause legitimate logins to fail, so validate in staging before production rollout. Finally, treat any pgAdmin instance that ran in webserver-auth mode while unpatched as potentially compromised: audit pgAdmin's session and user records for unexpected Administrator logins and rotate any credentials or secrets those sessions could have reached.

Affected VersionsENISA

pgAdmin 4 6.2 <9.18

Affected Packages

euvd pgadmin_4 fix: 9.18

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

pgAdmin 4 can delegate authentication to an upstream web server or reverse proxy through its 'webserver' authentication source, in which the front end is expected to assert the already-authenticated username via the WSGI/CGI environment variable named by config.WEBSERVER_REMOTE_USER. The root cause class is CWE-290 (Authentication Bypass by Spoofing): the vulnerable code in WebserverAuthentication.get_user() read that name from request.environ and, when it returned nothing, fell back to request.headers.get() - but request.headers is populated entirely from the inbound HTTP request, which the client writes. Any client able to reach pgAdmin could therefore send the username it wanted and be logged in as that user, including an Administrator, with no credential presented. A second, more subtle path existed when WEBSERVER_REMOTE_USER was configured to an HTTP_-prefixed or hyphenated value such as HTTP_X_FORWARDED_USER or X-Forwarded-User: WSGI servers map inbound HTTP headers into environ under exactly those names, so a client-supplied header collided with the environment lookup meant for the trusted proxy. The fix distinguishes a genuine CGI/WSGI variable from a header-derived one and only trusts header-asserted identities when the operator explicitly opts in (WEBSERVER_REMOTE_USER_FROM_HEADER), the request originates from a peer in WEBSERVER_TRUSTED_PROXIES, and any configured shared secret supplied in WEBSERVER_SHARED_SECRET_HEADER matches WEBSERVER_SHARED_SECRET under a constant-time comparison. Notably, 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. As defence in depth, login() now refuses any account whose auth_source is not 'webserver', preventing a misconfigured trust gate from being used to assume an internal or LDAP account. CPE cpe:2.3:a:pgadmin.org:pgadmin_4:*:*:*:*:*:*:*:* covers the affected line.

Know when Pgadmin 4 gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (PostgreSQL) PRIMARY 9.3 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 9.8 CRITICAL

Remote, no credentials, and no interaction once webserver auth is enabled; header spoofing grants Administrator, so C/I/A:H; the config gate is a deployment precondition not modeled by base metrics.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE 9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Primary rating from Vendor (PostgreSQL).

CVSS VectorVendor: PostgreSQL

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

4
Patch available
Sep 17, 2026 - 17:19 EUVD
Analysis Updated
Sep 17, 2026 - 16:28 vuln.today
v2 - CVSS changed
CVSS changed
Sep 17, 2026 - 16:22 NVD
9.8 (CRITICAL) 9.3 (CRITICAL)
CVE Published
Sep 17, 2026 - 15:30 cve.org
CRITICAL 9.8

DescriptionCVE.org

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.

Articles & Coverage 1

News Critical Authentication Bypass in pgAdmin 4 (v6.2-9.17) - CVE-2026-86863 Sep 18, 2026

Executive ViewAI

Why It Matters

pgAdmin 4 versions 6.2 through 9.17 configured with the non-default 'webserver' authentication source are affected by a critical authentication bypass. An unauthenticated attacker who can reach the pgAdmin web interface could impersonate any user, including an existing administrator, without credentials, potentially gaining full control over managed PostgreSQL databases and sensitive data. No vendor-released patch identified at time of analysis, so leadership should prioritize immediate mitigation to protect database confidentiality, integrity, and availability.

Business Impact: Severe
Compensating Controls

No vendor-released patch identified at time of analysis; interim mitigations include disabling the 'webserver' authentication source, using an alternative supported authentication method, restricting network access to pgAdmin interfaces to trusted administrative networks or VPN, and configuring reverse proxies to strip or reject client-supplied identity headers such as X-Forwarded-User and HTTP_X_FORWARDED_USER. Monitor vendor advisories and apply the vendor patch when released.

Threat Intelligence Overview

EPSS Score
0.4%
Top 70% exploitable
Prevalence
High
pgAdmin 4 is the de facto standard PostgreSQL administration GUI
Data Quality
7 sources
Confidence: High
EUVD 🇯🇵JVN NVD CVE.org EPSS Vulnrichment Vendor GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Out-of-Cycle
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
Very High
Technical Impact
Total

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication Bypass CRITICAL

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Pgadmin 4

View all
CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
CVE-2024-2044 CRITICAL POC
9.9 Mar 07

pgAdmin <= 8.3 is affected by a path-traversal vulnerability while deserializing users’ sessions in the session handling
CVE-2024-3116 CRITICAL POC
9.8 Apr 04

pgAdmin <= 8.4 is affected by a Remote Code Execution (RCE) vulnerability through the validate binary path API. Rated cr
CVE-2026-12046 CRITICAL POC
9.5 Jun 18

Remote unauthenticated access to two SQL Editor endpoints in pgAdmin 4 server-mode deployments (versions 6.9 through 9.1
CVE-2022-4223 HIGH POC
8.8 Dec 13

The pgAdmin server includes an HTTP API that is intended to be used to validate the path a user selects to external Post
CVE-2024-9014 MEDIUM POC
6.5 Sep 23

pgAdmin versions 8.11 and earlier are vulnerable to a security flaw in OAuth2 authentication. Rated medium severity (CVS
CVE-2025-12762 CRITICAL
9.8 Nov 13

Remote code execution in pgAdmin 4 (versions up to and including 9.9) lets an attacker who can get a crafted PLAIN-forma
CVE-2026-12045 CRITICAL
9.4 Jun 18

Remote SQL injection via prompt injection in pgAdmin 4 versions 9.13 through 9.15 allows attackers who can write content
CVE-2026-17351 CRITICAL
9.4 Jul 31

SQL injection sandbox escape in pgAdmin 4's AI Assistant (versions 9.13 through 9.16) lets an attacker break out of the

CVE-2026-17566 CRITICAL POC
9.4 Jul 31

OS command injection in pgAdmin 4 (all versions before 9.18) lets an authenticated user with the commonly-granted tools_
CVE-2026-7813 CRITICAL
9.4 May 11

Authorization bypass and privilege escalation in pgAdmin 4 server mode allows authenticated users to access other users'
CVE-2024-4216 MEDIUM POC
5.4 May 02

pgAdmin <= 8.5 is affected by XSS vulnerability in /settings/store API response json payload. Rated medium severity (CVS

Same weakness CWE-290 – Authentication Bypass by Spoofing

View all
CVE-2026-104935 HIGH POC
8.6
CVE-2026-102764 CRITICAL POC
9.3
CVE-2024-54085 CRITICAL
9.8
CVE-2023-50224 MEDIUM
6.5
CVE-2024-4358 CRITICAL POC
9.8
CVE-2018-5353 CRITICAL POC
9.8
CVE-2023-51350 CRITICAL POC
9.8
CVE-2022-3180 CRITICAL
9.8

Same technique Authentication Bypass

View all
CVE-2015-3306 CRITICAL POC
10.0
CVE-2023-22515 CRITICAL POC
9.8
CVE-2012-4681 CRITICAL POC
9.8
CVE-2013-2465 CRITICAL POC
9.8
CVE-2011-3544 CRITICAL POC
9.8
CVE-2022-40684 CRITICAL POC
9.8
CVE-2025-61882 CRITICAL POC
9.8
CVE-2024-0012 CRITICAL POC
9.3

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Module for Python 3 15 SP7 Affected
SUSE Linux Enterprise Server 15 SP7 Affected
SUSE Linux Enterprise Server for SAP Applications 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-86863 REF https://github.com/pgadmin-org/pgadmin4/issues/10383

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy