Apache WSS4J EUVD-2026-89795

Exploitation requires the target to use the WSS4J streaming (StAX) processing path - the DOM-based code is explicitly NOT affected - and to enforce a WS-SecurityPolicy that requires the SOAP Body (or specific SignedParts/SignedElements) to be signed; otherwise there is no protection to bypass. The trigger is a message containing a signature reference that uses the WS-Security STR-Transform, which permanently sets the internal 'inside signed content' flag and causes the policy enforcer to stop evaluating subsequent SignedParts/SignedElements. Given those preconditions, exploitation is remote and unauthenticated (AV:N/PR:N/UI:N) with low complexity; the main limiting factors are the required streaming code path, the policy that mandates a signed Body, and use of an affected version (<2.4.4, 4.0.0-4.0.1, 3.0.0-3.0.5).

This is a genuine, well-characterized integrity vulnerability rather than a hype-driven high-CVSS finding, but its real-world reach is gated by specific deployment conditions. The vendor CVSS of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) is internally consistent: the flaw is remotely reachable by an unauthenticated attacker who can send a SOAP message, requires no user interaction, and produces a pure integrity impact (C:N/I:H/A:N) by defeating WS-SecurityPolicy enforcement of SignedParts/SignedElements - a classic XML Signature Wrapping bypass. No EPSS score, KEV listing, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis'; the signal set therefore points to a credible but not-yet-actively-exploited defensive-control failure. CWE-693 (Protection Mechanism Failure) accurately frames the issue: signature verification itself still works, but the policy enforcer is tricked into believing an unsigned Body is signed. The most important caveat is that the CVSS PR:N/AC:L combination understates real preconditions - the target must use the WSS4J streaming (StAX) code path (the DOM path is unaffected) AND enforce a policy requiring the Body to be signed, and the message must legitimately include an STR-Transform signature reference to set the sticky flag. Note also the input Tag 'Information Disclosure' conflicts with the CVSS vector (C:N, I:H): this is an integrity/signature-wrapping issue, not a confidentiality/disclosure issue, and that tag should be corrected.

An attacker intercepts or crafts a SOAP request to a service that uses WSS4J's streaming StAX processor and enforces a policy requiring the SOAP Body to be signed. By including a signature reference that uses the WS-Security STR-Transform (which permanently sets the internal 'inside signed content' flag), the attacker causes the policy enforcer to stop checking SignedParts/SignedElements, then submits or wraps an unsigned/attacker-controlled Body that is accepted as if properly signed. No authentication, user interaction, or public exploit code is required, though the target must run the affected streaming code path.