Apache WSS4J CVE-2026-87830

Exploitation requires the target to (1) use Apache WSS4J (versions <4.0.2, <3.0.6, or <2.4.4) as its WS-Security implementation, (2) use the StAX/streaming WS-SecurityPolicy validator specifically, and (3) have a security policy whose SignedElements/EncryptedElements/RequiredElements assertions use relative or otherwise unsupported XPath expressions - the exact expressions that get mis-converted into never-matching paths. Where those conditions hold, a remote SOAP peer can exploit it without authentication or user interaction. The limiting factor is the policy configuration: services using only absolute/supported XPath or not relying on element-level XPath signing/encryption are not affected.

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, 9.1) presents this as a critical, remotely-reachable, unauthenticated security-control bypass. However, the real-world risk is materially lower than 9.1 for two reasons. First, exploitation is not universal: it is gated on the target service using Apache WSS4J's StAX (streaming) WS-SecurityPolicy validator AND having a security policy that references relative or unsupported XPath expressions - a configuration-specific precondition, not a default-on flaw, which realistically pushes attack complexity higher than the AC:L the vendor assigned. Second, I dispute the C:H rating: the described impact is that a remote SOAP peer can submit a required element WITHOUT the mandated signature or encryption, which is fundamentally an integrity/authentication-enforcement bypass (tampering/spoofing), not a disclosure of server-held secrets to the attacker; confidentiality impact is at best indirect. No EPSS score, no CISA KEV listing, and no public exploit code were provided - consistent with a recently-disclosed library flaw. Net: a genuine and serious integrity-control bypass for the subset of WSS4J deployments whose policies use the affected XPath forms, but the blanket 9.1 overstates both breadth (config-dependent) and confidentiality impact. Priority is elevated where WSS4J-fronted SOAP services rely on element-level XPath signing/encryption policies; otherwise moderate.

A remote SOAP peer targets a Java web service that enforces WS-SecurityPolicy via WSS4J's StAX validator with a policy specifying signed or encrypted elements by relative/unsupported XPath. The attacker crafts and sends a SOAP message that omits the required signature or encryption on that element; because the broken XPath conversion produces a path that never matches, the validator silently accepts the unprotected element, bypassing the integrity/encryption requirement. No public exploit code was identified at time of analysis.