CVE Intelligence

Oauth2-proxy Oauth2-proxy vulnerabilities

🔔 Create alert RSS Version checker

Published CVEs affecting Oauth2-proxy Oauth2-proxy: 7 record(s), with affected versions and fixes.

CVE-2026-76835 Critical · 9.1 CWE-290 Aug 24, 2026
OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
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.
CVE-2026-41059 High · 8.2 CWE-288 Apr 21, 2026
OAuth2 Proxy has an Authentication Bypass via Fragment Confusion in skip_auth_routes and skip_auth_regex
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 `skip_auth_routes` or the legacy `skip_auth_regex`; 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 `skip_auth_routes` and `skip_auth_regex` 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 `skip_auth_routes` rules.
CVE-2026-40575 Critical · 9.1 CWE-290 Apr 21, 2026
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
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.
CVE-2026-40574 Medium · 6.8 CWE-863 Apr 21, 2026
OAuth2 Proxy has an Authorization Bypass in Email Domain Validation via Malformed Multi-@ Email Claims
OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Prior to 7.15.2, an authorization bypass exists in OAuth2 Proxy as part of the email_domain enforcement option. An attacker may be able to authenticate with an email claim such as attacker@evil.com@company.com and satisfy an allowed domain check for company.com, even though the claim is not a valid email address. The issue ONLY affects deployments that rely on email_domain restrictions and accept email claim values from identity providers or claim mappings that do not strictly enforce normal email syntax. This vulnerability is fixed in 7.15.2.
CVE-2026-34457 Critical · 9.1 CWE-290 Apr 14, 2026
OAuth2 Proxy: Health Check User-Agent Matching Bypasses Authentication in auth_request Mode
OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions prior to 7.15.2 contain a configuration-dependent authentication bypass in deployments where OAuth2 Proxy is used with an auth_request-style integration (such as nginx auth_request) and either --ping-user-agent is set or --gcp-healthchecks is enabled. In affected configurations, OAuth2 Proxy treats any request with the configured health check User-Agent value as a successful health check regardless of the requested path, allowing an unauthenticated remote attacker to bypass authentication and access protected upstream resources. Deployments that do not use auth_request-style subrequests or that do not enable --ping-user-agent/--gcp-healthchecks are not affected. This issue is fixed in 7.15.2.
CVE-2026-34454 Low · 3.5 CWE-384 Apr 14, 2026
OAuth2 Proxy: Session cookie not cleared when rendering sign-in page
OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. A regression introduced in 7.11.0 prevents OAuth2 Proxy from clearing the session cookie when rendering the sign-in page. In deployments that rely on the sign-in page as part of their logout flow, a user may be shown the sign-in page while the existing session cookie remains valid, meaning the browser session is not actually logged out. On shared workstations or devices, a subsequent user could continue to use the previous user's authenticated session. Deployments that use a dedicated logout/sign-out endpoint to terminate sessions are not affected. This issue is fixed in 7.15.2
CVE-2025-64484 High · 8.5 CWE-644 Nov 10, 2025
OAuth2-Proxy vulnerable to header smuggling via underscore, leading to potential privilege escalation
OAuth2-Proxy is an open-source tool that can act as either a standalone reverse proxy or a middleware component integrated into existing reverse proxy or load balancer setups. In versions prior to 7.13.0, all deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications). Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised. The problem has been patched with v7.13.0. By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away. For those who have a rational that requires keeping a similar looking header and not stripping it, the maintainers introduced a new configuration field for Headers managed through the AlphaConfig called `InsecureSkipHeaderNormalization`. As a workaround, ensure filtering and processing logic in upstream services don't treat underscores and hyphens in Headers the same way.