An unauthenticated remote attacker can bypass authentication in OAuth2 Proxy versions 7.15.2 through 7.15.4 by manipulating the X-Forwarded-Uri header. The vulnerability, tracked as CVE-2026-76835, carries a CVSS score of 9.1 and is classified under CWE-290: Authentication Bypass by Spoofing. The mechanism is straightforward: an attacker sends a request to a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route — /health, /metrics, /ping. OAuth2 Proxy evaluates the skip-auth condition against the spoofed header. The upstream service receives the protected path unchanged.
This bypass is a direct successor to CVE-2026-40575, which affected versions 7.5.0 through 7.15.1 and exploited the same X-Forwarded-Uri trust relationship. Maintainers patched the original flaw in version 7.15.2 by introducing the --trusted-proxy-ip flag, designed to restrict which source IPs could supply forwarded headers. The fix did not hold. To preserve backwards compatibility, the flag defaults to 0.0.0.0/0 — every IP address is trusted. Because GetRequestURI in pkg/requests/util/util.go prefers the X-Forwarded-Uri header whenever CanTrustForwardedHeaders returns true, and every IP passes that check under the default, the guard is inert. The patch shipped; the protection did not.
Three conditions must converge for exploitation: --reverse-proxy must be enabled, at least one --skip-auth-route or --skip-auth-regex rule must be configured, and --trusted-proxy-ip must remain unset. Deployments matching this profile are common in Kubernetes ingress architectures and multi-tenant SaaS backends where OAuth2 Proxy sits behind a load balancer.
The fix arrived on October 1, 2026, with version 7.15.5. The release tightened skip-auth path matching to reject ambiguous or crafted paths — dot segments, double slashes, matrix parameters — before evaluating exemptions. It also hardened client-IP header resolution against spoofing and closed a credential disclosure path through OAuth callback error logging.
As of this writing, there is no confirmed exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, nor has it been indexed in the National Vulnerability Database. It does not yet have a dedicated GitHub Security Advisory page; the details are tracked under the existing advisory for CVE-2026-40575.
For operators, remediation is three-layered. Set --trusted-proxy-ip to the specific IP addresses or CIDR ranges of your reverse proxies — do not leave it at the default. Strip any client-supplied X-Forwarded-Uri header at the edge load balancer before it reaches OAuth2 Proxy. Alternatively, overwrite the header with the actual request path: in Nginx, proxy_set_header X-Forwarded-Uri $request_uri.
This is the eighth time in three weeks this desk has documented the same structural failure: a federation or proxy layer trusting a client-supplied claim without binding it to the actual request context. Budibase OIDC/SSO (Post 132121) trusted the IdP’s email assertion for invite matching. Citrix NetScaler SAML (Post 132019) shipped a fix that sat inside the next vulnerability’s affected range. The trend synthesis (Post 132155) traced the scale of the pattern across the enterprise auth stack. OAuth2 Proxy adds a new layer: the reverse proxy itself, where the security control defaulted to trusting everyone. A fix that requires manual hardening to function is not a fix — it is an option that most deployments will not exercise.