Dear Kimsroul Sun, Thank you for your report. The PMC has determined that the issue you reported is NOT a vulnerability in Apache Ws.
1. This isn’t an incomplete fix for CVE-2026-88920. As you correctly note, the fix for CVE-2026-88920 was #685. In that case the signature’s KeyInfo pointed at the assertion itself, so WSS4J treated a key the attacker had embedded in the assertion as belonging to the SAML subject. The engine was making an identity claim it had no basis for, and that was the defect. In the EncryptedKey scenario, the engine makes no such claim. The signature result is reported as verified with a bare symmetric key: it carries no subject or certificate and is not marked as trust-validated (TAG_VALIDATED_TOKEN). The assertion is reported as unsigned. The results describe the message accurately. 2. A signature keyed by an EncryptedKey proves integrity, not who sent the message. The receiver’s certificate is public, so anyone can create an EncryptedKey addressed to it. A signature made with that key shows the signed parts weren’t changed in transit. It says nothing about who sent them. Our threat model states this as a disclaimed property (THREAT-MODEL.md §9, “A verified XML Signature does not authenticate the sender when the verification key is a symmetric key”) and lists this exact construction as a known non-finding (§11a). 3. Legitimate messages have the same structure. A client using a WS-SecurityPolicy SymmetricBinding with an unsigned sender-vouches assertion builds its message exactly as your PoC does. The receiver has nothing it can use to tell the two apart. The guard proposed in #718 would therefore reject every such deployment as well as the forged message. 4. Sender authentication is enforced by the policy layer. A service that needs to know who vouched for an assertion has to require a token that authenticates the sender, through WS-SecurityPolicy. Examples are an X.509 initiator or endorsing token, a UsernameToken, a signed assertion, or two-way TLS. Apache CXF enforces those requirements, and the WSS4J result data gives it what it needs to do so. We won’t be assigning a new CVE or documenting the CVE-2026-88920 fix as incomplete. Thank you again for the careful work and for reporting this responsibly. Kind regards, Colm O hEigeartaigh PMC member for Apache Ws PMC --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
