A companion to the signature-wrapping note, because the two together explain why the WS-Security stack was harder to get right than anyone selling it admitted. Where wrapping broke integrity and authentication, the flaw described here broke confidentiality, and it broke it in a way that let an attacker read an encrypted message without ever recovering the key. If you deployed XML Encryption to protect a SOAP body in the 2000s, the odds are good that the protection was weaker than the specification led you to believe.
What XML Encryption was for
The W3C XML Encryption Recommendation, published in 2002, was the confidentiality companion to XML Signature. WS-Security leaned on it heavily. If a SOAP message carried a credit card number or a health record through an intermediary you did not fully trust, you encrypted that element rather than the whole transport, so that end-to-end confidentiality survived the message being parked in a queue or routed through a broker. The standard supported block ciphers in CBC mode, Triple-DES and later AES, as its symmetric algorithms. That choice, sensible-looking at the time, is where the problem lived.
The flaw: CBC without integrity is an oracle
CBC mode is malleable. An attacker who cannot decrypt a ciphertext can still make predictable, targeted changes to the plaintext by flipping bits in the preceding ciphertext block. On its own that is a known property, managed in well-designed systems by adding integrity protection so that any tampering is detected before the plaintext is ever used. XML Encryption, as specified, did not require that integrity protection. The recipient decrypted whatever ciphertext it was handed and then tried to parse the result as XML.
That parse step is the oracle. In 2011, Tibor Jager and Juraj Somorovsky demonstrated, in their paper How to Break XML Encryption, an adaptive chosen-ciphertext attack that recovered the full plaintext of an XML-encrypted message without the key. The mechanism is worth stating plainly, because it is the same mistake that keeps recurring across protocols. The attacker sends the target a modified version of the intercepted ciphertext. The server decrypts it and reacts, and its reaction differs depending on whether the decrypted bytes happened to form something the XML parser accepted or rejected. Well-formed or not-well-formed, a different error, a different timing, a different response at all, any distinguishable outcome tells the attacker one bit about the underlying plaintext. Repeat, adaptively, and the plaintext falls out byte by byte. Their reported cost was on the order of fourteen server requests per byte of plaintext, which for a session token or an account number is nothing.
Why this class of attack refuses to die
The forum will recognise the shape of this, because it is Bleichenbacher's 1998 attack on RSA PKCS#1 wearing new clothes, and it is the same family as the padding-oracle attacks that plagued TLS CBC cipher suites for a decade. The common root is encrypting without authenticating, then letting the decrypting party's behaviour leak information about the plaintext. Any system that decrypts attacker-supplied ciphertext and then does something observably different based on the content has built a decryption oracle, whether it meant to or not. XML Encryption built one into a Recommendation and shipped it to every enterprise integration team in the industry.
What actually fixed it
The durable fix is authenticated encryption. XML Encryption 1.1, published by the W3C in 2013, added AES in Galois/Counter Mode, an authenticated cipher that rejects any modified ciphertext outright rather than decrypting it and reacting. It also carried guidance to stop treating unauthenticated CBC as safe. GCM has its own operational footgun, catastrophic failure on nonce reuse, so it is not a licence to stop thinking, but as a replacement for malleable-CBC-without-a-MAC it closed the oracle. The general rule that the forum arrived at the hard way, the same one TLS eventually enforced, is that you authenticate the ciphertext before you decrypt it, and you never let the parser see bytes you have not first proven were untampered.
For the current state of the specification, the W3C XML Encryption 1.1 Recommendation is the reference, and the broader guidance on avoiding exactly this pattern is collected in the OWASP Cryptographic Storage Cheat Sheet. If you maintain anything that still speaks XML Encryption, and there is more of it embedded in banking and government integration than the REST generation likes to think, confirm it negotiates an authenticated cipher and refuses the CBC algorithms. A confidentiality control that can be turned into a decryption oracle is worse than no control, because it is a control someone is being paid to trust.
- mhendricks