Apr 14, 2026·5 min read·7 visits
Unauthenticated remote authentication bypass in OAuth2 Proxy (< 7.15.2) due to permissive health check User-Agent validation in auth_request deployments. Fixed in 7.15.2.
OAuth2 Proxy versions prior to 7.15.2 are vulnerable to a critical authentication bypass (CWE-290) when configured with User-Agent-based health checks in an auth_request architecture. An unauthenticated remote attacker can spoof the health check User-Agent header to bypass authorization checks entirely, gaining access to protected upstream resources.
OAuth2 Proxy is a reverse proxy and authorization service that provides authentication using various OAuth2 providers. It is frequently deployed alongside frontend web servers to secure internal applications and APIs. The proxy evaluates incoming requests, validates session tokens, and either permits or denies access to the protected upstream resources.
CVE-2026-34457 is an authentication bypass vulnerability (CWE-290) affecting OAuth2 Proxy versions prior to 7.15.2. The flaw exists within the health check routing logic, specifically when the proxy is configured to identify health checks using the HTTP User-Agent header. This behavior is enabled via the --ping-user-agent or --gcp-healthchecks configuration flags.
When deployed in an auth_request architecture, the vulnerability allows an unauthenticated remote attacker to bypass all authorization checks. The attacker achieves this by supplying a crafted User-Agent header matching the configured health check string. This results in the complete exposure of all downstream applications protected by the vulnerable OAuth2 Proxy instance.
The vulnerability originates from an overly permissive evaluation of incoming requests designated as health checks. OAuth2 Proxy includes functionality to exempt specific monitoring requests from authentication. This mechanism ensures that infrastructure load balancers can verify service availability without possessing valid OAuth2 session tokens.
When the --ping-user-agent or --gcp-healthchecks flags are utilized, the application logic evaluates the User-Agent header of the incoming HTTP request. If the header exactly matches the configured string, the proxy classifies the request as an authorized health check. The application performs this classification irrespective of the requested URI path, creating a fundamental access control breakdown.
In a standard deployment utilizing the Nginx auth_request module, Nginx intercepts the client request and generates a subrequest to OAuth2 Proxy to validate authorization. The client-provided User-Agent header is forwarded within this subrequest. Because OAuth2 Proxy observes the designated health check string, it returns an HTTP 200 OK response to the frontend proxy.
Nginx processes the 200 OK response as confirmation that the client is fully authenticated and authorized. Consequently, Nginx proxies the original HTTP request directly to the protected upstream application. The failure to bind the User-Agent health check exemption strictly to a dedicated endpoint, such as /ping, establishes the bypass condition.
Exploitation of CVE-2026-34457 requires low attack complexity and zero prior authentication. The attacker must possess network connectivity to the frontend web server routing traffic to the vulnerable OAuth2 Proxy deployment. The target deployment must actively utilize the subrequest-based auth_request integration methodology.
The attack payload consists of a standard HTTP request directed at a protected URI, modified to include the specific User-Agent header expected by the health check configuration. For instances deployed within Google Cloud Platform environments utilizing the --gcp-healthchecks flag, the default expected string is GoogleHC/1.0.
curl -H "User-Agent: GoogleHC/1.0" https://protected-app.example.com/api/v1/sensitive-dataIf the administrator has specified a custom monitoring string via the --ping-user-agent flag, the attacker must supply that precise string. Discovery of custom strings may require directory brute-forcing, error analysis, or prior knowledge of the target organization's internal monitoring infrastructure. Once the correct string is identified, subsequent requests bypass authentication deterministically.
Successful exploitation grants the attacker unauthenticated read and write access to the upstream resources protected by OAuth2 Proxy. The severity of the impact is directly correlated with the sensitivity of the applications residing behind the proxy boundary. Common deployments protect internal administrative dashboards, continuous integration servers, and internal API endpoints.
The CVSS v3.1 base score of 9.1 reflects the network-based attack vector, the lack of required privileges, and the high impact on both confidentiality and integrity. The vulnerability nullifies the primary security control established by the proxy, exposing internal applications to external threat actors.
The availability of the upstream service is not directly impacted by this vulnerability, as the attack leverages standard HTTP proxying mechanics. However, an attacker will likely impact availability through subsequent actions performed on the exposed applications, such as executing destructive database queries or modifying administrative configurations.
The primary remediation for CVE-2026-34457 is to upgrade the OAuth2 Proxy deployment to version 7.15.2 or later. The patched release modifies the health check routing logic to strictly validate the requested URI path. Health check exemptions are no longer granted solely based on the evaluation of the User-Agent header.
Organizations unable to apply the software update immediately must implement configuration-based mitigations. Administrators must remove the --ping-user-agent flag and disable the --gcp-healthchecks flag. This action removes the vulnerable code path entirely and neutralizes the authorization bypass.
Following the removal of User-Agent exemptions, health checks must be transitioned to utilize path-based routing. Administrators must configure upstream load balancers and monitoring systems to query the dedicated /ping endpoint. Nginx and other frontend proxies must be explicitly configured to route requests for /ping directly to OAuth2 Proxy without triggering an auth_request loop.
# Secure Nginx Configuration Example
location = /ping {
proxy_pass http://oauth2_proxy_backend;
# auth_request must NOT be applied to this location
}CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
OAuth2 Proxy OAuth2 Proxy | < 7.15.2 | 7.15.2 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-290 |
| Attack Vector | Network |
| CVSS Score | 9.1 (Critical) |
| Impact | Authentication Bypass |
| Exploit Status | PoC Available |
| Required Configuration | auth_request + UA Health Checks |
The system relies on an easily spoofed attribute (in this case, the HTTP User-Agent header) to grant privileges or bypass authentication.