Hi, The following vulnerabilities were published for wss4j. It is not clear if the "ancient" version we have is affected, can you investigate? CVE-2026-85532[0]: | 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. CVE-2026-87830[1]: | In the StAX streaming WS-SecurityPolicy validator, certain relative | or unsupported XPath expressions can be converted into paths that | never match the actual XML element path. A remote SOAP peer may | therefore send a required element without the expected signature or | encryption. Users are recommended to upgrade to versions 4.0.2 or | 3.0.6 or 2.4.4, which fix this issue. CVE-2026-88920[2]: | An authentication bypass in the DOM security processor in Apache | WSS4J allows unauthenticated remote attackers to forge authenticated | SOAP messages via a crafted unsigned SAML sender-vouches assertion | containing an attacker-controlled key. Users are recommended to | upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. CVE-2026-89238[3]: | WSS4J EncryptedHeader child confusion could promote an attacker- | controlled plaintext element as the decrypted header, leading to | incorrect confidentiality coverage and possible policy bypass. Users | are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, | which fix this issue. CVE-2026-92121[4]: | In the WSS4J streaming (StAX) code, a signature reference using the | WS-Security STR-Transform leaves an internal "inside signed content" | flag permanently set. The WS-SecurityPolicy enforcer uses that flag | to decide whether an element needs checking, so it stops evaluating | SignedParts and SignedElements for the rest of the message. A policy | requiring the SOAP Body to be signed is then satisfied even when the | Body carries no signature, removing the protection against XML | Signature Wrapping. Signature verification itself is unaffected. The | DOM code is not affected. Users are recommended to upgrade to | versions 4.0.2 or 3.0.6 or 2.4.4 which fix this issue. CVE-2026-92899[5]: | 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. CVE-2026-95616[6]: | 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. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-85532 https://www.cve.org/CVERecord?id=CVE-2026-85532 [1] https://security-tracker.debian.org/tracker/CVE-2026-87830 https://www.cve.org/CVERecord?id=CVE-2026-87830 [2] https://security-tracker.debian.org/tracker/CVE-2026-88920 https://www.cve.org/CVERecord?id=CVE-2026-88920 [3] https://security-tracker.debian.org/tracker/CVE-2026-89238 https://www.cve.org/CVERecord?id=CVE-2026-89238 [4] https://security-tracker.debian.org/tracker/CVE-2026-92121 https://www.cve.org/CVERecord?id=CVE-2026-92121 [5] https://security-tracker.debian.org/tracker/CVE-2026-92899 https://www.cve.org/CVERecord?id=CVE-2026-92899 [6] https://security-tracker.debian.org/tracker/CVE-2026-95616 https://www.cve.org/CVERecord?id=CVE-2026-95616 Regards, Salvatore