CVE-2026-76835
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk37th percentile - higher than 37% of all known CVEs
Summary
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 prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders 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.
Risk Assessment
An unauthenticated attacker can bypass authentication and access protected resources, potentially leading to confidentiality and integrity breaches.
Recommendation
Configure trusted_proxy_ip with a list of trusted proxy addresses or update OAuth2 Proxy to a version that fixes the issue, preventing trust in the X-Forwarded-Uri header in default configuration.
Other vulnerabilities in OAuth2 Proxy
See all- CVE-2017-1000069High
CVE-2017-1000069 describes a CSRF vulnerability in oauth2_proxy version 2.1 that can occur during the authentication flow.
- CVE-2026-40575Critical
OAuth2 Proxy 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 to bypass authentication and access protected routes without a valid session.
- CVE-2026-34457Critical
OAuth2 Proxy prior to version 7.15.2 contains an authentication bypass vulnerability in deployments using auth_request (e.g., nginx auth_request) with --ping-user-agent or --gcp-healthchecks enabled. The vulnerability allows access to protected upstream resources without authentication.
- CVE-2026-34454Low
A regression introduced in OAuth2 Proxy 7.11.0 prevents clearing the session cookie when rendering the sign-in page. In deployments relying on the sign-in page as part of the logout flow, a user may be shown the sign-in page while the existing session cookie remains valid, meaning the browser session is not actually logged out. On shared workstations, a subsequent user could continue the previous user's authenticated session. This is fixed in version 7.15.2.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS