CVE-2026-92899 in WSS4J
Summary
by MITRE • 09/30/2026
Apache WSS4J remembers the Nonce of each UsernameToken it accepts, so a captured token cannot be reused. It stored the Nonce as raw base64 text, but authentication decodes that text and uses the bytes.The same bytes can be written as base64 in several ways. An attacker who captured an authenticated request could re-send it with a space added to the Nonce: the password digest still verified, but the token no longer matched the remembered one, so the replay was accepted. Since a UsernameToken does not cover the message body, the captured token could then be reused on requests of the attacker's choosing until it expired. Affects deployments with a nonce replay cache configured, as Apache CXF has by default, and only tokens using a password digest. The cache is now keyed on the decoded Nonce. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability in Apache WSS4J represents a critical flaw in the implementation of WS-Security UsernameToken authentication, specifically concerning nonce validation and replay protection mechanisms. In secure web service communications, nonces are unique values used to ensure that each message is fresh and has not been previously transmitted by an attacker attempting a replay attack. The core technical failure stems from how Apache WSS4J stored and compared these nonces within its replay cache. While the system correctly decoded the base64-encoded nonce bytes for authentication purposes, it retained the raw base64 string representation in the memory-based cache used to track previously seen tokens. This discrepancy between storage format and validation logic created a significant edge case that undermined the integrity of the replay protection mechanism.
The technical root cause lies in the non-deterministic nature of certain base64 encoding implementations regarding whitespace handling. Although standard base64 encodings are generally consistent, variations exist where additional characters such as spaces or newlines can be inserted without altering the underlying binary data when decoded. An attacker who successfully captured a valid authenticated request could manipulate this captured token by inserting extra space characters into the nonce field of the UsernameToken. When Apache WSS4J processed this modified request, it would decode the base64 string to verify the password digest against the provided credentials. Since the underlying bytes remained identical due to whitespace tolerance in decoding, the authentication check passed successfully. However, when checking for replay protection, the system compared the raw input nonce including the added spaces against the stored cache entry which lacked those spaces. Because these strings did not match exactly, the system failed to recognize it as a previously seen token and allowed the request through.
This flaw effectively neutralizes the primary defense against message replay attacks in deployments utilizing Apache CXF with its default configuration, which includes an enabled nonce replay cache. The operational impact is severe because UsernameTokens do not inherently cover or sign the body of the SOAP message they accompany. Consequently, once an attacker bypasses the authentication check using this technique, they can reuse the valid token to execute arbitrary requests on behalf of the authenticated user until the token expires or the session terminates. This allows for unauthorized access to protected resources, data exfiltration, and potential privilege escalation depending on the permissions associated with the compromised account. The vulnerability is specifically limited to scenarios where a nonce replay cache is active and tokens rely on password digests rather than other authentication methods like X.509 certificates or clear text passwords which may have different validation paths.
To mitigate this risk, organizations must ensure that their Apache WSS4J installations are updated to patched versions 4.0.2, 3.0.6, or 2.4.4. These releases correct the issue by keying the replay cache on the decoded binary representation of the nonce rather than its raw string form. This ensures that any variation in whitespace encoding does not affect the uniqueness check performed during authentication. From a broader security architecture perspective, this incident highlights the importance of canonicalizing input data before performing cryptographic comparisons and strict adherence to standards such as CWE-294 which addresses authentication bypass by capture-replay attacks. Furthermore, it underscores the need for defense-in-depth strategies where message-level integrity checks like XML Signature are employed alongside authentication mechanisms to prevent token reuse even if authentication logic is flawed. Security teams should also audit their configurations to ensure that nonce caches are appropriately sized and monitored, as reliance on memory-based caches can introduce additional operational risks related to resource exhaustion if not managed correctly within the application lifecycle.