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.

Impact

An authorization bypass exists in OAuth2 Proxy as part of the emaildomain 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 emaildomain restrictions and accept email claim values from identity providers or claim mappings that do not strictly enforce normal email syntax. The practical risk ONLY exists in self-hosted or custom OIDC environments and federated setups where unexpected claim values can reach oauth2-proxy. Standard hosted providers that enforce valid email formatting ARE NOT effected.

Patches Users should upgrade to v7.15.2 or later once available.

Workarounds The most effective workaround is to ensure the configured identity provider cannot emit malformed or attacker-controlled email claim values.

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

Impact A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

- OAuth2 Proxy is used with an authrequest-style integration (for example, nginx authrequest) - --ping-user-agent is set or --gcp-healthchecks is enabled

In affected configurations, OAuth2 Proxy will treat a request with the configured health check User-Agent value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.

This issue does not affect deployments that do not use authrequest-style subrequests, or that do not enable --ping-user-agent/--gcp-healthchecks.

Patches Users should upgrade to v7.15.2 or later once available. Deployments running versions prior to v7.15.2 should be considered affected if they use authrequest-style authentication together with --ping-user-agent or --gcp-healthchecks.

Workarounds Users can mitigate this issue by:

- disabling --gcp-healthchecks - removing any configured --ping-user-agent - ensuring the reverse proxy does not forward client-controlled User-Agent headers to the OAuth2 Proxy auth subrequest - using path-based health checks only, on dedicated health check endpoints

Example nginx mitigation for the auth subrequest:

nginx location = /oauth2/auth { internal; proxypass http://127.0.0.1:4180; proxypassrequestbody off; proxysetheader Content-Length ""; proxysetheader Host $host; # set to value that isn't the same as your configured PingUserAgent or GCPs "GoogleHC/1.0" proxysetheader User-Agent "oauth2-proxy-auth-request"; }

Impact A regression introduced in v7.11.0 is preventing OAuth2 Proxy from clearing the session cookie when rendering the sign-in page.

This only impacts deployments that rely on the sign-in page as part of their logout flow. In those setups, a user may be shown the sign-in page while the existing session cookie remains valid, so the browser session is not actually logged out. On shared workstations be it browsers 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.

Patches This issue is fixed in v7.15.2.

Workarounds Do not rely on the sign-in page to clear an existing session. Instead:

- Use the dedicated logout/sign-out endpoint of OAuth2 Proxy - Ensure your application logout flow explicitly clears the OAuth2 Proxy session cookie before redirecting users to the sign-in page - If needed, clear the session cookie at the reverse proxy or application layer as a temporary mitigation

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 an open source reverse proxy that provides authentication with Google, Github or other providers. The --gitlab-group flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release. Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in --gitlab-group added to the new X-Forwarded-Groups header to the upstream application. While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the --gitlab-group config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed. This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of --gitlab-group membership restrictions. This is patched in v7.1.0. There is no workaround for the Group membership bug. But --gitlab-project can be set to use Project membership as the authorization checks instead of groups; it is not broken.

OAuth2 Proxy is an open-source reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group. In OAuth2 Proxy before version 7.0.0, for users that use the whitelist domain feature, a domain that ended in a similar way to the intended domain could have been allowed as a redirect. For example, if a whitelist domain was configured for ".example.com", the intention is that subdomains of example.com are allowed. Instead, "example.com" and "badexample.com" could also match. This is fixed in version 7.0.0 onwards. As a workaround, one can disable the whitelist domain feature and run separate OAuth2 Proxy instances for each subdomain.

In OAuth2 Proxy from version 5.1.1 and less than version 6.0.0, users can provide a redirect address for the proxy to send the authenticated user to at the end of the authentication flow. This is expected to be the original URL that the user was trying to access. This redirect URL is checked within the proxy and validated before redirecting the user to prevent malicious actors providing redirects to potentially harmful sites. This has been fixed in version 6.0.0.

Impact As users can provide a redirect address for the proxy to send the authenticated user to at the end of the authentication flow. This is expected to be the original URL that the user was trying to access. This redirect URL is checked within the proxy and validated before redirecting the user to prevent malicious actors providing redirects to potentially harmful sites.

However, by crafting a redirect URL with HTML encoded whitespace characters (eg. %0a, %0b,%09,%0d) the validation could be bypassed and allow a redirect to any URL provided.

Patches @rootxharsh and @iamnoooob provided this patch as potential solution: From 4b941f56eda310b5c4dc8080b7635a6bfabccad4 Mon Sep 17 00:00:00 2001 From: Harsh Jaiswal <harsh@pop-os.localdomain> Date: Fri, 1 May 2020 20:38:31 +0530 Subject: [PATCH] Fixes redirect issue

--- oauthproxy.go | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/oauthproxy.go b/oauthproxy.go index 1e9bb7c..f8beb4d 100644 --- a/oauthproxy.go +++ b/oauthproxy.go @@ -577,8 +577,9 @@ func validOptionalPort(port string) bool {

// IsValidRedirect checks whether the redirect URL is whitelisted func (p OAuthProxy) IsValidRedirect(redirect string) bool { + matched, := regexp.MatchString(^/\s+/|\\, redirect) switch { - case strings.HasPrefix(redirect, "/") && !strings.HasPrefix(redirect, "//") && !strings.HasPrefix(redirect, "/\\"): + case strings.HasPrefix(redirect, "/") && !strings.HasPrefix(redirect, "//") && !matched: return true case strings.HasPrefix(redirect, "http://") || strings.HasPrefix(redirect, "https://"): redirectURL, err := url.Parse(redirect) -- 2.17.1

This issue was also reported to us separately by @mik317 several hours later

The fix was implemented in #xxx and released as version 5.1.1

OAuth2 Proxy before 5.0 has an open redirect vulnerability. Authentication tokens could be silently harvested by an attacker. This has been patched in version 5.0.

CSRF in Bitly oauth2proxy 2.1 during authentication flow

The Bitly oauth2proxy in version 2.1 and earlier was affected by an open redirect vulnerability during the start and termination of the 2-legged OAuth flow. This issue was caused by improper input validation and a violation of RFC-6819