CVE-2025-64484: OAuth2-Proxy Auth Bypass Vulnerability

CVE-2025-64484 Overview

CVE-2025-64484 affects OAuth2-Proxy, an open-source reverse proxy and middleware component used to add authentication and authorization in front of upstream applications. The vulnerability exists in versions prior to 7.13.0 and allows authenticated users to inject underscore variants of X-Forwarded-* headers that bypass the proxy's header filtering logic. Upstream frameworks that normalize underscores to dashes in HTTP headers — including Django, Flask, FastAPI, and PHP-based applications — accept these forged headers as legitimate. This enables privilege escalation within the upstream application. OAuth2-Proxy's authentication and authorization flows themselves remain intact.

Critical Impact

Authenticated attackers can spoof identity and forwarded-address headers to escalate privileges in upstream applications that treat X_Forwarded-For and X-Forwarded-For as equivalent.

Affected Products

• OAuth2-Proxy versions prior to 7.13.0
• Deployments fronting WSGI-based frameworks (Django, Flask, FastAPI)
• Deployments fronting PHP applications that normalize header underscores to dashes

Discovery Timeline

• 2025-11-10 - CVE-2025-64484 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-64484

Vulnerability Analysis

The flaw is an Improper Neutralization of HTTP Headers for Scripting Syntax issue [CWE-644]. OAuth2-Proxy strips and rewrites a defined set of X-Forwarded-* headers before passing requests to upstream services. The filtering logic performs case-insensitive matching but treats underscores and dashes as distinct characters. An authenticated client can submit a header such as X_Forwarded-For or X_Forwarded_User, which OAuth2-Proxy does not recognize as a forwarded-identity header and therefore forwards unchanged.

Upstream frameworks built on WSGI or PHP follow common server conventions that fold underscores and dashes together when exposing headers to application code. The attacker-supplied X_Forwarded-User header arrives at the upstream as X-Forwarded-User, overriding the trusted value set by the proxy. The upstream application then makes authorization decisions based on attacker-controlled input.

Root Cause

The root cause is inconsistent header name normalization between OAuth2-Proxy and downstream HTTP frameworks. The proxy's strip list only matched canonical hyphenated names, while WSGI and PHP runtimes coerce _ to - when populating environment variables and request objects. This mismatch creates a parser-differential condition that defeats the trust boundary the proxy is meant to enforce.

Attack Vector

An authenticated user crafts an HTTP request that includes an underscore-variant header, for example X_Forwarded-Email: admin@example.com or X_Forwarded-Groups: administrators. OAuth2-Proxy's filter does not strip the header because it does not match the configured dash-form name. The request reaches the upstream application, which reads the header through its normalized request interface and treats the value as authoritative identity or group membership data. The attacker thereby impersonates other users or claims elevated group memberships without compromising the OAuth2 authentication exchange itself.

No proof-of-concept exploitation code has been published in the referenced advisories. Technical details are available in the GitHub Security Advisory GHSA-vjrc-mh2v-45x6 and the Telekom analysis of HTTP header smuggling.

Detection Methods for CVE-2025-64484

Indicators of Compromise

• Inbound HTTP requests containing headers with underscores in the X_Forwarded-* family, such as X_Forwarded-User, X_Forwarded-Email, X_Forwarded-Groups, or X_Forwarded-For.
• Upstream application logs showing identity or group values that do not match the OAuth2-Proxy session for the same request ID.
• Discrepancies between OAuth2-Proxy access logs and downstream audit logs for the authenticated principal.

Detection Strategies

• Inspect HTTP traffic at the edge or in upstream access logs for header names containing _ followed by Forwarded, User, Email, Groups, or Access-Token.
• Correlate authentication events emitted by OAuth2-Proxy with the identity claims observed by the upstream application. Mismatches indicate header spoofing.
• Add WAF or ingress controller rules that explicitly reject or alert on request headers matching the regex ^X_[A-Za-z-]+.

Monitoring Recommendations

• Enable verbose request header logging on upstream applications during incident triage to capture the raw header names received.
• Monitor OAuth2-Proxy version inventory across clusters to confirm all instances run 7.13.0 or later.
• Alert on authorization decisions where the principal identifier differs from the OAuth2-Proxy session identifier within the same request trace.

How to Mitigate CVE-2025-64484

Immediate Actions Required

• Upgrade OAuth2-Proxy to version 7.13.0 or later, which normalizes both capitalization and underscore-versus-dash differences when matching headers to strip.
• Audit upstream applications for any code paths that trust X-Forwarded-* headers for identity, authorization, or source-address decisions.
• Reject inbound requests at the ingress layer that contain HTTP headers with underscores in identity-related names.

Patch Information

The fix is included in OAuth2-Proxy v7.13.0. By default, all specified headers are now normalized so that X-Forwarded-For and X_Forwarded-for are treated as equivalent and stripped. Maintainers added a new AlphaConfig field, InsecureSkipHeaderNormalization, for operators who require the previous behavior. Full release details are available in the OAuth2-Proxy GitHub Security Advisory.

Workarounds

• Configure upstream services so that header filtering and parsing logic does not treat underscores and hyphens as equivalent.
• Place a WAF or ingress filter in front of OAuth2-Proxy that drops any client-supplied header beginning with X_ before the request reaches the proxy.
• Restrict trusted forwarded-header processing in upstream applications to a fixed list of canonical, hyphenated names read from a server-controlled source rather than the request.

# Example NGINX ingress rule to drop client-supplied underscore-variant identity headers
more_clear_input_headers 'X_Forwarded-For' 'X_Forwarded-User' 'X_Forwarded-Email' 'X_Forwarded-Groups' 'X_Forwarded-Access-Token' 'X_Forwarded-Preferred-Username';

# Optionally reject any header name containing an underscore before it reaches OAuth2-Proxy
if ($http_name ~* "^X_") { return 400; }