What happens when a SAML parser accepts external entities in a login flow?

Why external entities turn a login parser into a network pivot

External entities change the parser from a passive validator into an active retriever. That matters because XML processing can then reach out to URLs, file paths, or other referenced resources before the login request is fully evaluated. In a SAML flow, the security boundary is no longer just signature validation and assertion handling, it also includes whatever the parser is allowed to fetch during parsing.

The practical consequence is blind SSRF: the application may make outbound requests on behalf of the attacker without exposing the response directly. Even when the application never reflects the fetched content, the request itself can still reveal internal host reachability, port exposure, DNS behavior, or metadata endpoints. Similar abuse patterns show up in token and federation incidents where a seemingly narrow identity path becomes an access path into adjacent systems, as seen in Salesloft OAuth token breach and Klue OAuth Supply Chain Breach.

When SAML is involved, the impact is not limited to “bad XML hygiene.” The login request may become a probe against internal services, a way to test segmentation, or a stepping stone to higher-impact exploitation if the target can reach sensitive internal endpoints. If the parser also processes DTDs, local file references, or parameter entities, the abuse surface widens further, but the key security issue is the same: parsing behavior is now part of the attack surface.

What failure conditions make XXE dangerous in authentication flows?

The dangerous failure condition is not just that XML is accepted, but that the parser is configured to resolve external references during a trust-sensitive operation. In a SAML login flow, that usually means the application is handling an attacker-influenced document before it has established whether the document should be trusted at all. That sequencing error can turn a verification step into an outbound request engine.

Commonly overlooked details include whether the parser blocks external general entities, external parameter entities, and remote schema or DTD fetching. A flow can still be vulnerable even if response data is never displayed, because the attacker only needs the server to initiate the request. In practice, this often becomes a test of network egress controls, segmentation quality, and whether internal services are exposed to “trusted” application tiers that should not be able to reach them.

For readers comparing this to adjacent identity issues, the important distinction is that the parser weakness is upstream of identity enforcement. The login system may still validate signatures correctly, but the XML layer can independently create network activity that was never intended by the authentication design. That is why the issue is often discovered as a recon primitive first, then escalates only when the environment has weak internal reachability boundaries.

Practitioner Guidance

What to verify: Confirm that the SAML processing stack disables DTD loading, external entity resolution, and all remote retrieval paths during login request parsing. If the parser cannot be configured safely, isolate it from any network path that could make internal SSRF useful to an attacker.

Common mistake: Treating signature validation as sufficient hardening. A valid SAML signature does not neutralize parser-side retrieval behavior, and a “successful login flow” can still be a useful network probe if the XML layer is permissive.

What good looks like: The parser rejects or ignores external references, the application has tightly scoped egress, and internal services do not trust requests simply because they originate from an identity component. If the environment must process complex XML, the safe default is to remove fetch capability rather than trying to whitelist it piecemeal.

Practitioner takeaway: In SAML, parsing is part of the trust boundary, so any feature that lets attacker-controlled XML trigger outbound requests should be treated as an authentication-path exposure, not a formatting bug.

Related resources from NHI Mgmt Group

• Why do SAML integrations often fail in practice even when the login flow appears to work?
• What happens when SAML settings can be changed without external verification?
• What breaks when SAML signature verification is treated as optional in a help desk login flow?
• What happens when an open redirect is combined with a login or registration flow?