Apache WSS4J CVE-2026-92899

Exploitable only against deployments that (1) have a nonce replay cache configured - which Apache CXF enables by default - and (2) use UsernameTokens with a password digest; other token types are unaffected. The attacker must first capture a valid authenticated request, requiring a network-interception or traffic-observation position (MITM/proxy/shared path), and the captured token is only usable until it expires, bounding the exploitation window. These factors - required traffic capture, digest-token-only scope, and time-limited validity - meaningfully limit exploitation despite the unauthenticated, network-reachable nature of the replay itself.

No CVSS vector, EPSS, KEV entry, or SSVC decision data was provided by any source, so risk must be reasoned from the description and vendor advisory (Apache rated it 'moderate'). This is a genuine authentication-replay flaw rather than a paper cut: the nonce replay cache stored the raw base64 text of the Nonce while authentication decoded and verified the bytes, so re-encoding the same bytes (e.g. adding a space) produced a token that still passed the password-digest check but no longer matched the remembered value, defeating replay protection. Because a UsernameToken does not sign the message body, a single captured authenticated request can be replayed against arbitrary attacker-chosen operations until the token expires - effectively time-bounded impersonation. The mitigating reality is that exploitation requires the attacker to first capture a valid authenticated request (a network-interception/MITM precondition), the deployment must have a nonce replay cache configured (Apache CXF does by default), and only password-digest tokens are affected. Exploitation status: no public exploit identified at time of analysis, and there is no evidence of active exploitation. Net: a real, credible integrity/impersonation issue for affected SOAP deployments, but gated by traffic-capture and configuration conditions rather than a trivially wormable network bug - patch promptly but it is not an emergency mass-exploitation candidate.

An attacker positioned to observe SOAP traffic (e.g. on a shared network path or via a proxy) captures a legitimate request bearing a password-digest UsernameToken. They resend the request after re-encoding the Nonce - such as inserting a space into the base64 - which still verifies as the correct digest but fails to match the cached raw-text Nonce, so the replay cache accepts it. Since the token does not cover the message body, the attacker then swaps in arbitrary SOAP operations and replays the token repeatedly until it expires. No public proof-of-concept has been identified.