Three NetScaler ADC and Gateway zero-days in a fortnight, two of them used to get root on internet-facing appliances weeks before anyone knew they existed. The patches are out, and most organisations will apply them, tick the box and move on. That is the mistake. If an appliance was compromised before you upgraded, the attacker may already have its configuration: password hashes, TLS private keys, and the service accounts it uses to talk to Active Directory. Upgrading the firmware rotates none of it.
This piece sets out what happened, what the attackers did on the box, and how to hunt in Microsoft Sentinel and Defender for credentials stolen from a NetScaler being used somewhere else.
Update, 9 October 2026: on 8 October Citrix published a further critical fix, CVE-2026-107406, for appliances configured for SAML. It is not reported as exploited, but it moves the minimum safe builds again. The fixed versions below have been updated.
What happened
- Early September 2026: exploitation of CVE-2026-88772 begins. Google Threat Intelligence Group and Mandiant trace in-the-wild activity back to at least early September, against government, financial services, education, legal and professional services organisations in North America and Europe.
- 27 September: Citrix discloses eight vulnerabilities (CVE-2026-88771 to CVE-2026-88778). CVE-2026-88771 and CVE-2026-88772 go straight onto CISA's Known Exploited Vulnerabilities catalogue, and US federal agencies are given until 30 September to patch or disconnect.
- 30 September to 1 October: GTIG and Mandiant publish details of two post-exploitation tools, WHIPSHOT and SLAPSHOT. Separate incident reports, including from Rapid7 and LevelBlue, describe configuration theft and rogue administrator accounts.
- 4 October: a third zero-day, CVE-2026-88779, is disclosed in appliances configured for SAML and added to the KEV catalogue the same day.
- 8 October: Citrix publishes CTX697191 for CVE-2026-107406, another SAML memory overflow. Some builds released only days earlier are still affected.
This comes on top of CVE-2026-8451 in July. For anyone running these appliances, 2026 has been a year of emergency change windows.
The vulnerabilities
CVE-2026-88771: unauthenticated RCE (CVSS 9.5)
Improper input validation that leads to remote code execution, with low attack complexity, in default configurations. Disabling a feature does not mitigate it. You have to upgrade.
CVE-2026-88772: DTLS memory corruption (CVSS 9.5)
A memory-overflow flaw reachable over UDP/443 when DTLS is enabled, which it is by default on Gateway virtual servers. GTIG describes attackers sending "specially malformed or fragmented record headers" to corrupt heap memory and gain root-level operating system privileges. Disabling DTLS and blocking UDP/443 reduces exposure to this flaw only, not to CVE-2026-88771.
CVE-2026-88779: SAML memory overflow (CVSS 8.7)
Affects appliances configured as a SAML service provider or identity provider. A single crafted request crashes the authentication service, and Rapid7 notes that repeated crashes reboot the appliance. On its own it is a denial of service. Researchers have flagged that it may also help attackers trigger the other two flaws.
CVE-2026-107406: SAML memory overflow (CVSS 9.5)
A memory overflow that Citrix says can lead to remote code execution or denial of service. It needs the appliance to be configured as a SAML service provider or identity provider. On builds 14.1-73.37 to 14.1-73.41 and 13.1-64.23 to 13.1-64.28, only identity provider configurations are affected. Older builds are affected either way. To check, look for add authentication samlAction (service provider) or add authentication samlIdPProfile (identity provider) in the running configuration. Citrix lists no workaround, and the bulletin does not report exploitation. Given this year's pattern, we would not wait for that to change.
Fixed versions
Upgrade to builds that address all four:
- NetScaler ADC and Gateway 14.1-73.46 or later
- NetScaler ADC and Gateway 13.1-64.29 or later
- NetScaler ADC 14.1-FIPS 14.1-73.46 FIPS or later
- NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.283 or later
Builds 14.1-73.37 and 13.1-64.23, released for the first wave, do not fix CVE-2026-88779. Builds 14.1-73.41 and 13.1-64.28, released for the second, do not fix CVE-2026-107406 on appliances acting as a SAML identity provider. Secure Private Access hybrid deployments that use NetScaler instances also need upgrading. Versions 12.1 and 13.0 are end of life and get no fix at all.
What the attackers did on the box
Across the published incident reports the post-exploitation pattern is consistent, and it is aimed at staying in and taking credentials.
- WHIPSHOT, a PHP web shell disguised as client download files under paths such as
/vpn/media/nsgclient.icoand/vpn/scripts/linux/nsgclient*.deb. The Apache configuration is modified so those file types execute as PHP. Commands arrive Base64-encoded in an HTTP header, and every response is a spoofed 404, so casual checks see nothing there. - SLAPSHOT, a Python tunneller that proxies TCP traffic from the appliance into the internal network. It shuts itself down when idle and deletes its working files (
/tmp/.uxdport,/tmp/.uxdlock), so its absence proves little. - Root persistence via
chmod u+s /bin/sh, with references scrubbed from/etc/crontab. - Configuration theft. Rapid7 saw
/flash/nsconfigarchived and taken. LevelBlue saw a new superuser account created (sec_monitor).
A NetScaler sits between the internet and your identity provider. Compromise of the appliance is rarely the objective. It is the route to the credentials the appliance holds.
Why patching is not the end of it
Rapid7 lists what /flash/nsconfig contains: encrypted administrator passwords, SSL certificates and private keys, and SSH host keys. Mandiant's guidance is to rotate "all credentials it handled", including LDAP and RADIUS credentials. In a Microsoft-centric estate, that means:
- The LDAP bind account. Gateways that authenticate users against Active Directory hold a service account to do it, often over-privileged and rarely rotated. Treat it as compromised.
- TLS private keys. A stolen key for your Gateway's public certificate lets an attacker impersonate it convincingly. Reissue and revoke, don't just reinstall.
- SAML trust material. If the appliance is a SAML service provider for Entra ID or another IdP, review the signing certificates and the federation trust.
- Local NetScaler administrators, including nsroot, and any accounts you did not create.
- Active user sessions. After upgrading, terminate existing sessions, as was standard advice after earlier NetScaler incidents, so no stolen session survives the patch.
The order of operations
- Preserve evidence first. Take logs, a configuration export and a snapshot before upgrading. The upgrade can destroy the indicators you need to decide whether you were compromised.
- Check for compromise. Run Citrix's indicator-of-compromise script and look for the artefacts above: unexpected PHP handlers in
httpd.conf, PHP content in.deb,.sigor.icofiles, a setuid/bin/sh, and unknown system users. - Upgrade to the builds listed above.
- Terminate sessions and rotate everything the appliance held.
- If you find evidence of compromise, rebuild. Deploy a fresh instance from clean firmware rather than cleaning a box an attacker had root on, then treat it as an incident in the wider network.
Hunting for the downstream intrusion
The appliance is the start of the chain. The question that matters for most organisations is whether anything taken from it was used inside the network. These queries are starting points for Microsoft Sentinel and Defender XDR. Field names depend on how your NetScaler logs are ingested, so tune them to your environment before relying on them.
1. The LDAP bind account used from anywhere but the appliance
Defender for Identity sees every authentication against your domain controllers. The bind account should only ever authenticate from the NetScaler's own addresses.
let NetScalerIPs = dynamic(["10.0.0.10", "10.0.0.11"]); // NSIP and SNIP addresses
let BindAccounts = dynamic(["svc-netscaler-ldap"]); // your bind account(s)
IdentityLogonEvents
| where TimeGenerated > ago(45d)
| where AccountName in~ (BindAccounts)
| where IPAddress !in (NetScalerIPs)
| summarize Logons = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
Targets = make_set(DestinationDeviceName, 20)
by AccountName, IPAddress, Protocol, ActionType
Any result here deserves a full investigation. The 45-day window is deliberate: exploitation goes back to early September.
2. The appliance reaching into internal hosts
SLAPSHOT's job is to tunnel from the NetScaler into the network. Gateways legitimately talk to back-end applications, but they rarely open SMB, RDP or WinRM sessions to workstations and servers.
let NetScalerIPs = dynamic(["10.0.0.10", "10.0.0.11"]);
DeviceNetworkEvents
| where TimeGenerated > ago(45d)
| where ActionType == "InboundConnectionAccepted"
| where RemoteIP in (NetScalerIPs)
| where LocalPort in (22, 135, 445, 3389, 5985, 5986)
| summarize Connections = count(), Ports = make_set(LocalPort), FirstSeen = min(TimeGenerated)
by DeviceName, RemoteIP
3. Administrative changes on the appliance
If NetScaler audit logs reach Sentinel through Syslog, look for accounts being created or changed and shell access you did not schedule:
Syslog
| where TimeGenerated > ago(45d)
| where SyslogMessage has "CMD_EXECUTED"
| where SyslogMessage has_any ("add system user", "set system user",
"bind system user", "shell")
| project TimeGenerated, HostName, SyslogMessage
| order by TimeGenerated desc
An attacker with root can bypass the audited CLI entirely, so an empty result is not a clean bill of health. A hit, though, is unambiguous.
The edge is the attack surface
The wider lesson is not specific to one vendor. Remote access gateways, VPN concentrators and mail gateways are internet-facing, highly trusted, poorly instrumented and patched on change-control timescales. They are where zero-days get spent. Few organisations get endpoint-grade telemetry from these devices, so the practical defence is to watch what they are trusted to do inside the network: authenticate users, bind to directories, reach back-end systems. Then you notice when that trust is used by someone else.
How a managed SOC helps
- Someone watching while the vendor is still investigating. Our SOCs are manned 24/7. When a zero-day lands on a weekend, as CVE-2026-88779 did, the hunt starts that weekend.
- Investigation that follows the chain. CYBERSHIELD AI's Investigation Agent works each alert through to a verdict, averaging 3m 30s, or 7m 50s where the incident needs Advanced Investigation. That means connecting the bind-account logon to the appliance it should have come from, not judging it in isolation.
- Analysts who sign it off. On the managed service, senior analyst sign-off is the default. When a case needs hands-on response, our incident responders are on shift around the clock.
- Microsoft-native. We have run Microsoft Sentinel since 2019, and the connectors, parsers and analytics for the rest of the estate, network appliances included, are built at onboarding as part of the managed service.
If you patched a NetScaler in the last fortnight and are not certain nothing left with the config, talk to our team about a compromise assessment.