CVE-2026-34457: OAuth2 Proxy: Health Check User-Agent Matching Bypasses Authentication in auth_request Mode

Published Apr 14, 2026
·
Updated

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"; }

Other sources

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 authrequest-style integration (such as nginx authrequest) 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 authrequest-style subrequests or that do not enable --ping-user-agent/--gcp-healthchecks are not affected. This issue is fixed in 7.15.2.

MITRE

Affected Software

4 affected componentsFixes available
OAuth2 Proxy OAuth2 Proxy<7.15.2
go/github.com/oauth2-proxy/oauth2-proxy<=3.2.0
go/github.com/oauth2-proxy/oauth2-proxy/v7<7.15.2
7.15.2
Oauth2 Proxy Project Oauth2 Proxy<7.15.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/oauth2-proxy/oauth2-proxy/v7 to a version that resolves this vulnerability.

    Fixed in 7.15.2
  2. Upgrade

    Upgrade OAuth2 Proxy to a version that resolves this vulnerability.

    Fixed in v7.15.2
  3. Configuration

    In affected configurations, remove any configured --ping-user-agent value (or ensure it is not used) because OAuth2 Proxy treats requests matching this configured health-check User-Agent as successful health checks regardless of path.

    OAuth2 Proxy --ping-user-agent = (remove or do not set to the health-check User-Agent value)
  4. Configuration

    In affected configurations, disable --gcp-healthchecks because enabling it makes OAuth2 Proxy treat requests matching the health-check behavior as successful health checks regardless of path.

    OAuth2 Proxy --gcp-healthchecks = disabled
  5. Configuration

    Ensure the reverse proxy does not forward client-controlled User-Agent headers to the OAuth2 Proxy auth subrequest; only allow the reverse proxy to set the User-Agent so it cannot match the configured health-check User-Agent used by OAuth2 Proxy.

    Reverse proxy (nginx) -> OAuth2 Proxy auth subrequest User-Agent forwarded to auth_request subrequest = Do not forward client-controlled User-Agent (use a fixed non-health-check value)
  6. Compensating control

    For affected configurations, use path-based health checks only on dedicated health check endpoints (not using the auth_request-style OAuth2 Proxy auth subrequest).

Event History

Apr 14, 2026
CVE Published
via MITRE·10:14 PM
Data Sourced
via MITRE·10:14 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·10:31 PM
Data Sourced
via GitHub·10:31 PM
DescriptionSeverityWeaknessAffected Software
Data Sourced
via NVD·11:16 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:16 PM
Affected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-34457?

CVE-2026-34457 has a medium severity rating due to its potential to allow authentication bypass under certain configurations.

2

How do I fix CVE-2026-34457?

To fix CVE-2026-34457, upgrade to OAuth2 Proxy version 7.15.2 or later if using v7, or update to a secure version within the 3.2.x range.

3

What versions are affected by CVE-2026-34457?

CVE-2026-34457 affects OAuth2 Proxy versions prior to 7.15.2 for v7 and up to and including 3.2.0 for the 3.x series.

4

Can CVE-2026-34457 be exploited easily?

Exploitation of CVE-2026-34457 is dependent on specific deployment configurations which may expose the vulnerability.

5

Does CVE-2026-34457 affect all OAuth2 Proxy deployments?

No, CVE-2026-34457 only affects OAuth2 Proxy deployments that use 'auth_request' mode with misconfigured User-Agent checks.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203