AI analysis
Apache WSS4J has an integer overflow in its DER bounds check that lets an oversized allocation pass validation. An unauthenticated attacker can send a SOAP message whose X.509 certificate SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF; WSS4J decodes that extension while resolving the signature key reference, before the message is authenticated, so a tiny extension can force about a 2 GB allocation. Repeating the request exhausts server memory and denies service, with no confidentiality or integrity impact. Any service that uses a vulnerable WSS4J release to process unauthenticated SOAP with WS-Security signatures is affected. There is no known public proof of concept and the issue is not listed in CISA KEV.
What to do: Upgrade Apache WSS4J to 4.0.2, 3.0.6, or 2.4.4 (whichever release line you use) and redeploy every application that embeds it, including transitive dependencies pulled in by Apache CXF or other WS-Security stacks. Until the upgrade is in place, constrain process memory and request size for unauthenticated SOAP endpoints so a single oversized allocation cannot exhaust the host.
Affected
| Apache WSS4J | Fixed in 2.4.4, 3.0.6, and 4.0.2; earlier releases on those lines are affected (exact vulnerable ranges not stated in the advisory data) |
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
An integer overflow in WSS4J's DER bounds check lets an oversized allocation pass validation. An unauthenticated attacker can send a SOAP message carrying an X.509 certificate whose SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF; WSS4J decodes this while resolving the signature's key reference, before the message is authenticated, so an eleven-byte extension triggers a 2 GB allocation. Repeated requests exhaust server memory. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.