Apache WSS4J: Streaming WS-SecurityPolicy validation may skip element-protection checks

Summary

Certain relative or unsupported XPath expressions in the StAX streaming WS-SecurityPolicy validator of Apache WSS4J are converted into paths that never match the actual XML element path. A remote SOAP peer can therefore send a required element without the expected signature or encryption, and the validation does not reject the message. The issue requires that the affected SOAP service uses streaming WS-SecurityPolicy with signed or encrypted element requirements; the default configuration is unaffected.

Affected

• Apache WSS4J (org.apache.wss4j:wss4j-ws-security-policy-stax) 4.0.0 before 4.0.2
• Apache WSS4J (org.apache.wss4j:wss4j-ws-security-policy-stax) 3.0.0 before 3.0.6
• Apache WSS4J before 2.4.4 (lower bound for the 2.x branch: unknown)
• Third-party aggregators list these ranges; verify against the Apache advisory.

Fixed in

• Apache WSS4J 4.0.2
• Apache WSS4J 3.0.6
• Apache WSS4J 2.4.4

Workaround

Unknown. No official workaround has been published. Upgrading is the documented remediation. Reviewing WS-SecurityPolicy XPath expressions and using simple element paths is a possible interim step, but it is not a documented mitigation from Apache.

Exploitation

• CVSS 3.1 score 9.1 (CRITICAL), network-reachable, no authentication or user interaction required.
• CISA SSVC: Exploitation none, Automatable yes, Technical Impact total.
• No evidence of exploitation in the wild found; KEV: No.
• No public proof of concept found in the research; this is not fully verified.

Our recommendation

• Inventory WSS4J and any dependency that pulls in wss4j-ws-security-policy-stax, for example via Apache CXF, including transitive versions.
• Upgrade to 4.0.2, 3.0.6 or 2.4.4, matching your branch.
• Test SOAP security policies before rollout, because the stricter XPath handling can reject requests that previously worked.
• Prioritise internet- or partner-facing SOAP endpoints.
• Check the Apache advisory for the authoritative affected range.
• Verify the CWE assignment (CWE-917) in NVD, as it appears inconsistent with the description.
• Patch the related CVEs fixed in the same release together.
• Monitor SOAP endpoints for unexpected messages without required signatures or encryption.
• The CVE record is not fully confirmed from primary sources; verify before finalising.
• Note: the same release also fixes CVE-2026-88920, CVE-2026-89238 and CVE-2026-92121 according to third-party sources.
• Ubuntu rates this as medium while CVSS is 9.1; treat the CVSS score as the primary rating.
• Test thoroughly before deployment.
• Treat the exposure as high where SOAP services are reachable from untrusted networks.
• Document the patch status for audit purposes.
• Re-check the Apache thread after publication for further guidance.
• Review logs for SOAP messages from unexpected peers.
• Confirm after patching that the validator enforces the required signature and encryption elements.

Public exploits iAttack code is publicly available (PoC on GitHub, Metasploit or Exploit-DB).

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

• Apache WSS4J advisory thread lists.apache.org
• oss-security post CVE-2026-87830 www.openwall.com
• Tomitribe ws-wss4j fix PR github.com
• Ubuntu CVE-2026-87830 ubuntu.com
• Quarkus CXF 3.40.2 release notes docs.quarkiverse.io
• Apache WSS4J streaming documentation ws.apache.org
• Maven Repository WSS4J mvnrepository.com

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 07:56.