Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-24T18:17:21.570Z",
  "pubdate": "2026-08-24T18:17:21.570Z",
  "executiveSummary": "OAuth2 Proxy suffers from an authentication bypass vulnerability where the application improperly honors a client-supplied X-Forwarded-Uri header when evaluating whether a request is permitted to skip authentication.\nThis flaw arises because the mitigation introduced for CVE-2026-40575 remains inert under the default reverse-proxy configuration.\nThe impact allows unauthenticated remote attackers to completely bypass access controls and query protected upstream paths without presenting valid credentials.\nThe affected system is OAuth2 Proxy when operating in reverse proxy mode without an explicitly configured trusted_proxy_ip directive.\nThe risk implications are severe, as any external client is implicitly trusted due to fallback mechanisms, effectively stripping authentication boundaries for protected resources.\nThe attacker capabilities require no prior authentication or privileges; the attacker merely needs network access to the proxy and the ability to inject custom HTTP headers such as X-Forwarded-Uri.\nExploitation requirements are minimal, relying entirely on the default insecure trust posture of the proxy configuration where the trusted proxy IP network set defaults to allow-listing all IP addresses.",
  "technicalDetails": "The root cause of the vulnerability resides in the interaction between header processing logic, trust evaluation routines, and path authorization checks within OAuth2 Proxy.\nSpecifically, the function GetRequestURI located in pkg/requests/util/util.go prioritizes the client-supplied X-Forwarded-Uri header over the actual request URI whenever the function CanTrustForwardedHeaders evaluates to true.\nThe evaluation function CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants trust if the caller address exists within the configured trusted proxy set.\nHowever, the function buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs—which explicitly includes 0.0.0.0/0 and ::/0—whenever reverse proxy mode is enabled and trusted_proxy_ip has not been explicitly configured by an administrator.\nConsequently, every incoming client connection is dynamically treated as originating from a trusted proxy.\nSubsequent authorization evaluations handled by isAllowedPath in oauthproxy.go compare the skip_auth_routes and skip_auth_regex allow lists against this spoofed request path derived from the manipulated X-Forwarded-Uri header.\nThe step-by-step attack flow proceeds as follows: an unauthenticated attacker transmits an HTTP request directed at a protected upstream path.\nSimultaneously, the attacker injects a spoofed X-Forwarded-Uri header containing a value that matches a configured allow-listed route within skip_auth_routes or skip_auth_regex.\nBecause CanTrustForwardedHeaders returns true due to the overly broad default network range, GetRequestURI extracts and accepts the spoofed header value.\nThe proxy evaluates the isAllowedPath check against the spoofed path, determines that the route is permitted to skip authentication, and forwards the original, protected upstream path unchanged to the backend service.\nThis mechanism completely subverts the security guard introduced to address CVE-2026-40575, rendering authentication checks inert under default deployment parameters."
}