Apache WSS4J CVE-2026-88920

Exploitation requires a target service that uses Apache WSS4J (versions before 4.0.2, 3.0.6, or 2.4.4) and is configured to accept and validate SAML sender-vouches assertions through the DOM security processor. The attacker needs only network reachability to the SOAP endpoint - no credentials, no user interaction, and no non-default toolchain - because the flaw is that an unsigned assertion carrying an attacker-controlled key is accepted as authenticated. Deployments that do not process SAML sender-vouches assertions, or that have upgraded to the fixed versions, are not exploitable via this vector.

This is a genuine high-priority vulnerability, not a high-CVSS-but-low-risk case. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is internally consistent with the description: an unauthenticated remote attacker forges authenticated SOAP messages, directly defeating the security control the library exists to enforce (CWE-287, authentication bypass). Because WSS4J is a security-enforcement library, a bypass here has full CIA impact on any service that trusts it for message authentication. No EPSS score, CISA KEV entry, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis' - the real-world signal is currently theoretical rather than observed. However, the low attack complexity, absence of any authentication or user-interaction requirement, and the fact that the flaw lets an attacker impersonate authenticated principals make this the type of issue that is quickly weaponized once details circulate (an oss-security advisory is already public). The main mitigating factor is not the flaw's severity but its reachability: only deployments that accept and process SAML sender-vouches assertions through the DOM security processor are affected.

An attacker targeting a SOAP web service that uses Apache WSS4J for WS-Security crafts a malicious SOAP request containing an unsigned SAML sender-vouches assertion embedding a key the attacker controls. The DOM security processor accepts the forged assertion as valid authentication, letting the attacker impersonate a legitimate authenticated user without any credentials or prior access. No public exploit code is identified yet, but the oss-security disclosure describes the mechanism and exploitation requires only a network-reachable endpoint.