Bug 2543905 (CVE-2026-92121)

Summary: CVE-2026-92121 wss4j: org.apache.wss4j/wss4j-ws-security-policy-stax: org.apache.wss4j/wss4j-ws-security-stax: org.apache.wss4j/wss4j: Apache WSS4J: Security policy bypass via STR-Transform reference
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: anujha, aschwart, asoldano, aszczucz, bbaranow, bmaxwell, boliveir, bstansbe, dlofthou, drichtar, fmariani, fmongiar, gmalinko, istudens, ivassile, iweiss, janstey, jnethert, jwon, mcarlett, mosmerov, mposolda, msvehla, nwallace, pberan, pdelbell, pesilva, pjindal, pmackay, rmartinc, rstancel, rstepani, ssilvert, sthorger, tcunning, thjenkin, vdosoudi, vmuzikar, yfang
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Apache WSS4J. This vulnerability allows a remote attacker to bypass security policy enforcement by submitting a specially crafted message using a Security Token Reference (STR) transformation. Due to an internal state tracking error in the streaming message processor, signature verification requirements are improperly skipped for subsequent parts of the message. As a result, critical message sections, such as the message body, can be accepted without a valid digital signature, exposing the application to message tampering.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-30 12:33:22 UTC 
In the WSS4J streaming (StAX) code, a signature reference using the WS-Security STR-Transform leaves an internal "inside signed content" flag permanently set. The WS-SecurityPolicy enforcer uses that flag to decide whether an element needs checking, so it stops evaluating SignedParts and SignedElements for the rest of the message. A policy requiring the SOAP Body to be signed is then satisfied even when the Body carries no signature, removing the protection against XML Signature Wrapping. Signature verification itself is unaffected. The DOM code is not affected. 
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4 which fix this issue.