Apache CXF EUVD-2026-95699

Exploitation requires the target application to use Apache CXF's STSTokenValidator or its Security Token Service (STS) with the validated-token cache enabled (WS-Security/WS-Trust token validation or renewal flows). The attacker must craft a token (UsernameToken or self-signed SAML Assertion) whose Java Arrays.hashCode/hashCode() value collides with an entry already present in that cache, so a legitimately validated token for the target identity must already be cached - a meaningful limiting factor. Deployments of Apache CXF that do not perform STS/STSTokenValidator-based token validation or that do not cache validated tokens are not exploitable. The weak 32-bit hash space makes the collision itself computationally feasible, but success is gated on the cache state above. Fixed in 4.2.4, 4.1.9, and 3.6.13.

Signals conflict and must be weighed together rather than taken from the headline score. The CVSS 3.1 base score is 9.1 (Critical) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, implying a remote, unauthenticated, low-complexity authentication bypass - a genuinely severe primitive (CWE-328, use of a weak non-cryptographic hash). Against that, EPSS is only 0.17% (6th percentile), there is no CISA KEV listing, and no public exploit code was identified in the provided sources, so exploitation is currently theoretical rather than observed. No SSVC decision framework data (exploitation/automatable/technical-impact) was supplied, so that dimension cannot be cross-referenced. The CVSS AC:L rating is arguably optimistic: real-world exploitation depends on CXF being deployed with STSTokenValidator or the STS using token caching AND on a legitimate validated token already residing in the cache to collide against - conditions not reflected in the base vector. Net assessment: this is a real, patch-worthy priority specifically for deployments using Apache CXF WS-Trust/STS token validation or renewal, but the low EPSS, absent KEV/POC, and feature-specific preconditions mean it is not yet broad-exploitation risk; environments not using STS token caching face substantially lower practical risk than the 9.1 suggests.

An attacker crafts a token - for example a UsernameToken or a self-signed SAML assertion - whose 32-bit Java hashCode collides with a token already cached as validated by CXF's STSTokenValidator or STS. CXF treats the cache hit as proof the token was validated and accepts it without password validation, signature trust verification, or an STS call, letting the attacker authenticate as another user and, via STS validation/renewal, obtain STS-signed tokens for that identity. No public exploit was identified at time of analysis; per the CVSS vector (PR:N) this is reachable by remote unauthenticated attackers, though a colliding cached entry must exist.