AI analysis
Apache WSS4J did not adequately bound attacker-controlled derived-key lengths and offsets when processing WS-Security messages. A crafted message can force cryptographically weak keys or drive excessive CPU and memory use. The flaw is improper input validation (CWE-20) in the WSS4J library, which is commonly pulled in by Java SOAP stacks that handle WS-Security. Users of releases before the fixed versions 2.4.4, 3.0.6, and 4.0.2 are affected. There is no known public proof of concept, the issue is not on the CISA KEV list, and exploitation in the wild is not known.
What to do: Upgrade Apache WSS4J to 4.0.2, 3.0.6, or 2.4.4, matching the release line you already use. Identify every application that processes untrusted WS-Security messages (often via Apache CXF or similar SOAP stacks) and confirm the fixed library version is on the classpath. Until then, restrict or carefully gate WS-Security endpoints that accept derived-key material from untrusted clients.
Affected
| Apache WSS4J | versions prior to 2.4.4, 3.0.6, and 4.0.2 |
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
Apache WSS4J accepted attacker-controlled derived-key lengths and offsets without adequate bounds. This could permit cryptographically weak keys or excessive CPU and memory consumption when processing crafted WS-Security messages. The fixes enforce a minimum key length of 16 bytes, a maximum length of 512 bytes, and a maximum offset of 4096 bytes. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.