This forum spent its active years arguing about how to sign a SOAP body correctly, which WS-Security header ordering WebLogic and .NET would both accept, and whether canonical XML would ruin your day (it usually would). Most of those arguments are historical curiosities now. REST won, JSON won, and the WS-* stack is a museum piece.
One thing from that era did not die, though. It followed the industry from SOAP into SAML and it is still breaking single sign-on deployments in 2026. It deserves a consolidated note for anyone who inherited an XML-based authentication system and assumes that "the signature validates" means "the message is safe." It does not. The attack is XML Signature Wrapping, and understanding it is understanding a permanent flaw in how XML digital signatures relate to application logic.
The core problem
An XML digital signature does two things people conflate. It proves that a specific element has not been tampered with, and it identifies that element by a reference, usually an ID attribute. What it does not do is force the application to process the element that was signed. Signature validation and application logic are two separate passes over the same document, and nothing in the XML Signature specification guarantees they are looking at the same element.
That gap is the whole attack. An attacker takes a legitimately signed message, leaves the original signed element exactly where the signature validator can still find and verify it, and injects a second, forged, unsigned element in the place where the application logic actually reads. The signature check passes, because the element it references is untouched. The application processes the forged element, because that is the one it happens to select. Valid signature, attacker-controlled content.
What it looks like in SAML
The clearest example is a signed SAML assertion, the backbone of enterprise SSO. Suppose the identity provider signs an assertion stating NameID = alice. The attacker intercepts that assertion, wraps the original signed element inside a decoy container the validator will still walk into, and inserts a forged assertion stating NameID = administrator at the position the service provider's code reads from. The signature validates against the original alice assertion by its ID reference. The service provider extracts the identity from the forged assertion. The attacker is now administrator.
This is not theoretical. Somorovsky and colleagues demonstrated in their 2012 study On Breaking SAML: Be Whoever You Want to Be that the majority of the SAML frameworks they tested were vulnerable to some variant of this. The class itself was described earlier, by McIntosh and Austel in 2005, as XML signature element wrapping, in exactly the WS-Security context this forum lived in. Twenty years later, new SAML and XML-DSig implementations still reintroduce it.
Why it never goes away
The reason is architectural, not a bug in any one library. XML is flexible by design; a document can carry the same element type in many valid positions, and XPath, schema validation, and signature reference resolution can each disagree about which one is "the" element. Every time a framework re-implements signature verification and identity extraction as two independent steps, the gap reopens. It moved from SOAP message security to SAML web SSO to XML-based tokens in general, and it will follow XML wherever it goes next.
It is worth noting that this is one of the quiet reasons JSON Web Tokens, whatever their own well-documented failings, avoided this specific trap. A compact JWS signs the entire token as one opaque string; there is no rich document tree for a validator and a consumer to disagree about. The industry did not necessarily reason its way there deliberately, but the flatter format removed the wrapping surface.
What actually fixes it
The durable countermeasure is the one this forum kept repeating in 2004: process only what was signed. Concretely, that means extracting the identity or payload from the exact element the signature reference resolves to, not re-selecting it independently with XPath afterwards. It means strict schema validation that rejects documents containing unexpected or duplicated assertion elements. It means position-aware validation where the location of the signed element is itself checked, not just its integrity. Defence-in-depth libraries that implement "see what is signed" as a first-class operation close the gap; libraries that hand you a validated document and let you go find the interesting parts yourself leave it wide open.
For a current reference on the mechanics and mitigations, the OWASP SAML Security Cheat Sheet and the W3C XML Signature specification are both still relevant, which tells you something about how little the underlying problem has changed.
If you run SAML single sign-on in 2026, and most enterprises still do somewhere in the estate, this is worth an afternoon with your identity provider and service provider libraries. The XML web services era is over, but the lesson it kept trying to teach, that a signature authenticates an element and not your intention to process it, is as expensive to relearn as it ever was.
- mhendricks