CVE-2026-34457: OAuth2 Proxy Authentication Bypass Issue

CVE-2026-34457 Overview

CVE-2026-34457 is an authentication bypass vulnerability in OAuth2 Proxy, a widely-used reverse proxy that provides authentication using OAuth2 providers. This critical flaw allows unauthenticated remote attackers to bypass authentication controls and access protected upstream resources by exploiting a configuration-dependent weakness in health check handling.

The vulnerability exists in deployments where OAuth2 Proxy is used with an auth_request-style integration (such as nginx auth_request) and either the --ping-user-agent flag is set or --gcp-healthchecks is enabled. In these configurations, OAuth2 Proxy incorrectly treats any request containing the configured health check User-Agent value as a successful health check, regardless of the actual requested path. This design flaw allows attackers to simply spoof the User-Agent header to gain unauthorized access to protected resources.

Critical Impact

Unauthenticated remote attackers can completely bypass OAuth2 authentication by spoofing the health check User-Agent header, potentially gaining access to sensitive protected applications and data.

Affected Products

• OAuth2 Proxy versions prior to 7.15.2
• Deployments using auth_request-style integration (e.g., nginx auth_request)
• Configurations with --ping-user-agent or --gcp-healthchecks enabled

Discovery Timeline

• 2026-04-14 - CVE-2026-34457 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-34457

Vulnerability Analysis

This vulnerability (CWE-290: Authentication Bypass by Spoofing) exploits a fundamental flaw in how OAuth2 Proxy validates health check requests. The proxy is designed to allow health check endpoints to bypass authentication for monitoring and orchestration purposes. However, the implementation fails to properly scope this bypass to specific health check paths.

When an attacker sets the User-Agent header to match the configured health check value (either via --ping-user-agent or the default GCP health check agent), the proxy incorrectly assumes the entire request is a legitimate health check. This allows the request to pass through without authentication, regardless of whether it targets /ping, /ready, or any other protected path.

The attack surface is network-based and requires no authentication or user interaction, making it trivially exploitable in affected configurations. An attacker with network access to the OAuth2 Proxy can gain full access to any upstream resources that the proxy protects.

Root Cause

The root cause is improper validation logic in the health check authentication bypass mechanism. The proxy evaluates the User-Agent header before checking the request path, and a matching User-Agent causes the authentication check to be skipped entirely. The correct behavior should require both a matching User-Agent AND a valid health check path (/ping or /ready) for the authentication bypass to apply.

Attack Vector

The attack vector is network-based and straightforward to exploit. An attacker can craft HTTP requests with the spoofed User-Agent header to access any protected resource:

1. Reconnaissance: Identify that the target uses OAuth2 Proxy with nginx auth_request integration
2. Configuration Discovery: Determine if --ping-user-agent or --gcp-healthchecks is enabled (GCP health check agents are publicly documented)
3. Exploitation: Send requests to protected resources with the spoofed User-Agent header
4. Access: Bypass authentication entirely and interact with upstream applications

For GCP deployments, the health check User-Agent values are well-documented (GoogleHC/1.0), making exploitation even more straightforward. Custom --ping-user-agent values may require additional reconnaissance but provide no additional security.

Detection Methods for CVE-2026-34457

Indicators of Compromise

• Requests to protected application paths containing health check User-Agent strings (e.g., GoogleHC/1.0)
• Unusual access patterns to sensitive endpoints from non-health-check sources
• Authentication bypass events where protected resources are accessed without valid OAuth2 sessions
• Requests from external IP addresses containing internal health check User-Agent values

Detection Strategies

• Monitor access logs for requests with health check User-Agent values accessing non-health-check paths
• Implement anomaly detection for User-Agent header spoofing attempts
• Review OAuth2 Proxy logs for authentication bypass events correlated with health check User-Agent values
• Deploy web application firewalls (WAF) to detect and block User-Agent spoofing patterns

Monitoring Recommendations

• Enable detailed access logging on OAuth2 Proxy and upstream applications
• Create alerts for health check User-Agent strings appearing in requests to protected resources
• Monitor for unusual authentication bypass patterns in security information and event management (SIEM) systems
• Audit network traffic for requests originating outside expected health check infrastructure

How to Mitigate CVE-2026-34457

Immediate Actions Required

• Upgrade OAuth2 Proxy to version 7.15.2 or later immediately
• If immediate upgrade is not possible, disable --ping-user-agent and --gcp-healthchecks flags
• Review access logs for signs of exploitation
• Implement additional network-layer controls to restrict health check access to trusted sources only

Patch Information

The vulnerability is fixed in OAuth2 Proxy version 7.15.2. Organizations should upgrade to this version or later to remediate the vulnerability. The fix ensures that health check authentication bypass only applies to designated health check paths, not to arbitrary paths based solely on User-Agent matching.

For detailed release information, refer to the GitHub Release v7.15.2 and the GitHub Security Advisory GHSA-5hvv-m4w4-gf6v.

Workarounds

• Disable the --ping-user-agent flag if not strictly required for operations
• Disable --gcp-healthchecks and implement alternative health check mechanisms
• Restrict network access to OAuth2 Proxy health check endpoints using firewall rules or network policies
• Implement additional authentication layers at the upstream application level as defense in depth

# Example: Disable vulnerable health check options in OAuth2 Proxy configuration
# Remove or comment out these flags from your OAuth2 Proxy startup configuration:
# --ping-user-agent=<custom-agent>
# --gcp-healthchecks

# Instead, use network-level restrictions for health checks:
# In nginx, restrict /ping and /ready to internal networks only:
location = /oauth2/ping {
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://oauth2-proxy:4180;
}