SAML parser inconsistencies can still bypass authentication controls

At a glance

What this is: This is a technical analysis of novel SAML authentication bypasses that exploit parser disagreements to defeat signature validation and impersonate users.

Why it matters: It matters because identity teams that rely on SAML for enterprise access need to understand that authentication trust can fail inside the parsing layer, not just at the IdP or policy layer.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read PortSwigger's analysis of novel SAML authentication bypasses

Context

SAML authentication remains widely deployed because it centralises enterprise access, but it also inherits XML parsing complexity that many identity programmes underestimate. The primary governance issue here is not whether SAML is familiar, but whether the implementation stack can be trusted to interpret signed content consistently across parsers and libraries.

This article shows that authentication can be bypassed when signature verification and assertion processing disagree about what the document means. For IAM teams, that turns parser behaviour into an access-control risk, because a valid-looking response can still produce an unauthorised session.

The problem is not limited to one library or one language. Any SAML deployment that depends on inconsistent XML handling, permissive XPath selection, or fragile canonicalisation assumptions is exposed to the same class of identity failure.

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 do namespace and attribute handling errors matter in SAML deployments?

A: Because SAML security depends on selecting the right signed element every time. If one component reads ID and another reads samlp:ID, or if XPath queries ignore namespace boundaries, the system can authenticate the wrong content. This turns parser semantics into an access-control decision, which is a governance failure, not a formatting issue.

Q: How do security teams test for SAML authentication bypass risk?

A: They should use adversarial test cases that include wrapped assertions, duplicate attributes, namespace confusion, malformed signatures, and canonicalisation edge cases. The goal is to prove that the consumer and verifier always agree on the same element before the response can produce a session.

Q: Who is accountable when a SAML parser flaw leads to unauthorised access?

A: Accountability sits with the service owner, the identity platform owner, and the team that ships or maintains the consuming application. Federated identity does not transfer responsibility to the IdP alone, because the failure often occurs in the service provider’s validation path and library choices.

Technical breakdown

How parser disagreement breaks SAML signature validation

SAML signature verification is supposed to bind a signed Assertion to the identity data the service provider consumes. In practice, many implementations split that work across different XML parsers or modules. When one component validates the signature and another extracts the user attributes, an attacker can exploit inconsistent node selection, namespace handling, or attribute resolution. The result is a mismatch between what was signed and what the application trusts. That is why parser fidelity matters as much as cryptographic correctness in identity workflows.

Practical implication: review every SAML implementation for parser split points, especially where signature validation and claim extraction use different XML libraries.

Attribute pollution and namespace confusion in XML identity flows

Attribute pollution occurs when the same logical identifier is represented in more than one namespace form, such as ID and samlp:ID, causing different parsers to select different values. Namespace confusion compounds the problem by making signature nodes visible to one parser and hidden from another. These flaws matter because many SAML libraries still rely on XPath queries and helper methods that are not namespace-safe by default. Once selection logic diverges, the attacker can steer the verifier toward one element and the business logic toward another.

Practical implication: prohibit namespace-ambiguous attribute lookups and reject documents that contain duplicate identity-bearing attributes.

Void canonicalization and the limits of incremental fixes

Canonicalization is meant to produce a stable byte representation before hashing, but edge cases can cause the digest process to collapse to an empty or unexpected value. That becomes especially dangerous when libraries try to patch one parsing flaw without redesigning the overall validation flow. The article shows that one patch can block a known vector while leaving the architecture fragile enough for a new bypass to emerge. In identity systems, a narrow fix is not the same thing as a safe trust model.

Practical implication: treat canonicalisation failures and schema exceptions as authentication failures, not recoverable parser quirks.

Threat narrative

Attacker objective: The attacker wants to bypass authentication and obtain access as a different user without possessing valid user credentials.

1. Entry occurs when an attacker obtains or reuses a legitimate signed XML document, such as signed metadata or a signed error response, that can be repurposed for abuse.
2. Escalation occurs when parser inconsistencies let the attacker replace the trusted assertion view with malicious identity data while the signature verifier still sees a valid signature.
3. Impact occurs when the service provider accepts the forged assertion and establishes an authenticated session for an unauthorised identity.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SAML parser trust is a governance problem, not just a code defect. Identity programmes often assume that signature verification and claim extraction operate on the same document interpretation. This article shows that assumption fails when separate XML parsers disagree about namespaces, attributes, or canonical form. The implication is that SAML assurance must be evaluated as an end-to-end trust chain, not as isolated cryptographic validation.

Parser disagreement creates an identity illusion gap. The application believes it is consuming a signed assertion, but the processing path can be redirected toward attacker-controlled content if element selection is inconsistent. That is a specific failure mode in federated identity: the security control succeeds on paper while the runtime trust boundary fails in practice. Practitioners should treat parser consistency as part of access control design, not implementation detail.

Incremental patching can preserve the same structural weakness. Blocking DTDs or a known XSW pattern may eliminate one exploit while leaving the same split-validation architecture intact. The article demonstrates that the durable risk sits in the design assumption that XML parsing can be safely decomposed across libraries. Security teams should judge remediation by whether the trust model changed, not by whether one exploit stopped working.

Federated authentication needs explicit parser governance. SAML remains central to enterprise access, which means parser safety is now part of identity assurance and incident prevention. When authentication depends on fragile XML semantics, the control plane inherits the weakness of every library in the path. The practical conclusion is that SAML governance must include parser testing, strict schema enforcement, and code-level validation ownership.

Shadow parser risk is the hidden problem in many identity stacks. Teams focus on IdP policy, MFA, and assertion signing, but the attack surface can live in the consuming service provider’s XML stack. That makes this a cross-domain identity issue spanning human access, federated trust, and implementation hygiene. The right governance lens is to map where assertions are interpreted, not just where they are issued.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity inventory remains across many environments.
• For a broader threat lens, see the 52 NHI breaches Report for recurring failure patterns that outlast individual fixes.

What this signals

Parser consistency is now part of identity architecture. Teams that run SAML through multiple libraries should treat XML handling as a control surface, not an implementation detail. As identity estates age, the risk is less about whether SAML exists and more about whether the consuming application still interprets signed assertions deterministically.

Signed data is only as trustworthy as the consumer path. That means service providers need the same level of scrutiny for XML parsing and canonicalisation that they already apply to MFA, session policy, and federation trust. For practitioners, the programme question is whether the consuming stack can prove one authoritative view of the assertion.

The broader lesson is that identity assurance fails when trust is split across components that were never designed to agree. That is why parser testing, negative validation cases, and strict library governance belong in the same programme conversations as federation policy and access review.

For practitioners

• Audit every SAML parser boundary Inventory where signature verification, schema validation, and assertion extraction occur in the same application path. Eliminate designs that let different XML libraries make trust decisions about the same response.
• Reject namespace-ambiguous identity attributes Block documents containing duplicate ID-like attributes, conflicting namespace declarations, or XPath selections that rely on simple-name lookup instead of namespace-aware matching.
• Treat canonicalisation errors as auth failures Fail closed when digest computation, schema validation, or XML canonicalisation returns an unexpected result. Do not continue processing a response that produced parser exceptions or empty-string digests.
• Test SAML code against parser mismatch cases Build negative test cases for attribute pollution, namespace confusion, wrapped assertions, and signed error responses. Use adversarial test fixtures to verify that verifier and consumer see the same element.
• Review service provider trust assumptions Reassess every service provider that depends on SAML for access decisions, especially where legacy XML libraries or custom extensions are involved. Link the review to the broader SAML parser boundary.

Key takeaways

• SAML authentication can fail at the parser layer even when the cryptography appears correct.
• The evidence here is a full authentication bypass path built from attribute pollution, namespace confusion, and canonicalisation edge cases.
• Practitioners should test the entire consuming path, because fixing one parser bug does not change the underlying trust model.

Key terms

• Signature Wrapping Attack: A signature wrapping attack tricks a system into validating one signed XML element while processing another, attacker-controlled element. In SAML, that usually means the verifier checks a legitimate signature but the application consumes forged identity claims from a different node.
• 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.
• Void Canonicalization: Void canonicalization is a failure mode where XML canonicalisation or digest computation collapses to an empty or unexpected representation. In authentication systems, that matters because the hash used for signature validation no longer reflects the content the application believes it has authenticated.
• Parser Fidelity: Parser fidelity is the degree to which every component in an identity pipeline interprets the same XML document in the same way. When fidelity breaks, signature validation and claim extraction can diverge, creating an authentication gap even when the cryptography itself appears sound.

What's in the full report

PortSwigger's full post covers the parser-level exploit mechanics this post intentionally leaves for the source:

• Step-by-step exploit construction for Ruby and PHP SAML libraries, including the parser discrepancy chain
• Detailed examples of attribute pollution, namespace confusion, and void canonicalisation in live XML payloads
• Proof-of-concept workflow against a vulnerable GitLab EE instance and the associated tooling notes
• Patch timeline and maintainer responses for the affected SAML and XML libraries

👉 PortSwigger's full post covers the exploit chain, parser differences, and defensive timeline in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.