How a SAML Login Flow Works and Where an Unauthenticated Request Gets Parsed

Every few months a gateway vendor ships an emergency fix for a bug in its SAML handling, and every time a subset of administrators are surprised that an unauthenticated attacker could reach that code at all. SAML is the thing that happens after the identity provider verifies the user, isn't it? No. The gateway has to parse attacker-supplied XML before it knows whether a user exists. This article walks the login flow and marks exactly where the untrusted input lands, using the Citrix NetScaler CVE-2026-88779 crash loop from October 2026 as the running example.

The three parties

A SAML deployment has three roles. The **principal** is the user and their browser. The **identity provider (IdP)Identity Provider (IdP)📖A system that creates, maintains, and manages identity information for users while providing authentication services to relying party applications through protocols like SAML or OAuth.** holds the credentials and decides whether the user is who they claim. The **service provider (SP)** is the application or gateway the user actually wants to reach. A NetScaler Gateway in front of a corporate network is usually the SP, delegating authentication to Entra ID, Okta, ADFS, or similar. NetScaler can also act as the IdP for downstream applications, which is why Citrix's bulletin lists both `add authentication samlAction` (SP mode) and `add authentication samlIdPProfile` (IdP mode) as preconditions.

The SP and IdP never talk to each other directly during a login. Everything is relayed through the user's browser. That design choice is why the attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. is where it is.

The flow, step by step

1. The browser requests a protected resource on the SP.
2. The SP has no session, so it builds a SAML **AuthnRequest**: an XML document saying "please authenticate someone and send them back here." It signs it (optionally), base64-encodes it, and redirects the browser to the IdP's single sign-on URL with the request attached.
3. The IdP parses the AuthnRequest, authenticates the user however it likes (password, MFA, device certificate), and builds a SAML **Response** containing an **assertion**: signed XML stating the subject's identity and attributes.
4. The IdP returns an HTML page that auto-submits a form, POSTing the base64-encoded Response to the SP's **Assertion Consumer Service (ACS)Assertion Consumer Service (ACS)🛡️The endpoint on a SAML service provider that receives the signed SAML response from the identity provider and establishes the user's session. It accepts HTTP POSTs from any client by design, which makes its XML parsing pre-authentication attack surface.** URL.
5. The SP decodes the Response, parses the XML, verifies the signature against the IdP's certificate, checks audience, timestamps, and replay conditions, and only then creates a session.

Steps 2 and 4 are the ones that matter for security. Both involve one party receiving XML from the browser, and the browser is under the attacker's control.

Where the unauthenticated parsing happens

The ACS endpoint on the SP accepts an HTTP POST from anyone. It cannot require authentication, because its whole purpose is to establish authentication. The first things the SP does with the POST body are decode base64, inflate if compressed, and parse XML into a document tree. Signature verification comes after parsing, because the signature covers a canonicalized form of the XML that the SP must compute. CanonicalizationCanonicalization🛡️Reducing an input such as a URL path to a single normal form, by decoding escapes, collapsing duplicate separators and resolving relative segments, before any security decision is made about it. Canonicalizing once and then matching prevents the parser disagreements that produce encoding-based authorization bypasses. itself is a complex transformation of the tree, with namespace handling, attribute ordering, and prefix rewriting.

So before any cryptographic check runs, the SP has executed a decoder, a decompressor, an XML parser, and a canonicalizer against bytes an anonymous client chose. If any of those stages has a memory-safety bug, the attacker reaches it with a single POST and no credentials. The CVSS vector on CVE-2026-88779 says exactly this: AV:N, PR:N, UI:N.

The same is true in the other direction. An IdP's single sign-on endpoint accepts AuthnRequests from any browser. If the IdP parses the request before validating that it came from a registered SP, the parser is unauthenticated attack surface too. That is why NetScaler in IdP mode is listed as affected alongside SP mode.

The NetScaler examples

Citrix has fixed three exploited memory-corruption bugs in NetScaler's SAML path in 2026. CVE-2026-8452 in June was a heap overflowHeap Overflow🛡️A memory-corruption bug where a program writes more data into a heap allocation than it was sized to hold, spilling into adjacent memory. When the overwritten neighbor is the allocator's own bookkeeping, an attacker can steer it toward code execution. in signature canonicalization; Bishop Fox documented that the code copied an XML namespace prefix list into a fixed-size buffer without checking its length, and that a single signed AuthnRequest to the SAML login endpoint could corrupt memory. That one sat in the packet engine. CVE-2026-88779, disclosed in October, crashes `nsaaad`, the authentication daemon, after a handful of crafted requests. Administrators reported that the trigger involved the username field on SAML authentication factors.

Three bugs, two components, one input class. The parser is written in C or C++ for performance, it handles a format with many optional and nested structures, and it runs before any trust decision. That combination is what security engineers mean when they call something pre-authentication attack surface. Why a memory bug rated 'denial of service' should be triaged like code execution follows directly: a crash in a pre-auth parser is a memory-safety bug an attacker can reach by design, and whether it stays a crash depends on the attacker's skill, not on the vendor's rating.

What this changes about how you deploy a gateway

**Know which endpoints are reachable anonymously.** On a SAML SP that is at least the ACS URL and the metadataMetadata📖Data about data—like email timestamps, file sizes, or location tags on photos. URL. On an IdP it is the SSO URL. Anything that accepts a POST without a session is a parser you are exposing to the internet.

**Prefer the IdP to do the parsing where possible.** If your gateway supports deferring the heavy XML work to a dedicated identity service and consuming a simpler token, the gateway's pre-auth surface shrinks. Many deployments cannot do this, but it is worth asking.

**Treat SAML configuration as a risk flag in inventory.** Citrix's bulletin was explicit that only appliances with the SAML directives were affected. Organizations that could answer "which of our NetScalers have SAML actions bound" within minutes patched the right boxes first. Those who could not patched everything or guessed.

**Rate-limit and geo-fence the ACS and SSO URLs if the product allows it.** The October exploitation reportedly involved a large volume of SAML requests. A parser bug that needs many attempts to trigger is less useful against an endpoint that drops the hundredth request from the same source. This is a mitigation, not a fix.

**Plan for the HA failover case.** When a crafted SAML request crashes the authentication daemon, the standby node that takes over receives the same request. How to keep a crash-loop exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. from taking down both nodes of an HA pair covers what to do about that.

The short version

A SAML gateway parses attacker-controlled XML before it checks any signature, because it has to. That parser is reachable by anyone who can send an HTTP POST, and on NetScaler it has now failed three times in a year. If you run SAML on an edge appliance, the question is not whether the parser will have another bug, but whether you will find out from the vendor's bulletin or from your appliance rebooting at 2 a.m.