CVE-2026-95616 in WSS4J
Summary
by MITRE • 09/30/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability described involves a critical integer overflow within the Web Services Security for Java (WSS4J) library, specifically during the processing of X.509 certificate extensions in SOAP messages. This flaw resides in the DER bounds check logic used when resolving key references for digital signatures. The core technical issue arises from how WSS4J handles the SubjectKeyIdentifier extension found within an X.509 certificate. When a malicious actor sends a SOAP message containing such a certificate, they can manipulate the length field of this extension to declare an impossibly large value, specifically 0x7FFFFFFF. This hexadecimal value corresponds to two billion and fifty-three million five hundred forty-five thousand one hundred ninety-nine bytes, or approximately two gigabytes. Because the validation logic fails to properly check for integer overflow conditions before proceeding with memory allocation, the system interprets this malformed input as a valid request for massive resource consumption rather than rejecting it as invalid data.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through server memory exhaustion. Since WSS4J processes these certificates during signature resolution prior to full message authentication, an unauthenticated attacker can trigger the flawed code path without needing valid credentials. The immediate consequence of triggering this overflow is that the application attempts to allocate eleven bytes worth of data structures but calculates the total buffer size based on the inflated length field, leading to a request for approximately two gigabytes of memory. When such requests are sent repeatedly in rapid succession, they rapidly deplete the available heap space on the server hosting the vulnerable service. This leads to out-of-memory errors, application crashes, or complete unavailability of the web services, effectively rendering the system unusable for legitimate users and disrupting business operations dependent on those SOAP-based interactions.
From a security architecture perspective, this vulnerability aligns with CWE-190, which defines integer overflow or wraparound vulnerabilities where arithmetic operations produce results that exceed the maximum value representable by the data type. Furthermore, because it allows an unauthenticated remote attacker to cause a denial of service through resource exhaustion via network interaction, it maps directly to MITRE ATT&CK technique T1498, specifically Network Denial of Service under the Impact category. The lack of proper input validation on cryptographic parameters highlights a failure in secure coding practices regarding boundary checks and type safety during parsing operations. This is particularly dangerous because it exploits the trust placed in certificate structures that are often processed early in the request lifecycle before stricter authentication controls can mitigate the damage.
To remediate this issue, organizations must immediately upgrade their WSS4J dependencies to patched versions where these bounds checks have been corrected. The recommended fixed versions include 4.0.2 for newer releases, as well as 3.0.6 and 2.4.4 for older supported branches. These updates implement proper validation logic that detects integer overflows or unreasonable allocation sizes before memory is committed. In addition to upgrading the library, administrators should consider implementing network-level rate limiting on SOAP endpoints to mitigate potential abuse during the transition period. It is also advisable to review input validation strategies across all cryptographic parsing components in the application stack to ensure similar vulnerabilities do not exist elsewhere in the codebase, particularly where external data influences memory allocation decisions or buffer sizes.