Apache CXF EUVD-2026-95697

Requires that the target deployment actually uses Apache CXF's OIDC relying-party component (the RP/redirect handling code path), and requires a victim to be lured into initiating/completing an authentication flow via an attacker-supplied link - exploitation is not fully automatic. The flaw triggers on both directly-encoded and double-encoded external URLs placed in the preserved state parameter, depending on which validation path executes. Limiting factors: victim user interaction is mandatory, the OIDC RP feature must be enabled, and impact is confined to redirection (and any OIDC data carried through it) rather than server compromise.

This is CWE-601 open redirect in Apache CXF's OIDC relying-party component, where attacker-controlled OIDC state parameters are preserved and reused as post-authentication redirect targets without validating that the decoded URI belongs to the RP's origin. No CVSS vector, EPSS score, KEV listing, or POC is present in the input, so quantitative risk signals are entirely absent and cannot be compared - exploitation status is therefore 'no public exploit identified at time of analysis.' Judged on mechanism alone this is a moderate, not critical, issue: open redirects require victim user interaction (clicking an attacker-crafted authentication link) and typically yield phishing or OAuth/OIDC authorization-code/token leakage rather than direct code execution. The absence of a vendor CVSS score and of any exploitation telemetry means this should be treated as a patch-on-normal-cadence item rather than an emergency, though in OIDC flows open redirects can escalate in value because the redirect can carry sensitive tokens/codes - verify with the Apache advisory whether token leakage is in scope.

An attacker crafts an authentication link to a legitimate Apache CXF OIDC relying party, embedding a directly-encoded or double-encoded external URL in the state parameter. A victim clicks the link, authenticates normally, and after successful login the RP redirects the browser to the attacker-controlled site, enabling credential phishing or leakage of OIDC authorization data. No public exploit code is identified in the provided data.