Apache CXF EUVD-2026-95700

Exploitable ONLY against Apache CXF services that use STSTokenValidator to validate SAML tokens with alwaysValidateToSts NOT set - that specific configuration is the precondition, so configurations that always forward to the STS are not affected. Exploitation further requires a race window: the attacker's forged assertion must be processed concurrently with a legitimate request whose trust-check succeeded, since the flaw is reading another request's result from a shared object. Limiting factors: dependence on this non-universal SAML/STS validation mode and the probabilistic timing of concurrent legitimate traffic reduce reliability, though no authentication or user interaction is needed (PR:N/UI:N).

Multiple signals point to a moderate, non-urgent priority. The NVD CVSS is 7.5 (AV:N/AC:L/PR:N/UI:N) implying trivially remote, unauthenticated exploitation, but the CWE-362 race-condition nature means real exploitation depends on winning a timing window against concurrent legitimate requests, which is better captured by AC:H than AC:L - the provided AC:L likely understates attack complexity. EPSS is low at 0.17% (6th percentile) and the flaw is NOT in CISA KEV, with no public exploit identified at time of analysis, so there is no evidence of active or widespread exploitation. A notable conflict: the published vector sets C:N/I:N/A:H (availability-only), yet the description describes a forged, untrusted-certificate-signed SAML assertion being accepted as trusted - that is an authentication/integrity bypass, not an availability loss. This impact mislabeling should be verified with the vendor advisory; if the integrity reading is correct, the true risk is unauthorized trust of forged tokens rather than denial of service. Net: a legitimately exploitable auth-validation flaw but gated by a narrow vulnerable configuration and a race window, so prioritize patching for affected SAML/STS deployments without treating it as an emergency.

An attacker repeatedly sends SAML assertions forged and signed with an untrusted certificate to a CXF service that uses STSTokenValidator without alwaysValidateToSts, timing them to coincide with legitimate requests being processed. Because the trust-check result is held in a single shared object, the attacker's request can read a concurrent legitimate request's 'trusted' result and have its forged assertion accepted without ever being sent to the STS. No public exploit code is identified at time of analysis.