CVE-2026-3055 Bleeds Session Tokens Your NetScaler Barely Logs. The Detection Lives Off the Box

By AutoCypher · 0 days ago 05 Jul 2026

The memory-disclosure bug on Citrix NetScaler is a franchise now. CitrixBleed (CVE-2023-4966), CitrixBleed 2 (CVE-2025-5777), and as of spring 2026 a third entry the writeups are calling CitrixBleed 3: CVE-2026-3055, a CVSS 9.3 overread in the SAML IdP path. It arrived with a supporting cast — CVE-2026-4368, a race condition in Gateway/AAA vservers narrow enough to hit a single build, and CVE-2026-8451, a pre-auth overread in the SAML XML attribute parser that watchTowr documented a few months later. Same root pattern behind 3055 and 8451: Citrix rolled its own parsing logic instead of using a vetted library, the parser reads past a buffer, and adjacent process memory gets handed back to an unauthenticated caller. What lives in that memory is the whole problem. Valid session cookies. SAML assertions. LDAP bind credentials.

The number that should worry you isn’t the CVSS. It’s that the appliance barely logs the activity that triggers the leak, and not in a way you can lean on. Mandiant said it flatly for CitrixBleed 1 back in 2023: the webserver on the appliance doesn’t record requests or errors to the vulnerable endpoints, with no configuration toggle to force it. 3055 is less absolute — watchTowr found that a successful overread can leave odd messages in ns.log (they saw unsupported ProtocolBinding value), but only with logging cranked to a DEBUG verbosity no production appliance runs. So appliance logs are not evidence of non-exploitation: the absence of a message proves nothing, because your box almost certainly wasn’t logging at that level. The event you’d most want in your index — a malformed request that came back carrying kilobytes of process memory — is not in your NetScaler syslog under any normal configuration. So the detection has to come off the box. That’s the part teams get wrong before they get it right, and it’s most of this post.

Where the leak actually happens

CVE-2026-3055 lives specifically in the SAML Identity Provider request handling. On an appliance configured as a SAML IdP, two request shapes walk the parser off the end of its buffer, and they are not equally dangerous. A /saml/login request that omits the AssertionConsumerServiceURL attribute leaks — but stingily: watchTowr found many fields capped around 100 bytes, the read stops at the first null, and getting anything back at all was largely down to luck across hundreds of requests. The reliable, kilobyte-scale leak is the other path — /wsfed/passive?wctx with wctx present but empty — which watchTowr showed returns kilobytes of memory per request with none of the first path’s size limits. Either way the leaked bytes come back base64-encoded inside the NSC_TASS response cookie, and repeating the request returns a different slice of memory. The 8451 pre-auth variant is stingier still (the read terminates on control characters like a null byte or a >), but it can surface pointer values — and watchTowr is careful here: if those are valid process pointers the bug graduates from a plain information disclosure to a genuine info-leak primitive useful for defeating ASLR, which they call plausible rather than certain.

The config prerequisite matters for scoping, and this is the first thing to check before you spend a weekend on it. If your NetScaler is a plain load balancer, or a Gateway with no SAML IdP configured, 3055 and 8451 don’t apply — both live in the SAML IdP path, nowhere else. Grep your ns.conf for samlIdPProfile. And don’t let “we already patched 5777” lull anyone; CitrixBleed 2 was a different endpoint. Patching one memory-overread in this family tells you nothing about your exposure to the next.

Two vantage points, and you might have neither

If the appliance won’t log it, two places can still see it: upstream and downstream.

Upstream means whatever sits in front of the NetScaler and actually logs HTTP. Emphasis on logs. Plenty of shops terminate TLS at the NetScaler itself and run it as the edge, with nothing in front that inspects the response body. If that’s you, there is no upstream vantage, and pretending otherwise wastes the first week. Answer that honestly before writing a single rule. If you do have a reverse-proxy or WAF tier that sees decrypted traffic — an F5 in front, an Nginx layer, a cloud WAF — that’s where the request/response record lives.

The request-side signatures are cheap to write:

GET /cgi/GetAuthMethods in bursts from source IPs with no prior history. Classic recon; it enumerates whether SAML auth is even configured.
POST /saml/login where the decoded SAMLRequest is missing AssertionConsumerServiceURL.
/wsfed/passive?wctx with an empty wctx.

Here’s the trap. Those are all request signatures, and the signal that a leak succeeded is on the response. Most WAF rulesets inspect requests, because inspecting response headers and bodies costs more and a lot of teams simply don’t log the response side. The high-fidelity indicator is a Set-Cookie: NSC_TASS= header that’s anomalously large — hundreds of bytes to kilobytes where the legitimate value is short — whose base64 payload decodes to printable memory junk rather than a valid token structure. A probe is noise. A probe that got a fat NSC_TASS back is an incident.

First-week tuning

Deploy “alert on NSC_TASS length > N” straight out of a blog and you’ll drown by lunch. The NSC_TASS cookie carries legitimate state, and SAML assertions are genuinely large sometimes, so a raw length threshold flags real auth flows. Baseline your own p99 NSC_TASS length across a normal week and alert well above it; if legit traffic sits around 300 bytes, start the alert near 1KB and tune down from there. Better than length alone: base64-decode the value and compare it against what a normal NSC_TASS decodes to in your environment. Don’t reach for an entropy test — a legitimate decoded NSC_TASS isn’t high-entropy random material; watchTowr’s benign examples decode to structured NetScaler state fields like ID=, bind=post, and ACSURL=. Entropy is a bad discriminator in both directions. Baseline that normal decoded structure and length, then score anomalies against it: unexpected embedded delimiters, stray XML fragments, credential-like substrings, pointer-like binary runs, null padding, or any decoded content that doesn’t match the state fields your appliance normally emits. Leaked memory looks like memory; a real NSC_TASS looks like a specific, known structure. That comparison kills most of the false positives length can’t.

/cgi/GetAuthMethods is the other easy own-goal, depending on your environment. In plenty of shops, load-balancer health checks and uptime monitoring hit that endpoint routinely, so the recon rule fires on your own Pingdom and monitoring IPs long before anything hostile — check whether that’s true for your deployment, and where it is, allowlist the monitoring sources first or the rule is dead on arrival.

And /saml/login without an ACS URL isn’t automatically malicious. A misconfigured-but-legitimate service provider that relies on the default ACS binding trips the same signature. Expect a handful of these from your own integrated apps and carve them out by SP entityID.

Volume reality: an internet-facing NetScaler is scanned around the clock, and 3055 has been in CISA’s KEV since 30 March 2026 (with a 2 April federal deadline, which tells you how fast this moved). Post-disclosure, the request-side probes are permanent background hum. Don’t alert on the probe. Alert on the probe that got a large response — and, more than anything, on what the leaked token does next.

Downstream is where the truth is

The memory returned inside NSC_TASS can contain a valid NSC_AAAC session cookie — the Gateway auth cookie — that was issued to a real, already-authenticated user with MFA satisfied and was sitting adjacent in process memory when the overread ran. Replay it and you’re that user. No username, no password, no second factor — the replay works because the NetScaler itself already regards that session as fully authenticated, so it never re-runs the MFA the downstream apps trust it to have enforced. That’s the entire value of the bug, identical to CitrixBleed 1 in 2023. Which means the durable detection isn’t a payload signature at all — it’s session anomaly:

A Gateway or NSC_AAAC session presenting from a source IP or ASN that doesn’t match where it was issued. A valid Gateway session with no preceding authentication event anywhere in the logs, because the auth never happened on this box — the session was born in leaked memory somewhere else. Out-of-hours ICA or VPN launches, sessions originating from residential or hosting-provider ASNs, a user suddenly reaching internal apps they’ve never touched.

This is impossible-travel logic, and it inherits every impossible-travel false positive you already fight. Mobile users roam IPs. Corporate egress shifts. CGNAT collapses thousands of users behind one address. On a flat setup where everyone leaves through a single VIP, the geo signal is close to useless. Tune against your actual population and weight ASN type — residential or hosting versus your known corporate ranges — over raw geographic distance. That catches more real hijacks with fewer roaming false alarms.

The retention caveat bites hard here, so plan for it. Recon started in late March. If your NetScaler and Gateway logs live 14 days hot before they roll to cold storage or get dropped, the sessions that were bled in March are already outside your searchable window. You’re hunting the current replay of tokens leaked weeks ago. Widen the lookback if you can stomach a cold-storage rehydrate; if you can’t, assume leakage happened and act as if it did.

Patching is step one, not the fix

The lesson every shop that ate CitrixBleed 1 already paid for, and half of them are about to relearn: if session material leaked before you patched, patching the appliance stops new leaks but does nothing to invalidate what already bled out. Those sessions stay valid until you kill them. The strongest direct precedent is CitrixBleed 1 — Tenable and CISA both told 4966 customers to invalidate active and persistent sessions after patching — and the same reasoning applies to 3055 wherever session cookies may have been exposed.

Concretely, get onto a fixed build. The public writeups converge on 14.1-66.59 and later (14.1-60.58 is also remediated), 13.1-62.23 and later, and — for the FIPS and NDcPP branches those regulated environments run exclusively, on a different versioning schema — 13.1-37.262 and later. Confirm the exact build against Citrix’s own bulletin anyway, because the aggregators quote slightly different numbers and I would not trust a version string this load-bearing to anyone but the vendor. Then: terminate all active sessions, force re-auth for everyone, and rotate the secrets that could have been sitting in that memory. That last part gets skipped and it’s the one that matters. Public analysis puts LDAP bind credentials and other users’ session cookies squarely in the leaked memory, so the LDAP bind the appliance authenticates with is a rotate-it credential — patch the box, kill every session, leave the LDAP bind in place, and you’ve handed the attacker directory access that outlives all of it. The SAML signing key is a harder call: I haven’t seen public 3055 research demonstrate that the private key itself leaked, so treat it as a risk assessment rather than an assumed loss — decide whether the key material could plausibly have been resident and reachable in that process memory, and rotate on that judgment plus whatever your IR turns up. If you do rotate it, it isn’t a quiet swap — every service provider that trusts your IdP has to be handed the new certificate or its assertion validation breaks, so budget that metadata rollover into the same change window instead of discovering it mid-incident. Drain and invalidate NSC_AAAC, NSC_TMAS, and NSC_TASS as part of the patch change window, not as a follow-up ticket that quietly slips two sprints.

Control mapping

Control	Where it bites here
AU-2, AU-12	Appliance-local logging of the vulnerable path is incomplete and verbosity-dependent — an overread may surface in `ns.log` only at DEBUG levels no production box runs — so appliance logs can’t be treated as authoritative evidence either way. The compensating controls are the upstream HTTP request/response telemetry you own and downstream identity/session analytics.
SI-2	Patch the fixed train. But SI-2 closed on its own, without session invalidation, is an incomplete remediation for this bug class.
SI-4	Response-size anomaly and session-hijack detection live here, off-box. This is the family doing the real work.
SI-16	Memory overread is the root class. On a sealed vendor appliance there’s no vendor-provided configuration that prevents the overread — you can only demand and apply the fix.
AC-12	Killing leaked sessions post-patch is the control that actually closes exposure. Skip it and the patch bought you little.
IA-5	Leaked tokens sidestep MFA entirely. Rotate the authenticators that could have been resident in that memory — the LDAP bind credential and any other bind or shared secret — not just user sessions.
SC-12, SC-13	The SAML signing key is cryptographic key material that could be resident in the same memory, though public 3055 research hasn’t demonstrated a private-key leak specifically — treat rotation as an exposure-risk decision, not an automatic step. If you do rotate, redistributing the new certificate to every SP is mandatory or assertion validation breaks, so plan it as a coordinated change, not a password reset.

Treat any internet-facing NetScaler SAML IdP that was reachable before you patched as already leaked, because you have no appliance log that would tell you otherwise. The overread is invisible to the box that suffered it. Your evidence is a fat cookie in an upstream proxy log you might not keep, and a session doing something the user who owns it never would. Build for the second one — it’s the signal that survives after the patch lands and the scanners move on.