A critical authentication bypass vulnerability has been disclosed in OAuth2 Proxy (CVE-2026-40575), allowing unauthenticated remote attackers to bypass authentication entirely and access protected application routes by spoofing the X-Forwarded-Uri HTTP header.
Organizations using OAuth2 Proxy in reverse-proxy configurations with skip-auth rules must act immediately to apply patches and harden their proxy infrastructure.
OAuth2 Proxy Vulnerability
A report was filed about a configuration-dependent authentication bypass in OAuth2 Proxy, the widely deployed open-source reverse proxy and central authentication tool used to enforce OAuth2/OIDC-based access control for web applications.
The flaw was published on April 14–15, 2026, published in GitHub Security Advisory GHSA-7×63-xv5r-3p2x, and has been assigned CVE-2026-40575 with a CVSS v3.1 score of 9.5 (Critical).
The vulnerability impacts all OAuth2 Proxy deployments running versions >= 7.5.0 and < 7.15.2. It was patched in the newly released v7.15.2 alongside another high-severity fix (GHSA-pxq7-h93f-9jrg).
At its core, this vulnerability stems from how OAuth2 Proxy handles the X-Forwarded-Uri header when operating behind a reverse proxy. When OAuth2 Proxy is configured with:
--reverse-proxyflag enabled, AND- At least one
--skip-auth-routeor the legacy--skip-auth-regexrule defined
…the proxy unconditionally trusts any X-Forwarded-Uri header supplied by the client, including malicious, attacker-crafted ones.
Here’s the attack chain in practice:
- An attacker identifies a publicly accessible route that is allowed via
--skip-auth-route(e.g.,/healthor/public/assets) - The attacker crafts an HTTP request targeting a protected route (e.g.,
/admin/dashboard) but injects a spoofedX-Forwarded-Uri: /healthheader - OAuth2 Proxy evaluates authentication rules against the spoofed
/healthpath rather than the real/admin/dashboardpath - Since
/healthmatches a skip-auth rule, OAuth2 Proxy skips authentication and forwards the request upstream - The upstream application, however, serves the actual requested path
/admin/dashboardgranting the attacker unauthorized access
This is a textbook CWE-290: Authentication Bypass by Spoofing attack. No privileges, no user interaction, and no special conditions beyond network access are required, making this trivially exploitable at scale.
The vulnerability carries a CVSS v3.1 score of 9.5.
| Metric | Value |
|---|---|
| CVE ID | CVE-2026-40575 |
| CVSS Score | 9.5 Critical |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Confidentiality Impact | High |
| Integrity Impact | High |
| Availability Impact | None |
| CWE | CWE-290 (Authentication Bypass by Spoofing) |
The combination of no required privileges, no user interaction, and network-based exploitability positions CVE-2026-40575 as an immediately weaponizable threat for any unpatched deployment.
| Status | Versions |
|---|---|
| Vulnerable | >= 7.5.0 and < 7.15.2 |
| Patched | v7.15.2 and later |
Organizations running any OAuth2 Proxy release between 7.5.0 and 7.15.1 (inclusive) are vulnerable if they use reverse proxy mode with skip-auth rules.
Patch & Mitigation
The official OAuth2 proxy patch introduces a new --trusted-proxy-ip flag in OAuth2 Proxy v7.15.2. This allows administrators to explicitly define the IP addresses or CIDR ranges of trusted reverse proxies permitted to send X-Forwarded-* headers.
Important: If left unset after upgrading, all source IPs (0.0.0.0/0) remain trusted by default for backward compatibility, meaning the spoofing risk persists until explicitly configured.
- Upgrade immediately to OAuth2 Proxy v7.15.2 or later
- Configure
--trusted-proxy-ipwith the specific IPs or CIDR ranges of your load balancers and reverse proxies, never leave it set to 0.0.0.0/0 in production - Strip client-supplied
X-Forwarded-Uriheaders at the reverse proxy or load balancer level before they reach the OAuth2 Proxy - Explicitly overwrite
X-Forwarded-Uriwith the actual$request_uriin your nginx or load balancer config to prevent downstream header injection - Restrict direct client access to OAuth2 Proxy, so it is only reachable through your trusted reverse proxy infrastructure
- Audit and narrow
--skip-auth-route/--skip-auth-regexrules remove any overly permissive patterns that expose broad URL namespaces
For nginx deployments using OAuth2 Proxy as an auth subrequest handler, setting proxy_set_header X-Forwarded-Uri $request_uri; directly in the internal auth location block effectively strips any attacker-supplied value and replaces it with the real request path.
Header spoofing vulnerabilities in reverse proxy chains are a persistently underestimated attack surface. OAuth2 Proxy is widely deployed in Kubernetes ingress architectures, cloud-native environments, and internal developer tooling to enforce centralized authentication.
A bypass at this layer effectively neutralizes the entire authentication perimeter exposing admin panels, internal APIs, CI/CD dashboards, and sensitive data endpoints to unauthenticated attackers.
As organizations increasingly adopt zero-trust networking models, the assumption that X-Forwarded-* headers represent trusted, validated data, which is a dangerous architectural gap.
This vulnerability underscores that header validation and proxy IP allowlisting are not optional hardening steps; they are fundamental security controls.
FAQ
Q1: What is CVE-2026-40575?
It is a critical authentication bypass vulnerability in OAuth2 Proxy caused by trusting attacker-controlled X-Forwarded-Uri headers, enabling unauthenticated access to protected routes.
Q2: Which OAuth2 Proxy versions are affected?
All versions from 7.5.0 up to (but not including) 7.15.2 are vulnerable when using --reverse-proxy with skip-auth rules.
Q3: What is the fix for this vulnerability?
Upgrade to OAuth2 Proxy v7.15.2 and configure the new --trusted-proxy-ip flag to restrict which proxies can send trusted forwarded headers.
Q4: Can this vulnerability be exploited without authentication?
Yes, CVE-2026-40575 requires zero privileges and no user interaction, making it remotely exploitable by any network-accessible attacker.
Site: http://thecybrdef.com
About the Author
