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 --skipauthroutes or 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-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

Example 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. proxysetheader Host $host; proxysetheader X-Real-IP $remoteaddr; # set the value to the actual $requesturi and therefore strip any user provided X-Forwarded-Uri proxysetheader X-Forwarded-Uri $requesturi; proxypass 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-regex rules where possible

OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 have a configuration-dependent authentication bypass. Deployments are affected when all of the following are true: Use of skipauthroutes or the legacy skipauthregex; use of patterns that can be widened by attacker-controlled suffixes, such as ^/foo/./bar$ causing potential exposure of /foo/secret; and protected upstream applications that interpret # as a fragment delimiter or otherwise route the request to the protected base path. In deployments that rely on these settings, an unauthenticated attacker can send a crafted request containing a number sign in the path, including the browser-safe encoded form %23, so that OAuth2 Proxy matches a public allowlist rule while the backend serves a protected resource. Deployments that do not use these skip-auth options, or that only allow exact public paths with tightly scoped method and path rules, are not affected. A fix has been implemented in version 7.15.2 to normalize request paths more conservatively before skip-auth matching so fragment content does not influence allowlist decisions. Users who cannot upgrade immediately can reduce exposure by tightening or removing skipauthroutes and skipauthregex rules, especially patterns that use broad wildcards across path segments. Recommended mitigations include replacing broad rules with exact, anchored public paths and explicit HTTP methods; rejecting requests whose path contains %23 or # at the ingress, load balancer, or WAF level; and/or avoiding placing sensitive application paths behind broad skipauthroutes rules.