CVE-2026-76835
OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
9.3
OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
CVE-2026-76835- CVSS 4.0
- 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-290
- Updated
- 2026-11-02
EUVDEUVD-2026-65061
9.3
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
EUVD-2026-65061- CVSS 4.0
- 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-vvqv-7vrf-88vh
9.3
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may...
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
GHSA-vvqv-7vrf-88vh- CVSS 4.0
- 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-290
- Updated
- 2026-11-02
NVD
9.3
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
CVE-2026-76835- CVSS 4.0
- 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-290
- Updated
- 2026-11-02
OSVCVE-2026-40575
9.1
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
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.
- Record
CVE-2026-40575- CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-290
- Updated
- 2026-11-02
OSV
9.3
OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
CVE-2026-76835- CVSS 4.0
- 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-290
- Updated
- 2026-11-02
Show 5 moreShow less
OSVGHSA-7x63-xv5r-3p2x
9.1
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
Impact
A configuration-dependent authentication bypass exists in OAuth2 Proxy.
Deployments are affected when all of the following are true:
- OAuth2 Proxy is configured with
--reverse-proxy - and at least one rule is defined with
--skip_auth_routesor the legacy--skip-auth-regex
OAuth2 Proxy may trust a client-supplied X-Forwarded-Uri header when --reverse-proxy is enabled and --skip-auth-route or --skip-auth-regex 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.
Patches
This issue is addressed as part of the newly introduced --trusted-proxy-ip flag in v7.15.2. If you leave it unset, OAuth2 Proxy will continue to trust ALL source IPs (0.0.0.0/0) for backwards compatibility, which means a client may still be able to spoof forwarded headers. Therefore after upgrading we urge you to use the new --trusted-proxy-ip flag to set the IPs or CIDR ranges of the reverse proxies that are allowed to send X-Forwarded-* headers and furthermore implement the mitigation steps outlined below to properly configure your load balancer infrastructure.
Mitigation
-
Strip any client-provided
X-Forwarded-Uriheader at the reverse proxy or load balancer level -
Explicitly overwrite
X-Forwarded-Uriwith the actual request URI before forwarding requests to OAuth2 ProxyExample nginx mitigation for the auth subrequest:
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/; } -
Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy
-
Remove or narrow
--skip-auth-route/--skip-auth-regexrules where possible
- Record
GHSA-7x63-xv5r-3p2x- CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-290
- Updated
- 2026-11-02
OSVRHSA-2026:74536
9.1
Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update
- Record
RHSA-2026:74536- CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
OSVBIT-oauth2-proxy-2026-40575 No score
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
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.
- Record
BIT-oauth2-proxy-2026-40575- Updated
- 2026-11-02
OSVBIT-oauth2-proxy-2026-76835 No score
OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
- Record
BIT-oauth2-proxy-2026-76835- Updated
- 2026-11-02
OSVGO-2026-5236 No score
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing in github.com/oauth2-proxy/oauth2-proxy
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing in github.com/oauth2-proxy/oauth2-proxy
- Record
GO-2026-5236- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
oauth2-proxyBitnami From an advisory covering 2 CVEs |
7.5.0 up to 7.15.2 | 7.15.2 |
oauth2-proxyBitnami From an advisory covering 2 CVEs |
7.15.2 up to 7.15.5 | 7.15.5 |
github.com/oauth2-proxy/oauth2-proxy/v7Go From an advisory covering 2 CVEs |
7.5.0 up to 7.15.2 | 7.15.2 |
github.com/oauth2-proxy/oauth2-proxyGo From an advisory covering 2 CVEs |
All versions | None known |
oauth2-proxyRed Hat:hummingbird:1 From an advisory covering 2 CVEs |
before 0:7.15.5-0.1.hum1 | 0:7.15.5-0.1.hum1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-76835 is a critical vulnerability (CVSS 9.3) in Oauth2-proxy, published April 15, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.45%, the 39th percentile. No source names a fixed version.
References
github.com/oauth2-proxy/oauth2-proxy
github.com/oauth2-proxy/oauth2-proxy/issues/3506
github.com/oauth2-proxy/oauth2-proxy/blob/v7.15.4/pkg/apis/middleware/scope.go
github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x
vulncheck.com/advisories/oauth2-proxy-through-authentication-bypass-via-x-forwarded-uri-under-the-default-trusted-proxy-set
nvd.nist.gov/vuln/detail/CVE-2026-76835
Show 21 moreShow less
github.com/advisories/GHSA-vvqv-7vrf-88vh
nvd.nist.gov/vuln/detail/CVE-2026-40575
access.redhat.com/security/cve/CVE-2026-40575
bugzilla.redhat.com/show_bug.cgi?id=2460449
security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40575.json
github.com/CVEProject/cvelistV5/tree/main/cves/2026/40xxx/CVE-2026-40575.json
github.com/CVEProject/cvelistV5/tree/main/cves/2026/76xxx/CVE-2026-76835.json
access.redhat.com/errata/RHSA-2026:74536
images.redhat.com
access.redhat.com/security/cve/CVE-2026-76835
access.redhat.com/security/updates/classification
access.redhat.com/security/cve/CVE-2026-56851
security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_74536.json
bugzilla.redhat.com/show_bug.cgi?id=2547607
cve.org/CVERecord?id=CVE-2026-56851
nvd.nist.gov/vuln/detail/CVE-2026-56851
go.dev/cl/793360
go.dev/issue/80112
pkg.go.dev/vuln/GO-2026-6629
bugzilla.redhat.com/show_bug.cgi?id=2522418
cve.org/CVERecord?id=CVE-2026-76835