oauth-proxy EUVD-2026-90589

Exploitation requires the attacker to deliver a specially crafted link (containing an attacker-controlled rd redirect-destination parameter) to a victim who must click it and complete authentication through the OpenShift oauth-proxy login flow - this user interaction (UI:R) is the primary limiting factor. No special non-default configuration is indicated; the flaw lies in oauth-proxy's default failure to validate the rd parameter during post-login redirection. No attacker authentication is needed (PR:N), but the attack yields only a browser redirect to an arbitrary external site, so real impact depends on the victim being successfully socially engineered into trusting the subsequent attacker-controlled page.

This is a textbook open-redirect (CWE-601) in oauth-proxy, the authentication proxy sidecar used across Red Hat OpenShift Container Platform 4. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 Medium) is internally consistent with the description: network-reachable, no authentication, but requiring the victim to click a crafted link (UI:R), with only limited confidentiality/integrity impact and a scope change because the proxy redirects the browser to an attacker-controlled external origin. No EPSS score, CISA KEV listing, or public proof-of-concept was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Real-world risk is genuinely moderate-to-low in isolation: an open redirect does not by itself compromise the cluster or the proxy - its value is as a phishing/credential-theft force-multiplier that lends a trusted OpenShift login hostname to an attacker's malicious destination. The signals do not conflict (CVSS network vector matches the described remote link-based attack), but note the key missing signals - no EPSS, KEV, or POC data was supplied - so prioritization should treat this as a lower-tier hardening fix rather than an emergency, weighted by how exposed the cluster's oauth-proxy login endpoint is to untrusted users.

An attacker crafts a link to a legitimate OpenShift oauth-proxy login endpoint with a malicious rd destination parameter pointing to an attacker-controlled site, then sends it to a victim via phishing. After the victim authenticates against the trusted OpenShift domain, oauth-proxy redirects their browser to the external attacker site, which mimics the login or a follow-on page to harvest credentials or tokens. No public exploit code was provided in the input, and exploitation requires the victim to click the link (UI:R).