OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
Summary
| CVE | CVE-2026-40575 |
|---|---|
| State | PUBLISHED |
| Assigner | GitHub_M |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-04-22 00:16:27 UTC |
| Updated | 2026-07-15 02:21:07 UTC |
| Description | OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 may trust a client-supplied `X-Forwarded-Uri` header when `--reverse-proxy` is enabled and `--skip-auth-regex` or `--skip-auth-route` is configured. An attacker can spoof this header so OAuth2 Proxy evaluates authentication and skip-auth rules against a different path than the one actually sent to the upstream application. This can result in an unauthenticated remote attacker bypassing authentication and accessing protected routes without a valid session. Impacted users are deployments that run oauth2-proxy with `--reverse-proxy` enabled and configure at least one `--skip-auth-regex` or `--skip-auth-route` rule. This issue is patched in `v7.15.2`. Some workarounds are available for those who cannot upgrade immediately. Strip any client-provided `X-Forwarded-Uri` header at the reverse proxy or load balancer level; explicitly overwrite `X-Forwarded-Uri` with the actual request URI before forwarding requests to OAuth2 Proxy; restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy; and/or remove or narrow `--skip-auth-regex` / `--skip-auth-route` rules where possible. For nginx-based deployments, ensure `X-Forwarded-Uri` is set by nginx and not passed through from the client. |
Risk And Classification
Primary CVSS: v3.1 8.7 HIGH from ADP
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
EPSS: 0.004770000 probability, percentile 0.380340000 (date 2026-07-15)
Problem Types: CWE-290 | CWE-290 CWE-290: Authentication Bypass by Spoofing | CWE-290 Authentication Bypass by Spoofing
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | ADP | CVSS | 8.7 | HIGH | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | [email protected] | Secondary | 9.1 | CRITICAL | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| 3.1 | 0b0ca135-0b70-47e7-9f44-1890c2a1c46c | Secondary | 8.7 | HIGH | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | CNA | DECLARED | 9.1 | CRITICAL | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
NVD Known Affected Configurations (CPE 2.3)
| Type | Vendor | Product | Version | Update | Edition | Language |
|---|---|---|---|---|---|---|
| Application | Oauth2 Proxy Project | Oauth2 Proxy | All | All | All | All |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Oauth2-proxy | Oauth2-proxy | affected >= 7.5.0, < 7.15.2 | Not specified |
| ADP | Red Hat | Red Hat Ceph Storage 9 | Not specified | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| bugzilla.redhat.com/show_bug.cgi | 0b0ca135-0b70-47e7-9f44-1890c2a1c46c | bugzilla.redhat.com | |
| access.redhat.com/security/cve/CVE-2026-40575 | 0b0ca135-0b70-47e7-9f44-1890c2a1c46c | access.redhat.com | |
| security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40575.json | 0b0ca135-0b70-47e7-9f44-1890c2a1c46c | security.access.redhat.com | |
| github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-... | [email protected] | github.com | Vendor Advisory |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Additional Advisory Data
| Source | Time | Event |
|---|---|---|
| ADP | 2026-04-22T00:01:48.616Z | Reported to Red Hat. |
| ADP | 2026-04-21T23:20:30.486Z | Made public. |
Workarounds
ADP: This issue can be mitigated by one of the options bellow: 1) Strip any client-provided `X-Forwarded-Uri` header at any layer before it reaches `oauth2-proxy`; 2) Overwrite the `X-Forwarded-Uri` header with the actual request URI before the request reaches `oauth2-proxy`. If you are using NGINX you can use the following example to create your tailored mitigation: ~~~ location /internal-auth/ { internal; # Ensure external users can't access this path # Make sure the OAuth2 Proxy knows where the original request came from. proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # set the value to the actual $request_uri and therefore strip any user provided X-Forwarded-Uri proxy_set_header X-Forwarded-Uri $request_uri; proxy_pass http://oauth2-proxy:4180/; } ~~~ 3) Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy; 4) Remove or narrow --skip-auth-route / --skip-auth-regex rules where possible;