Apache CXF EUVD-2026-53859

Exploitation requires that the Apache CXF relying-party has been explicitly configured to accept self-issued OIDC ID tokens - this is a non-default setting that must be deliberately opted into by the application operator. Any CXF deployment using standard federated OIDC identity providers (Keycloak, Azure AD, Okta, Ping Identity, etc.) is not affected regardless of version. The attacker must be able to reach the OIDC-protected CXF service endpoint over the network, and must know or discover that the self-issued token acceptance mode is active. No authentication credentials are required to attempt exploitation - that is the nature of the bypass. Limiting factors include: the non-default configuration dramatically narrows the exposed population; prior reconnaissance is needed to confirm the feature is enabled; and internal-only deployments further reduce exposure.

No official CVSS vector or EPSS score was provided; all scoring is analyst-derived. This vulnerability is not listed in the CISA KEV catalog, and no public proof-of-concept has been identified at time of analysis. The most significant real-world risk limiter is the non-default configuration requirement: self-issued OIDC token acceptance must be explicitly enabled in CXF's relying-party setup. Standard federated deployments using external identity providers (Keycloak, Azure AD, Okta) are entirely unaffected. Organizations that have opted into self-issued OIDC should treat this as high priority given the complete authentication bypass potential and the low exploit complexity once the precondition is met. The gap between the broad CPE coverage (all versions) and the narrow practical attack surface (non-default feature) means aggregate exposure across the CXF user base is likely low, though individual affected deployments face severe impact.

An attacker aware that a target CXF service has self-issued OIDC token acceptance enabled crafts a JWT bearing arbitrary iss, sub, and aud claims with no valid expiry or sub_jwk binding, then submits it directly to the OIDC-protected CXF endpoint. The defective validator accepts the token without verifying any OIDC claims, granting the attacker an authenticated session as any chosen identity - including privileged users or administrators. No public proof-of-concept has been identified, but JWT construction is well-understood, making exploitation straightforward for an attacker with knowledge of the non-default configuration.