CitrixBleed 2 Is a Whitespace Bug: How CVE-2026-8451 Leaks Live NetScaler Sessions Through NSC_TASS

Every SAML identity provider we hunt against looks bulletproof from the outside: it terminates TLS, verifies signatures on tokens, and hands sessions back to a workforce that trusts the little green padlock. Then someone at watchTowr shows us that the padlock has a servant door marked "unquoted attribute values," and everyone in the room remembers why hand-rolled XML parsers used to keep us up at night.

CVE-2026-8451 is that servant door for Citrix NetScaler ADC and Gateway. Citrix disclosed it on 30 June 2026 in advisory CTX696604 at 8.8 CVSS. Lupovis caught real exploitation on internet-facing sensors the following day, and CrowdSec tracked broader scanning against NetScaler IdP endpoints. The nickname "CitrixBleed 2" stuck because the end state matches the original CVE-2023-4966: live session tokens fall out of an appliance that stands in front of your workforce, and the operator walks past MFA holding someone else's cookie.

Two characters the SAML parser never learned to fear

The vulnerable code is a custom XML parser NetScaler ships to handle inbound SAML AuthnRequest documents at /saml/login. Aliz Hammond of watchTowr Labs, who reported the bug, traced the primitive to attribute-value handling. XML permits attribute values written as Foo="bar" with quotes or, in permissive readers, as Foo=bar with no quote at all. NetScaler's parser accepts the unquoted form, and the loop that walks the value stops only when it hits one of three sentinels: a null byte, a closing >, or a matching quote. Whitespace, tabs, and newlines are treated as though the value is still going.

Feed the parser an <samlp:AuthnRequest> document with an unquoted attribute followed by a long whitespace run and no closing sentinel, and it reads past the end of the attribute buffer into whatever memory lives after it. The parser copies that data into the NSC_TASS cookie value it sets on the response, so adjacent memory is echoed straight back to the attacker in plain HTTP.

The bug class is CWE-125 out-of-bounds read, and the reason the leak is dangerous rather than merely embarrassing is what NetScaler stores next door. An appliance configured as a SAML IdP is a session broker for the whole workforce, holding session tokens, cookies, and partial credentials in memory for users it has just authenticated. Adjacent memory is the payoff.

Base64 in, session tokens out: what an exploit request looks like

The wire pattern is unglamorous, and that is a big part of what makes it dangerous. Exploitation is a single unauthenticated POST to /saml/login on any internet-facing NetScaler IdP, carrying a SAMLRequest parameter whose base64 payload decodes to an <samlp:AuthnRequest> element with a single unquoted attribute and a long run of trailing whitespace. That request survives every check the appliance runs before parsing, because parsing IS the check. Both CrowdSec and The Hacker News reproduced the request shape from watchTowr's write-up.

The response is a normal 200 OK with a Set-Cookie: NSC_TASS= header whose value is much larger than any legitimate session cookie should be. Inside sits a chunk of live process memory. Repeat the request a few hundred times and the attacker collects a corpus of session identifiers, cookies, and stray credentials belonging to users who authenticated through the same appliance moments earlier. CrowdSec logged the exploit landing from a Frankfurt IP (146.70.139.154) that swept sensors for hours on 30 June, dropping the payload only on hosts that returned 200 OK, a fingerprint worth pivoting on if you own IDS or perimeter capture.

Session hijack from there is uneventful. The attacker replays a leaked token against the NetScaler Gateway and the appliance accepts it as its own paperwork, with no password prompt and no MFA challenge, because the appliance itself is the identity provider. CyberScoop traces the resemblance to the 2023 original: MFA is only as strong as the box that hands out the session ticket after MFA passes.

Why this walks past every appliance-side control

A working NetScaler sees a torrent of SAML requests every business day, and the malicious ones look no different from the legitimate ones until they are inside the parser. The primitive here is a read rather than a write, so nothing crashes and nothing pattern-matches on shellcode. There is no exec, no file write, and no /etc/passwd string in the request body for a conventional appliance-side WAF or IPS rule to fire on, because "SAML with an unquoted attribute" is not a signature anyone was writing.

The response side is only slightly more visible. NSC_TASS is a legitimate NetScaler cookie name, and appliances have always been chatty about setting cookies. What changes under exploitation is the size and entropy of the value, because the leak is binary memory rather than a clean session identifier, and that difference is only detectable if someone is watching the shape of outbound cookies.

Where the tell lives in your logs

Start with NetScaler access logs. Search POST /saml/login events for SAMLRequest values whose base64 decodes to <samlp:AuthnRequest> with no Issuer, no signature, and an unusual whitespace run before the closing tag. Repeated hits from a single source IP with a stable user agent and no follow-through into an authenticated session are scan behaviour, not authentication behaviour. CrowdSec's detection rule captures the request shape and is worth pulling into whatever perimeter tooling you own.

On the response side, hunt for Set-Cookie: NSC_TASS= values whose length sits outside the normal band or whose content includes non-printable byte ranges. If you have TLS-terminating visibility in front of the NetScaler, this is the cheapest query to run and the least noisy signal you will get. In ATT&CK terms, initial access maps to T1190 (Exploit Public-Facing Application), the memory disclosure to T1552 (Unsecured Credentials), the session replay to T1550.004 (Web Session Cookie), and eventual pivoting to T1078 (Valid Accounts).

Downstream, watch identity logs for stolen sessions replayed from mismatched geography. A user whose SSO fired from a Seattle office at 09:00 UTC and whose session cookie shows up posting to SharePoint from a Frankfurt VPS at 09:04 UTC has been session-jacked, not phished. Correlate NetScaler logs, SSO logs, and EDR user-attribution telemetry through the same alert path so a single stitched event fires instead of three quiet ones nobody investigates.

Patch, invalidate, and prove the leak is closed

Fixed builds are in CTX696604: NetScaler ADC and Gateway 14.1 at 14.1-72.61 or later, and 13.1 at 13.1-63.18 or later. FIPS and NDcPP builds carry their own fixed versions in the same advisory. If you cannot patch immediately, disabling the SAML IdP configuration on internet-facing appliances removes the exposed endpoint entirely and buys back the runway.

Patching alone does not close the incident, because the entire point of a memory-disclosure bug is that the damage is done before you notice. Once the new build is on the wire, invalidate every existing session on the affected appliances so leaked tokens are no longer replayable, then rotate credentials for accounts whose sessions could have been active during the exposure window. Retroactively hunt /saml/login traffic and oversized NSC_TASS responses in whatever historical capture you keep.

Verifying the fix held is the part that quietly bites most fleets. A build number in the CMDB does not prove the code path is patched: a rollback after a compatibility complaint, an HA pair with one node missed, or a change-control freeze on the standby all re-open the door. Replay a benign exploit request on a schedule from an allowlisted internal source and confirm the response is a normal cookie value rather than padded memory. When that check fails, it should page the on-call before it shows up on someone else's blog.

Where this sits for us

CitrixBleed keeps returning under new CVE numbers because the detection story and the validation story are separate problems, run out of separate tools. BlueTeamAutomation runs BASzy safe-payload simulations against your NetScaler and the identity fabric on a schedule, correlates the appliance, EDR, and SIEM signals through one SOAR loop, and keeps the compliance evidence live so the next KEV entry is a scheduled test rather than an all-hands scramble.