Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-09-30T13:17:21.823Z",
  "pubdate": "2026-09-30T13:17:21.823Z",
  "executiveSummary": "This vulnerability in Apache WSS4J involves an improper validation mechanism within the UsernameToken nonce replay cache.\nThe flaw allows for a Replay Attack where an attacker can bypass non-repeating token protections by subtly altering the Base64 encoding of the nonce.\nAffected products include Apache WSS4J, particularly when utilized within environments like Apache CXF that enable nonce replay caching by default.\nThe vulnerability occurs because the system stores and keys the nonce as raw Base64 text rather than the underlying decoded bytes.\nBy manipulating the encoding format of a previously captured nonce, an attacker can bypass the cache validation, allowing for the unauthorized reuse of UsernameTokens.\nSince UsernameToken security does not inherently protect the integrity of the message body, successful exploitation allows an attacker to perform authenticated actions on behalf of the user, potentially leading to unauthorized data access or service manipulation.\nThe impact is significant for deployments relying on password digest authentication with nonce caching enabled.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper normalization of Base64 encoded Nonce strings within the Apache WSS4J replay cache. When processing a UsernameToken, the system is designed to verify the nonce to prevent replay attacks; however, the implementation stores the nonce in its encoded string format rather than its canonical binary representation.\nBecause the Base64 encoding scheme allows for different string representations of the same underlying byte sequence (e.g., through the inclusion of non-functional characters like spaces or padding variations), the equality check performed by the cache fails to identify a previously seen nonce if the input string differs even slightly from the cached entry.\nThe attack flow begins with an attacker intercepting a legitimate, authenticated request containing a UsernameToken. While the password digest remains valid for the server-side verification process, the attacker modifies the Nonce field in the header by introducing a space, which is permitted by certain Base64 parsers.\nWhen the server receives this replayed request, it decodes the modified nonce for authentication purposes, where it successfully validates the password digest. However, when the system checks the replay cache, it compares the modified Base64 string against the stored values. Because the key in the cache was derived from the original, unmodified Base64 string, the modified string does not produce a cache hit. Consequently, the system erroneously assumes the request is unique and accepts the replayed token.\nThis vulnerability is specifically dangerous because the UsernameToken authentication mechanism primarily authenticates the principal but does not enforce integrity over the entire SOAP message body. Once the authentication is bypassed via the replayed token, the attacker can effectively 'replay' the identity to issue subsequent requests of their choosing. The exploitation remains viable until the original token's temporal expiration occurs.\nThe vulnerability affects Apache WSS4J versions prior to 4.0.2, 3.0.6, and 2.4.4. Deployments utilizing Apache CXF are particularly susceptible if they have enabled the default nonce replay cache configuration and rely on password digest-based authentication."
}