SAML parser inconsistencies can still bypass authentication controls

At a glance

What this is: PortSwigger describes how SAML parser inconsistencies in Ruby and PHP can let attackers bypass authentication by making signed XML and processed XML diverge.

Why it matters: This matters because IAM teams cannot treat SAML signature verification as sufficient if different parsers can interpret the same response differently and silently accept forged identity claims.

Context

SAML authentication depends on two things lining up: the XML signature must verify, and the application must process the same asserted identity from the same document. When different XML parsers or library layers disagree about namespaces, attributes, or canonicalization, the trust boundary breaks even though the response still looks valid.

That makes this an identity governance problem as much as a protocol problem. If the verification path and the assertion-processing path do not share the same parsing assumptions, authentication can be bypassed without any visible user compromise, and patching one parser in isolation may only move the failure to another code path.

The article’s primary concern is not SAML in the abstract but the governance fragility of parser-dependent authentication. The practical question for IAM and platform teams is whether their federation stack still assumes that a signed XML document is inherently the same document the application will consume.

Key questions

Q: What breaks when SAML signature validation and assertion parsing use different XML libraries?

A: The verifier can confirm a signature on one XML object while the application consumes identity claims from another. That split creates a trust gap where an attacker can present a valid-looking response that resolves to attacker-controlled attributes. The fix is to ensure one parser model governs both signature checking and claim extraction.

Q: Why can a valid SAML signature still result in authentication bypass?

A: Because the signature may cover a legitimate node while the application reads attacker-controlled identity data from a different node in the same document. That happens when parser behaviour diverges around namespaces, attribute selection, or canonicalization. The cryptography can be correct and the authentication can still fail if the semantic object being trusted is not the same object that was signed.

Q: What signs suggest a SAML implementation is vulnerable to parser inconsistency attacks?

A: Look for separate libraries or code paths handling signature verification and assertion extraction, especially if they use different XML parsers. Extra warning signs are namespace-sensitive lookups, permissive XPath queries, duplicate attribute handling, and schema extensions that accept more than the protocol actually needs. Those conditions make it easier for an attacker to steer which element the application trusts.

Q: How should teams respond when a SAML parser inconsistency is discovered?

A: Treat it as an authentication-control defect, not a minor library bug. Replace any trust-on-parse behaviour with a single authoritative interpretation path, tighten schema and extension handling, and retest every federation flow that depends on signed XML. If the application cannot prove it is consuming exactly what it verified, the control is still unsafe.

Technical breakdown

Why separate signature verification and assertion parsing diverge

SAML responses often pass through one code path that checks the XML signature and another that extracts identity attributes from the assertion. If those paths use different parsers, XPath rules, or namespace handling, they may not agree on which element is signed or which attribute value is authoritative. That creates an opening for XML Signature Wrapping, where a legitimate signature can validate one fragment while the application consumes a different fragment. The vulnerability is architectural: the security decision and the identity decision are made over different interpretations of the same document.

Practical implication: Consolidate signature validation and assertion consumption around one trusted XML interpretation boundary.

How attribute pollution changes the meaning of a signed response

Attribute pollution works when duplicate-looking attributes such as ID and namespaced ID values are resolved inconsistently. Some libraries ignore namespaces when reading attributes, while others may return a different value depending on order or implementation details. If the signature logic binds to one attribute value but the application later reads another, the attacker can steer which element is treated as signed and which assertion is used for login. This is especially dangerous in SAML because identity assertions often rely on a small number of attributes to establish trust.

Practical implication: Treat duplicate or namespaced identity attributes as a hard failure rather than trying to resolve them heuristically.

Why void canonicalization breaks the signature trust model

Canonicalization is supposed to create one stable representation of XML before hashing and signing, but edge cases can cause the canonicalized output to differ from what the application later processes. In the attack described here, a canonicalization error can collapse the digest calculation in a way that lets an attacker preserve a valid-looking signature while changing the effective assertion. That is not just a parser bug. It is a trust-model failure in which the signed structure no longer guarantees the processed structure, so signature validity stops being equivalent to authentication validity.

Practical implication: Reject responses that rely on permissive canonicalization behavior or error recovery in the signing path.

Threat narrative

Attacker objective: The attacker wants to impersonate a trusted identity provider response and gain access to the service provider as an authenticated user.

1. Entry occurs when an attacker obtains or reuses a legitimately signed XML document, such as a signed metadata or error response, rather than stealing a user session directly.
2. Credential access is replaced by parser abuse, as the attacker crafts a SAML response that will be interpreted differently by the signature-verification parser and the assertion-processing parser.
3. Escalation happens when attribute pollution, namespace confusion, or void canonicalization cause the application to accept attacker-controlled identity claims as if they were signed.
4. Impact is full authentication bypass, allowing the attacker to create or take over an account and access protected application resources as the forged identity.

Breaches seen in the wild

• Oracle E-Business Suite exploitation 2025: Cl0p-branded attackers exploited an Oracle EBS zero-day, then sent extortion emails from hundreds of hijacked third-party mailboxes.
• HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Parser agreement, not XML signatures alone, is the real control boundary in SAML. This article shows that a signed document can still be unsafe when verification and assertion parsing are performed by different components. The security decision is only as strong as the shared interpretation of namespaces, attributes, and canonicalization. The implication is that federation programmes should treat parser consistency as an identity control, not just an implementation detail.

Signature validity is a necessary condition, not a sufficient one, for authentication. In the SAML ecosystem, a valid signature can coexist with a forged assertion if the application consumes a different node than the one that was verified. That means the trust model fails when developers assume that cryptographic validation automatically guarantees semantic correctness. Practitioners need to reassess where the authoritative identity claim is established, because the parser can become the de facto policy engine.

Incremental patching of legacy SAML libraries only postpones the next bypass. The article’s core lesson is that parser quirks, namespace handling, and canonicalization edge cases are structural weaknesses in older XML-based federation stacks. Those weaknesses are difficult to eliminate piecemeal because each fix can leave a neighbouring inconsistency intact. The practical conclusion is that authentication architecture, not just patch cadence, determines whether SAML remains governable.

SAML parser divergence is an authentication trust gap, not just a bug class. When one library treats an attribute, namespace, or canonical form differently from another, the identity programme loses a stable source of truth. That is a named governance problem because the control assumption is that signed identity data is interpreted consistently end to end. The implication is that federation owners must map where their trust boundary actually lives and where it silently fragments.

Void canonicalization exposes the fragility of protocol-era security assumptions. SAML relies on XML processing rules that were never designed for modern threat pressure or heterogeneous parser stacks. The result is a recurring class of bypasses that survive because the protocol’s semantics depend on exact implementation behaviour. For identity architects, the lesson is to treat parser determinism as part of assurance, not as an optional hardening detail.

What this signals

SAML federation now has a parser determinism problem. Identity teams should assume that signature verification and assertion consumption can diverge unless the entire XML path is tested as one control. That means federation assurance has to include parser behaviour, not just certificate trust and metadata hygiene.

The deeper issue is that legacy XML protocols expose control assumptions that modern authentication teams rarely model explicitly. When the same response can produce different security outcomes depending on attribute order, namespace handling, or canonicalization behaviour, federation governance becomes a code-level assurance problem rather than a policy-only one.

For practitioners

• Enforce a single XML trust boundary Make the same parser, namespace rules, and canonicalization logic responsible for both signature validation and assertion consumption so the application cannot read a different document than the verifier approved.
• Reject ambiguous SAML attributes Treat duplicate, shadowed, or namespace-colliding attributes such as ID and samlp:ID as invalid input instead of letting library defaults decide which value wins.
• Remove permissive extension points from SAML responses Tighten schema handling so unexpected extension elements cannot be used as insertion points for wrapped assertions or alternate signature material.
• Test federation stacks with parser differential cases Build negative tests that compare how your signing and assertion libraries interpret the same response, especially around namespaces, attribute lookup, and canonicalization edge cases.

Key takeaways

• SAML authentication can fail even when the XML signature verifies, because parser inconsistencies let different components consume different parts of the same response.
• The article demonstrates a real authentication bypass path using attribute pollution, namespace confusion, and void canonicalization against widely used Ruby and PHP SAML implementations.
• The control that matters is not only signature checking but deterministic end-to-end XML interpretation, with ambiguous parsing rejected before identity claims are trusted.

Key terms

• Xml signature wrapping: XML Signature Wrapping is an attack pattern where a signed XML document is altered so the parser validates one node but the application consumes another. It exploits implementation flaws, which is why secure parsing and full-document validation are essential.
• Canonicalisation: Canonicalisation is the practice of normalising output into a consistent, predictable form before it is exposed to callers. In privacy and security design, it helps remove hidden entropy, reduce ambiguity, and prevent internal implementation details from becoming externally observable signals.
• Attribute Pollution: Attribute pollution is the presence of conflicting attributes that represent the same logical value in different forms, often across namespaces. In XML identity flows, it can cause different parsers to select different identifiers, which breaks the assumption that the signed and processed values are the same.
• Federation Trust Boundary: A federation trust boundary is the point where one identity system accepts assertions, tokens, or sessions issued by another system. It is a critical boundary because any weakness in signature validation, redirect handling, or token issuance can convert a legitimate sign-in into attacker-controlled access.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.