The Gateway Was a Credential Vault: NetScaler CVE-2026-88771 and What a Patch Can't Undo

On September 24, GreyNoise watched a single IP, 149.104.78.141, throw an exploit at a Citrix NetScaler Gateway. Nobody outside the attacker's crew knew what the bug was. Citrix didn't publish bulletin CTX697096 until Sunday, September 27, and CISA added CVE-2026-88771 and CVE-2026-88772 to the Known Exploited Vulnerabilities catalog the same day. Google Threat Intelligence and Mandiant now say the campaign had been running since at least early September.

Read that timeline slowly. Roughly three weeks of root on the appliance that sits between the internet and your directory, then a weekend bulletin, then a public proof-of-concept that turned a quiet espionage operation into a free-for-all. By the time your patch window opened, the useful work was already done.

I look at intrusions from the offensive side for a living. Most of the coverage this week stops at "web shells deployed," and that's exactly where the part worth your attention begins. Compromising a NetScaler isn't the goal. It's the doorway. What matters is the room behind it.

Two bugs, same room

The two CVEs reach the same outcome by different roads. Both score CVSS 9.5, and both work pre-authentication against default configurations, per watchTowr's FAQ.

CVE-2026-88771 is an input-validation failure that reporting from BleepingComputer ties to a maintenance routine parsing NetScaler log data without sanitising it, a classic log-poisoning setup that ends in command execution as root. CVE-2026-88772 is a memory-corruption bug in the DTLS handling inside the packet engine. Mandiant's write-up describes malformed record headers inducing heap corruption in the NSPPE and diverting control flow to run shellcode with root privileges on the underlying FreeBSD. DTLS is on by default for VPN virtual servers, so most Gateway deployments qualify without anyone touching a setting.

Different flaws. Same result: root, no credentials required, from the open internet.

Fixed builds, from Citrix and confirmed in the vendor bulletin:

• NetScaler ADC and Gateway 14.1: upgrade to 14.1-73.37 or later
• NetScaler ADC and Gateway 13.1: upgrade to 13.1-64.23 or later
• ADC 14.1-FIPS: 14.1-73.37 FIPS or later

There is no workaround for 88771. For 88772 you can disable DTLS and block inbound UDP/443, which buys time on one of the two bugs and nothing on the other.

Root on the box means root on the secrets

Here's the thing people underestimate. A NetScaler isn't a router that happens to terminate TLS. It's an identity broker. It holds the bind credentials for your LDAP directory so it can authenticate your VPN users. It holds RADIUS shared secrets, TACACS credentials, SNMP community strings, and NITRO API keys. It brokers sessions into StoreFront, virtual desktops, and whatever internal segment the Gateway fronts. Every one of those secrets lives in the appliance config, and root reads the appliance config.

So when Google says attackers used their tooling in at least one intrusion to "manually conduct reconnaissance and steal credentials," don't picture a smash-and-grab. Picture someone with a shell and three unhurried weeks, sitting on the one box that already knows how to talk to your domain controllers.

The toolkit Mandiant documented is built for exactly that patience. WHIPSHOT is a PHP web shell dropped into the VPN scripts directory and disguised as a Debian package, with its command traffic hidden inside HTTP headers like HTTP_NSC_LDAP and its responses wrapped so error logging stays quiet. It pairs with SLAPSHOT, a Python TCP tunnelling daemon that turns the compromised appliance into a bridge and forwards arbitrary traffic to internal hosts. It even auto-terminates after ten minutes of inactivity so it doesn't sit there humming when nobody's driving it. This is not noisy malware. It's a quiet proxy that makes the attacker look like the gateway itself, because functionally, it is.

That framing is the whole problem for defenders. Traffic from a NetScaler to a domain controller is not an anomaly. It is the appliance's job. When the attacker rides that same path, your netflow, your SIEM correlation rules, and your EDR on the DC all see a trusted device doing trusted things.

There's a nastier wrinkle specific to these boxes. The LDAP bind account a NetScaler uses is often over-provisioned. In more engagements than I'd like to admit, that "read-only directory lookup" account turned out to have write access somewhere it shouldn't, or membership in a group that had drifted over the years. Whoever set up the Gateway five years ago is gone, the account still works, and nobody has re-scoped it since. Root on the appliance hands the attacker that account verbatim, and it's already trusted by the directory it was built to query. You don't have to escalate a privilege you were handed on setup.

The patch is the beginning of the work, not the end

This is where I get frustrated with how these advisories land. "Patch immediately" is correct and also insufficient, and Mandiant's own guidance says as much: examine systems for compromise before you upgrade, because patching over a live implant just gives you a clean-looking box with a stranger still inside its address space and, more importantly, still holding the secrets it read last week.

Rotating credentials after a perimeter identity box gets popped is not a checkbox. Google's list runs long for a reason: NetScaler admin accounts, local appliance accounts, SSH keys, TLS private keys, LDAP bind and service accounts, RADIUS and TACACS secrets, SNMP strings, NITRO keys, and then the downstream blast radius, StoreFront, Delivery Controllers, and any domain accounts the appliance could authenticate as. Kill the active admin, Gateway, and ICA sessions too. If you patch and skip the rotation, you have fixed the way in and left the keys on the table. We made this same argument about Artifactory tokens outliving the fix in our breakdown of why patching Artifactory doesn't evict anyone, and the lesson transfers cleanly: the vulnerability was the door, the credentials are the tenancy.

The numbers say most people won't do the hard part

The exposure figures are grim in a familiar way. Shadowserver counts more than 23,000 exposed instances, roughly 22,000 ADC appliances and 1,500 Gateways. Palo Alto's Cortex Xpanse puts potentially vulnerable instances north of 50,000. Help Net Security cites around 42,000 internet-facing hosts, 32 percent of them in the United States and 13 percent in Germany.

And patching? Kevin Beaumont, tracking this closely, put the patched share of exposed hosts below 10 percent as of September 29, while counting more than 100 victim organisations, each carrying a unique web shell that can't be scanned for remotely unless you're the person who planted it. Sit with that last detail. The implants are bespoke per victim. There is no clean external scan that tells you you're clean. CISA's Binding Operational Directive 26-04 gave federal civilian agencies until September 30 to patch, but a patch deadline measures the door, not the tenancy.

Xavier Bellekens of Lupovis said his sensors logged live exploitation within minutes of watchTowr's PoC dropping. His advice was blunt: if you run NetScaler and haven't patched, assume you're already being probed. I'd extend it. If you were exposed during September, assume the credentials on that box are burned and act like it.

What actually catches the quiet tenant

If your detection strategy for a compromised identity broker depends on spotting bad-looking traffic, you've already lost, because there isn't any. The attacker inherits the appliance's trust. The gap is the same one we keep hitting: legitimate-looking access from a legitimate-looking source. It's the reason stolen sessions and shadow identities slip past login-based alerting, and the reason a bypass that mints valid sessions leaves almost nothing to investigate.

What changes the math is planting something that has no business being touched. Suppose the LDAP config on that appliance references a service account that does nothing, authenticates nothing, and exists only to be found by someone reading the config with root. A honeytoken like that has one property that behavioural analytics can't offer here: zero false positives. Nobody legitimate ever uses it, so the first authentication attempt against it is, by definition, an intruder who has already read your gateway's secrets. You're no longer trying to distinguish a malicious LDAP query from ten thousand real ones. You're waiting for a specific account that should never light up to light up once.

Same logic works a layer out. A MineField decoy service on the internal segment behind the Gateway is not something a real user reaches through legitimate VPN flow. When SLAPSHOT starts forwarding TCP streams to internal hosts to map the environment, the decoy is exactly the kind of target that reconnaissance touches and normal operations never do. The attacker's own methodical, patient sweep, the thing that makes them hard to catch on volume, is what trips a tripwire that only reconnaissance ever reaches.

None of this replaces patching or rotation. It changes what happens during the weeks you didn't know you were owned, which in this case was most of September. Detection that fires on the intruder's use of stolen trust, rather than on the presence of an implant you can't fingerprint, is the only kind that would have caught this campaign before Citrix named it.

If your NetScaler faced the internet this month, treat every secret it held as compromised, then go read your own config the way an attacker with root already did, and decide what a fake account in that config would have told you three weeks ago. Book a Mine2 demo and we'll show you how the tripwire gets planted before the next zero-day gets its bulletin.