See how oauth2-proxy compares to other vendors in security performance
Impact This vulnerability affects oauth2-proxy deployments using the skipauthroutes configuration option with regex patterns. The vulnerability allows attackers to bypass authentication by crafting URLs with query parameters that satisfy the configured regex patterns, potentially gaining unauthorized access to protected resources.
The issue stems from skipauthroutes matching against the full request URI (path + query parameters) instead of just the path as documented. This discrepancy enables authentication bypass attacks where attackers append malicious query parameters to access protected endpoints.
Example Attack:
Configuration: skipauthroutes = [ "^/foo/./bar$" ] Intended behavior: Allow /foo/something/bar Actual vulnerability: Also allows /foo/criticalendpoint?param=/bar
Deployments using skipauthroutes with regex patterns containing wildcards or broad matching patterns are most at risk, especially when backend services ignore unknown query parameters.
Patches A patch has been released with version v7.11.0.
Workarounds
Immediate mitigations:
1. Review regex patterns: Audit all skipauthroutes configurations for overly permissive patterns 2. Use precise patterns: Replace wildcard patterns with exact path matches where possible 3. Anchor patterns: Ensure regex patterns are properly anchored (start with ^ and end with $) 4. Path-only matching: Consider implementing custom validation that strips query parameters before regex matching
Example secure configuration:
toml Instead of: "^/public/." Use specific paths: "^/public/assets$", "^/public/health$" skipauthroutes = ["^/public/assets$", "^/public/health$", "^/api/status$"]
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.