CVE-2026-88920 is an authentication bypass in Apache WSS4J, the Java library that implements WS-Security for SOAP web services. WSS4J is usually not a server an administrator logs into: it is embedded in services and middleware, including Apache CXF and Apache Axis, to handle message signatures, encryption, and tokens such as SAML.
That placement matters. The exposed party is an organisation running a Java SOAP endpoint that uses WSS4J’s DOM security processor and SAML sender-vouches authentication—not every application that happens to depend on WSS4J. Enterprise integration and application middleware are the likely homes for it; downstream tracking also identifies Camel deployments, JBoss Fuse, JBoss EAP and Red Hat Single Sign-On among the affected ecosystems.
An assertion can supply the key that validates it
SAML sender-vouches is a model in which a message sender vouches for an assertion. In the flawed DOM processing path, an unauthenticated remote attacker can send an unsigned sender-vouches assertion containing a secret key of their choosing, then use that same key to sign a crafted SOAP message. The processor could accept the result as authenticated.
In other words, the vulnerable code let the attacker bring both the claimed identity material and the credential used to verify the message, without establishing that either belonged to a trusted party. The attacker needs network reachability to a vulnerable SOAP service and the ability to submit a crafted request; no prior account or authentication is required. What they gain depends on what the receiving service authorizes that asserted identity to do, but the immediate effect is bypassing the service’s intended SOAP-message authentication.
Apache’s fix makes the missing distinction explicit. The patch rejects a raw secret key taken from a non-holder-of-key assertion such as sender-vouches, rather than treating verification with that attacker-provided key as meaningful proof of possession. The advisory identifies the affected artifact as org.apache.wss4j:wss4j-ws-security-dom; it does not say that WSS4J’s StAX streaming processor is affected.
Upgrade the embedded dependency, then test the trust boundary
Apache has published fixes for [CVE-2026-88920](https://ws.apache.org/wss4j/advisories/CVE-2026-88920.txt): upgrade 4.0.x users to 4.0.2, 3.0.x users to 3.0.6, and pre-2.4.4 users to 2.4.4. Teams should inventory direct and transitive WSS4J dependencies, particularly in CXF-, Axis-, Camel-, and JBoss-based services, and confirm whether they invoke the DOM processor with sender-vouches assertions. Updating a library in a build file is not enough if a packaged application server or integration product supplies its own copy.
Regression-test the real endpoint after upgrading: reject unsigned sender-vouches assertions carrying caller-controlled key material, and check that legitimate SOAP clients still authenticate as expected. Apache rates the issue Important, while CVE enrichment assigns CVSS 3.1 9.8/Critical; the available material does not explain that difference.
As of October 6, 2026, no exploitation in the wild, breach, victim, or named campaign could be confirmed. It is absent from the CISA KEV catalogue, and no standalone public proof of concept or weaponized exploit has surfaced. Apache’s regression test demonstrates the condition, but is not a ready-to-run network exploit.
This is a dependency-level authentication failure, so ownership often sits awkwardly between platform and application teams. Use SecAlerts to monitor the software your organisation actually runs and alert on new vulnerabilities affecting that stack, while treating this update as a prompt to map every SOAP authentication path behind it.
