Wss4J
Monthly
Unauthenticated denial of service in Apache WSS4J lets remote attackers exhaust server memory by sending SOAP messages that carry a specially crafted X.509 certificate: the certificate's SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF, and an integer overflow in WSS4J's DER bounds check allows the oversized allocation to pass validation, so an eleven-byte extension can trigger an approximately 2 GB allocation. Because the certificate is decoded while resolving the signature's key reference - before the message is authenticated - no credentials are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and repeated requests can drive an exposed WS-Security endpoint to OutOfMemory conditions. Affected releases are WSS4J 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all versions before 2.4.4; impact is limited to availability, with no code execution or data disclosure path identified. No public exploit code, EPSS score, or CISA KEV entry is present in the provided data, so risk is driven by Apache's "important" severity rating and the pre-authentication nature of the flaw rather than confirmed active exploitation.
XML Signature Wrapping protections in Apache WSS4J's streaming (StAX) code path can be bypassed, allowing a remote unauthenticated attacker to deliver a SOAP message whose Body is unsigned yet still satisfies a WS-SecurityPolicy requiring the Body to be signed. The root cause is that a signature reference using the WS-Security STR-Transform permanently sets an internal 'inside signed content' flag, which causes the WS-SecurityPolicy enforcer to stop evaluating SignedParts and SignedElements for the remainder of the message; signature verification itself is not broken, and the DOM-based code is unaffected. Only deployments on the streaming path that enforce such a policy are exposed: affected versions are below 2.4.4, 3.0.0 through 3.0.5, and 4.0.0 through 4.0.1, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patches are available as 4.0.2, 3.0.6, and 2.4.4.
WS-Security policy bypass in Apache WSS4J (4.0.0 <4.0.2, 3.0.0 <3.0.6, and 0 <2.4.4) allows an unauthenticated remote attacker to exploit EncryptedHeader child confusion so that an attacker-controlled plaintext element is promoted as the decrypted header, undermining confidentiality coverage and enabling WS-SecurityPolicy bypass. Per the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1), the flaw is network-reachable with low complexity, requires no authentication and no user interaction, and can affect both confidentiality and integrity - typically through Apache CXF-based SOAP services that decrypt EncryptedHeader elements and enforce WS-SecurityPolicy. Exposure is limited to deployments that actually rely on encrypted SOAP headers and policy enforcement; services not using WS-Security header confidentiality are not meaningfully exposed, and no public exploit code was identified at time of analysis.
Unauthenticated remote attackers can bypass authentication in Apache WSS4J (4.0.0 before 4.0.2, 3.0.0 before 3.0.6, and 2.x before 2.4.4) and forge authenticated SOAP messages by submitting a crafted unsigned SAML sender-vouches assertion that carries an attacker-controlled key, which the DOM security processor accepts as proof of identity. Any SOAP service configured to accept and validate SAML sender-vouches assertions through that processor is exposed at the network layer alone, with no credentials and no user interaction required, yielding critical confidentiality and integrity impact (CVSS 3.1 base 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). At time of analysis no public exploit code and no confirmed active exploitation were identified, but the low attack complexity and the fact that the vulnerable code path is a security trust boundary make this a genuine high-priority vulnerability rather than a high-CVSS-but-low-risk case; remediation is straightforward because vendor patches exist.
Apache WSS4J versions 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4 can accept SOAP messages in which a required element was never signed or encrypted, because the StAX streaming WS-SecurityPolicy validator converts relative or otherwise unsupported XPath expressions into paths that never match the real XML element path. The result is a fail-open integrity failure: a remote, unauthenticated SOAP peer (CVSS 3.1 AV:N/PR:N/UI:N) can send a policy-required element without the expected signature or encryption and the validator will not object. Exploitation is conditional on the deployment using WSS4J's StAX/streaming policy validator with a security policy whose SignedElements, EncryptedElements, or RequiredElements assertions use relative or unsupported XPath; our independent assessment rates the exploit vector AC:H and limits impact to integrity (I:H) with no confidentiality or availability effect, well below the vendor's 9.1 score, and no public exploit code has been identified at time of analysis.
Denial of service in Apache WSS4J (2.x before 2.4.4, 3.x before 3.0.6, and 4.x before 4.0.2) allows unauthenticated remote attackers to force excessive CPU and memory consumption by sending crafted WS-Security messages whose derived-key Length and Offset values are not validated by the library. The issue is a CWE-20 improper input validation flaw rated by the vendor at CVSS 3.1 base 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), so the rated impact is availability only, although the same unchecked bounds could in principle yield cryptographically weak derived keys. Vendor patches are available in 4.0.2, 3.0.6, and 2.4.4; CISA SSVC lists Exploitation: none with Automatable: yes, and no public exploit identified at time of analysis.
UsernameToken replay protection in Apache WSS4J can be bypassed by re-encoding the Nonce, allowing a captured authentication token to be reused against the same service. Affected are deployments of WSS4J 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4, but only where a nonce replay cache is configured - which Apache CXF enables by default - and only for UsernameTokens that use a password digest. An attacker who already holds a valid captured request (via a MITM, proxy, or shared network path) can re-send it with, for example, a whitespace character appended to the base64 Nonce; the password digest still verifies while the token no longer matches the cached entry in unpatched WSS4J, and because a UsernameToken does not cover the message body, the captured credential can be reused on arbitrary attacker-chosen requests until the token expires. Apache rates this as moderate severity, no public exploit code has been identified at time of analysis, there is no CISA KEV listing, and no CVSS vector, EPSS score, or SSVC decision was supplied by any source; the vendor has released fixed versions, so remediation is straightforward.
Apache WSS4J before 1.6.17 and 2.0.x before 2.0.2 improperly leaks information about decryption failures when decrypting an encrypted key or message data, which makes it easier for remote attackers. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apache WSS4J before 1.6.17 and 2.x before 2.0.2 allows remote attackers to bypass the requireSignedEncryptedDataElements configuration via a vectors related to "wrapping attacks.". Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. Epss exploitation probability 13.9%.
Apache WSS4J before 1.6.17 and 2.x before 2.0.2, as used in Apache CXF 2.7.x before 2.7.13 and 3.0.x before 3.0.2, when using TransportBinding, does not properly enforce the SAML SubjectConfirmation. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.
Unauthenticated denial of service in Apache WSS4J lets remote attackers exhaust server memory by sending SOAP messages that carry a specially crafted X.509 certificate: the certificate's SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF, and an integer overflow in WSS4J's DER bounds check allows the oversized allocation to pass validation, so an eleven-byte extension can trigger an approximately 2 GB allocation. Because the certificate is decoded while resolving the signature's key reference - before the message is authenticated - no credentials are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and repeated requests can drive an exposed WS-Security endpoint to OutOfMemory conditions. Affected releases are WSS4J 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all versions before 2.4.4; impact is limited to availability, with no code execution or data disclosure path identified. No public exploit code, EPSS score, or CISA KEV entry is present in the provided data, so risk is driven by Apache's "important" severity rating and the pre-authentication nature of the flaw rather than confirmed active exploitation.
XML Signature Wrapping protections in Apache WSS4J's streaming (StAX) code path can be bypassed, allowing a remote unauthenticated attacker to deliver a SOAP message whose Body is unsigned yet still satisfies a WS-SecurityPolicy requiring the Body to be signed. The root cause is that a signature reference using the WS-Security STR-Transform permanently sets an internal 'inside signed content' flag, which causes the WS-SecurityPolicy enforcer to stop evaluating SignedParts and SignedElements for the remainder of the message; signature verification itself is not broken, and the DOM-based code is unaffected. Only deployments on the streaming path that enforce such a policy are exposed: affected versions are below 2.4.4, 3.0.0 through 3.0.5, and 4.0.0 through 4.0.1, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patches are available as 4.0.2, 3.0.6, and 2.4.4.
WS-Security policy bypass in Apache WSS4J (4.0.0 <4.0.2, 3.0.0 <3.0.6, and 0 <2.4.4) allows an unauthenticated remote attacker to exploit EncryptedHeader child confusion so that an attacker-controlled plaintext element is promoted as the decrypted header, undermining confidentiality coverage and enabling WS-SecurityPolicy bypass. Per the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1), the flaw is network-reachable with low complexity, requires no authentication and no user interaction, and can affect both confidentiality and integrity - typically through Apache CXF-based SOAP services that decrypt EncryptedHeader elements and enforce WS-SecurityPolicy. Exposure is limited to deployments that actually rely on encrypted SOAP headers and policy enforcement; services not using WS-Security header confidentiality are not meaningfully exposed, and no public exploit code was identified at time of analysis.
Unauthenticated remote attackers can bypass authentication in Apache WSS4J (4.0.0 before 4.0.2, 3.0.0 before 3.0.6, and 2.x before 2.4.4) and forge authenticated SOAP messages by submitting a crafted unsigned SAML sender-vouches assertion that carries an attacker-controlled key, which the DOM security processor accepts as proof of identity. Any SOAP service configured to accept and validate SAML sender-vouches assertions through that processor is exposed at the network layer alone, with no credentials and no user interaction required, yielding critical confidentiality and integrity impact (CVSS 3.1 base 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). At time of analysis no public exploit code and no confirmed active exploitation were identified, but the low attack complexity and the fact that the vulnerable code path is a security trust boundary make this a genuine high-priority vulnerability rather than a high-CVSS-but-low-risk case; remediation is straightforward because vendor patches exist.
Apache WSS4J versions 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4 can accept SOAP messages in which a required element was never signed or encrypted, because the StAX streaming WS-SecurityPolicy validator converts relative or otherwise unsupported XPath expressions into paths that never match the real XML element path. The result is a fail-open integrity failure: a remote, unauthenticated SOAP peer (CVSS 3.1 AV:N/PR:N/UI:N) can send a policy-required element without the expected signature or encryption and the validator will not object. Exploitation is conditional on the deployment using WSS4J's StAX/streaming policy validator with a security policy whose SignedElements, EncryptedElements, or RequiredElements assertions use relative or unsupported XPath; our independent assessment rates the exploit vector AC:H and limits impact to integrity (I:H) with no confidentiality or availability effect, well below the vendor's 9.1 score, and no public exploit code has been identified at time of analysis.
Denial of service in Apache WSS4J (2.x before 2.4.4, 3.x before 3.0.6, and 4.x before 4.0.2) allows unauthenticated remote attackers to force excessive CPU and memory consumption by sending crafted WS-Security messages whose derived-key Length and Offset values are not validated by the library. The issue is a CWE-20 improper input validation flaw rated by the vendor at CVSS 3.1 base 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), so the rated impact is availability only, although the same unchecked bounds could in principle yield cryptographically weak derived keys. Vendor patches are available in 4.0.2, 3.0.6, and 2.4.4; CISA SSVC lists Exploitation: none with Automatable: yes, and no public exploit identified at time of analysis.
UsernameToken replay protection in Apache WSS4J can be bypassed by re-encoding the Nonce, allowing a captured authentication token to be reused against the same service. Affected are deployments of WSS4J 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4, but only where a nonce replay cache is configured - which Apache CXF enables by default - and only for UsernameTokens that use a password digest. An attacker who already holds a valid captured request (via a MITM, proxy, or shared network path) can re-send it with, for example, a whitespace character appended to the base64 Nonce; the password digest still verifies while the token no longer matches the cached entry in unpatched WSS4J, and because a UsernameToken does not cover the message body, the captured credential can be reused on arbitrary attacker-chosen requests until the token expires. Apache rates this as moderate severity, no public exploit code has been identified at time of analysis, there is no CISA KEV listing, and no CVSS vector, EPSS score, or SSVC decision was supplied by any source; the vendor has released fixed versions, so remediation is straightforward.
Apache WSS4J before 1.6.17 and 2.0.x before 2.0.2 improperly leaks information about decryption failures when decrypting an encrypted key or message data, which makes it easier for remote attackers. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apache WSS4J before 1.6.17 and 2.x before 2.0.2 allows remote attackers to bypass the requireSignedEncryptedDataElements configuration via a vectors related to "wrapping attacks.". Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. Epss exploitation probability 13.9%.
Apache WSS4J before 1.6.17 and 2.x before 2.0.2, as used in Apache CXF 2.7.x before 2.7.13 and 3.0.x before 3.0.2, when using TransportBinding, does not properly enforce the SAML SubjectConfirmation. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.