Apache WSS4J EUVD-2026-89791

Exploitation requires a service that embeds Apache WSS4J and processes inbound WS-Security messages containing derived-key elements - i.e., a SOAP endpoint accepting WS-Security tokens is exposed to the attacker. No authentication or user interaction is required (PR:N/UI:N). The limiting factor is deployment topology: only applications that actually consume WSS4J-processed WS-Security messages (e.g., Apache CXF-based SOAP web services) on affected versions (<2.4.4, <3.0.6, <4.0.2) are at risk; endpoints not exposing WS-Security message processing are unaffected.

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) describes a remotely reachable, low-complexity, unauthenticated flaw whose sole rated impact is availability - consistent with the CWE-20 input-validation description where attacker-controlled derived-key lengths/offsets drive excessive CPU/memory consumption. The CISA SSVC framework aligns and tempers this: Exploitation is 'none' (no observed or public exploitation), Automatable is 'yes' (a crafted WS-Security message can be sprayed at any listening endpoint), and Technical Impact is 'partial' - matching a DoS rather than full compromise. No KEV listing and no POC were provided, and no EPSS score is present in the input, so exploitation likelihood cannot be quantified from these signals; the honest read is 'exploitable-in-principle but not yet observed.' Note a signal tension: the description also warns of 'cryptographically weak keys,' which implies a potential confidentiality/integrity dimension, yet the vendor scored C:N/I:N - the DoS path is the concrete, primary risk while the weak-key path is contingent and unquantified. Net: a genuine but moderate-priority availability issue for exposed SOAP/WS-Security endpoints, not a critical widespread-exploitation emergency.

An unauthenticated attacker sends a crafted WS-Security SOAP message to a service that uses Apache WSS4J, specifying an abusive derived-key length or offset that the library accepts without bounds checking. WSS4J allocates excessive CPU/memory while processing the message, degrading or exhausting the service. No public exploit code was identified at time of analysis, but the attack is network-reachable, requires no authentication, and is automatable per CISA SSVC.