OpenShift OAuth Proxy CVE-2026-49331

Exploitation requires that the target OpenShift oauth-proxy deployment is configured with at least one skip-auth-regex rule that matches an accessible URL path - this is a non-default, operator-defined configuration. The upstream application behind the proxy must also trust the X-Forwarded-User, X-Forwarded-Email, or X-Forwarded-Access-Token headers as authoritative identity signals without independently verifying them. Exploitation is limited to the specific paths matched by skip-auth-regex; authenticated paths are unaffected because the proxy handles and reasserts identity on those paths. There is no required user interaction and no authentication is needed from the attacker's perspective (per CVSS PR:N). Deployments where upstream applications perform their own authentication or ignore forwarded identity headers are not materially affected.

The CVSS 6.5 score (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) reflects meaningful real-world risk: the attack is fully network-accessible, requires no authentication, no user interaction, and no elevated complexity. However, the scope is unchanged (S:U) and impact is bounded to Low confidentiality and Low integrity, because exploitation is constrained to paths explicitly whitelisted for authentication bypass - paths that are by design exposed without credentials. The realistic blast radius depends heavily on what those upstream endpoints do: if they perform sensitive reads or writes based on identity headers, impact could be significantly higher in practice than the base score implies. No EPSS data was provided in source intelligence; no CISA KEV listing is present, and no POC has been identified, suggesting no confirmed widespread exploitation. The primary risk signal is the ease of exploitation (PR:N, AC:L) once an attacker identifies a skip-auth-regex path, combined with the likelihood that upstream services implicitly trust forwarded identity headers in OpenShift-native deployments.

An unauthenticated external attacker enumerates or guesses a URL path that matches the operator's skip-auth-regex pattern (e.g., /healthz or /public/). The attacker then sends an HTTP request to that path with a crafted X-Forwarded-User: admin@corp.example.com header. Because the oauth-proxy forwards the request without stripping the header, the upstream application receives and trusts the forged identity, granting the attacker access to functionality or data scoped to the impersonated user. No public POC has been identified at time of analysis.