Headline
GHSA-7rh7-c77v-6434: OAuth2-Proxy has authentication bypass in oauth2-proxy skip_auth_routes due to Query Parameter inclusion
Impact
This vulnerability affects oauth2-proxy deployments using the skip_auth_routes
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 skip_auth_routes
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:
skip_auth_routes = [ "^/foo/.*/bar$" ]
- Intended behavior: Allow
/foo/something/bar
- Actual vulnerability: Also allows
/foo/critical_endpoint?param=/bar
Deployments using skip_auth_routes
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 release with version v7.11.0.
Workarounds
Immediate mitigations:
- Review regex patterns: Audit all
skip_auth_routes
configurations for overly permissive patterns - Use precise patterns: Replace wildcard patterns with exact path matches where possible
- Anchor patterns: Ensure regex patterns are properly anchored (start with
^
and end with$
) - Path-only matching: Consider implementing custom validation that strips query parameters before regex matching
Example secure configuration:
# Instead of: "^/public/.*"
# Use specific paths: "^/public/assets$", "^/public/health$"
skip_auth_routes = ["^/public/assets$", "^/public/health$", "^/api/status$"]
Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.