CVE-2026-49332

CVE-2026-49332 is a header normalization bypass in oauth-proxy. The proxy correctly sets the authenticated user's identity in the X-Forwarded-User header (with a dash), but it treats X_Forwarded-User (with an underscore) as an untrusted client header and passes it through unchanged to the downstream application. When the request reaches a WSGI or PHP backend, both header variants normalize to the same internal key — the attacker-supplied underscore version overwrites the proxy-set dash version. The application receives the attacker's identity without any sign of tampering, because the proxy already authenticated the request and never sanitized the header channel it delegated identity-setting to. Check your deployment immediately: if oauth-proxy sits in front of any application that reads X-Forwarded-User (or its normalized equivalents) to establish identity, you are affected. This includes Python/WSGI applications using frameworks like Flask, Django, or FastAPI that normalize HTTP header keys, and PHP applications running under Apache or Nginx. The proxy version 4.x through 5.x is vulnerable; check your running instance. Remediate at the proxy layer first: the fix is to strip underscore-prefixed variants of any header the proxy controls (X_Forwarded_User, X_Forwarded_Email, etc.) before forwarding. If you're using the standard oauth-proxy binary, upgrade to the patched version. For custom deployments, filter outbound headers with underscores in the name. But also harden the application layer as defense-in-depth. Never trust any header that the proxy 'should' have set without explicit validation. If your application reads X-Forwarded-User, verify it against the proxy's session state or re-validate the claim rather than treating the header as trusted by default. This is not optional — the proxy's guarantee is limited to authentication, not header integrity across the normalization boundary. One final note: the actual exploitability hinges on whether an attacker can inject arbitrary headers into requests that traverse oauth-proxy. If your ingress controller strips client-supplied headers, this remains theoretical. If you allow client-controlled headers through (common in some internal service-to-service meshes), treat this as actively exploitable. Assume the worse-case until you've verified your header filtering at the ingress point.

Reviewed through automated stages and approved by a human before publication.