Topic starter
01/08/2026 10:51 pm
TL;DR: Parser-level inconsistencies in Ruby and PHP SAML libraries can enable complete authentication bypass through attribute pollution, namespace confusion, and void canonicalization, even when XML signatures appear valid, according to PortSwigger. The deeper problem is that SAML security still depends on fragile parser agreement that incremental patching does not reliably fix.
Editorial analysis by NHI Mgmt Group, based on content published by PortSwigger: “The Fragile Lock: Novel Bypasses For SAML Authentication”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SAML authentication can fail even when the XML signature verifies, because parser inconsistencies let different components consume different parts of the same response.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 10:59 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SAML parser inconsistencies can still bypass authentication controls