Citrix NetScaler Zero-Days (CVE-2026-88771, CVE-2026-88772): Patch, Then Hunt

If you run Citrix NetScaler ADC or NetScaler Gateway and are not yet on one of the fixed builds listed below, upgrade now. If the appliance was reachable from the internet at any point in September, also assume the upgrade is only half the job: both flaws were being exploited before Citrix disclosed them, and none of the vendor reports says an upgrade removes what attackers installed.

This article covers what is confirmed, where the vendor reports differ, and the order to work in.

What Citrix disclosed

On September 27, 2026, Citrix published security bulletin CTX697096 covering eight vulnerabilities, CVE-2026-88771 through CVE-2026-88778. Two of them were already under attack. BleepingComputer quotes the bulletin as saying exploits of CVE-2026-88771 and CVE-2026-88772 “on unmitigated NetScaler deployments have been observed.”

The details below come from the CVE records that NetScaler itself published as the CVE Numbering Authority (the organization authorized to assign and describe CVE IDs for its own products).

CVSS (Common Vulnerability Scoring System) is the industry-standard 0 to 10 severity scale; these scores use version 4.0.

The other six CVEs in the bulletin, CVE-2026-88773 through CVE-2026-88778, carry CVSS 4.0 base scores between 7.0 and 9.3 in their CVE records. As of October 3, 2026, none of the six is in CISA’s Known Exploited Vulnerabilities catalog. All eight records list the same fixed builds.

Affected and fixed builds

A formatting note: seven of the eight CVE records write the last build as “13.1.37.279”, while the record for CVE-2026-88773 and Tenable’s summary write “13.1-37.279”, the format NetScaler build numbers normally use. We read these as the same build; confirm the exact build string on the Citrix download page before upgrading a FIPS or NDcPP appliance.

Versions 12.1 and 13.0 are end-of-life and receive no security updates. Tenable noted on September 27 that Citrix had not said whether they are affected. If you still run either, the absence of a statement is not evidence of safety; plan the migration rather than waiting for one.

The DTLS precondition

Rapid7 and Tenable both report that CVE-2026-88771 affects default configurations, while CVE-2026-88772 requires DTLS to be enabled. DTLS (Datagram Transport Layer Security) is TLS adapted for UDP, and NetScaler Gateway uses it on UDP port 443 alongside the usual TCP port 443.

That precondition narrows less than it sounds. NetScaler’s own documentation states: “By default, the DTLS functionality is set to ON for the existing SSL VPN virtual server.” Unless someone turned it off, a Gateway deployment meets the condition.

What is known about exploitation

Three security vendors have published observations. They do not contradict each other, but each describes only what its own telemetry or incident response work showed, so the dates differ.

The practical reading: the exposure window for an unpatched, internet-facing appliance opened weeks before the bulletin, not on the day of it. Unit 42 does not attribute the activity to a named group.

On scale, Unit 42 says its Cortex Xpanse scanning “identified 50,277 exposed instances that could potentially be vulnerable” as of September 27, 2026. That is a count of exposed appliances, not of confirmed compromises.

Tenable reported no public proof-of-concept exploit for either flaw as of September 27, 2026. Rapid7 reports that exploitation widened after disclosure. Treat the September 27 statement as a point in time, not a current guarantee.

What attackers did after getting in

The behavior described by Google and Rapid7 explains why patching alone is not enough:

• Configuration theft. Rapid7 observed tar czf /var/netscaler/gui/vpn/c -C /flash nsconfig, which packs the configuration directory into a location the web server will hand out. Rapid7 notes that directory holds encrypted administrator passwords, SSL certificates and private keys, and SSH host keys.
• Web shells behind innocent-looking extensions. Google documented changes to /etc/httpd.conf that make Apache run .deb and .sig files as PHP, plus an AliasMatch rule that maps .ico requests under /vpn/media/ onto those files. The shells answer with HTTP 404, so they look like misses in a casual log review.
• Root persistence. Google observed chmod u+s /bin/sh, which sets the SUID bit so later web requests execute with root privileges.
• Tunneling into the network. Google named two tools: WHIPSHOT, a PHP web shell acting as a tunnel front end, and SLAPSHOT, a Python proxy that listens on a loopback port and records it in /tmp/.uxdport.

What to do, in order

1. Preserve evidence before you change anything

If the appliance is a virtual machine, take a snapshot that includes memory before rebooting or upgrading. Google recommends this explicitly, and Citrix’s guidance for a suspected compromise lists a snapshot, a technical support bundle and a packet engine core dump as the first step. An upgrade reboots the device and discards memory-only evidence.

2. Upgrade to a fixed build

Move to the fixed build for your branch from the table above. Google lists the upgrade as its recommended option and advises opening a Severity 1 support case with Citrix if you cannot locate the right build.

If you cannot upgrade immediately, Google describes compensating controls for CVE-2026-88772 only:

• Disable DTLS on internet-facing Gateway virtual servers where you do not need it. The documented command is set vpn vserver <name> -dtls off.
• Block inbound UDP port 443 on the perimeter firewall or edge router. Google warns that ACLs on the appliance are not sufficient, because the traffic reaches the vulnerable packet engine first.

Neither control addresses CVE-2026-88771. They buy time for one of the two bugs; they are not a substitute for the upgrade.

3. Hunt for compromise

Run these on the appliance shell. All commands are taken from Google’s published hunting guidance. A clean result reduces the likelihood of this specific tooling; it does not prove the device is clean.

Check for tampering in the web server configuration:

grep -En -i "application/x-httpd-php|php_flag|AliasMatch" /etc/httpd.conf

Look for handlers that register non-PHP extensions such as .deb or .sig as PHP, and for AliasMatch rules pointing /vpn/media/, /vpn/theme/ or /vpn/images/ at script directories.

Search the web directories for PHP where none belongs:

grep -rlE "<\?php|eval\(|base64_decode\(|shell_exec\(" /var/netscaler/gui/ /netscaler/ns_gui/ /var/vpn/ /netscaler/portal/ 2>/dev/null

Check for the tunneling tool’s files, the SUID shell and stray Python processes:

ls -la /tmp/.uxdport* /tmp/.uxdlock
ls -l /bin/sh
ps aux | grep -E "python.*(\.uxd|uxdport|uxdlock|base64)"

Permissions of -rwsr-xr-x on /bin/sh indicate the SUID change. Either /tmp/.uxd* file means the proxy is running or ran recently.

Also check for two artifacts from Rapid7’s report: a file at /var/netscaler/gui/vpn/c, which is the output path of the archive command it observed, and a web shell at /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver.

In logs, Google flags two patterns worth alerting on. The first is a DTLS handshake failure with ClientVersion DTLSv1.0 and the reason “Handshake failure-Internal Error”, followed within minutes by a crash of NSPPE (the NetScaler Packet Processing Engine) in /var/log/messages. The second is HTTP 404 responses to /vpn/media/*.ico that carry multi-kilobyte bodies.

Network indicators such as IP addresses and file hashes change quickly. Pull current lists from the Google, Rapid7 and Unit 42 reports rather than a copy in an article. Google also publishes YARA rules for the web shells and the configuration tampering.

4. If you find anything, rebuild rather than clean

Citrix’s guidance for a suspected compromise is to remove the appliance from the network, erase and reinstall firmware, upgrade to the latest version, and restore a known good backup that predates the compromise. Google adds one step that is easy to miss in a high-availability pair: disable HA synchronization and assess each node on its own, so a tampered configuration is not replicated to the healthy node.

Given the early September exploitation dates above, a “known good” backup should predate early September 2026 at a minimum, not merely the bulletin. That is our inference from the reported timeline, not vendor guidance.

5. Rotate what the appliance knew

Because the configuration directory was a target, Google advises assuming credentials on a compromised appliance are exposed, and rotating them after the appliance is patched:

• NetScaler administrator and local account passwords, and SSH keys
• TLS certificates and their private keys
• LDAP bind and service accounts, RADIUS shared secrets, TACACS credentials
• SNMP community strings and NITRO API credentials

Invalidate active administrative, Gateway and VPN sessions as well. Citrix’s guidance goes further on restored devices: rotate the Key Encryption Keys and replace all SSL certificates.

Then look downstream. Google recommends reviewing StoreFront servers, Delivery Controllers and virtual desktop hosts for unexpected interactive logons, RDP activity and signs of credential dumping, since the appliance sits directly in front of them.

What the CISA deadline means for you

CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on September 27, 2026, with a due date of September 30, 2026. The catalog entry also requires forensic triage, noting that “customers must conduct forensic triage as directed by BOD 26-04.”

Two points of scope. First, according to Tenable’s analysis of Binding Operational Directive 26-04, CISA issued the directive on June 10, 2026, it applies to US Federal Civilian Executive Branch agencies, and it is not binding on the private sector, though CISA encourages adoption. Second, the due date has already passed. For an organization outside the federal government, the deadline is useful as a signal: three days is the shortest remediation window in the directive as Tenable describes it, and CISA paired the patch with a mandatory compromise check, which is the same sequence recommended above.

The pattern worth fixing after the incident

This section is editorial analysis rather than reported fact.

Edge appliances are attractive targets for structural reasons: they face the internet by design, they hold credentials for the directory and authentication systems behind them, and most cannot run the endpoint detection agents that cover servers and laptops. Three changes reduce the cost of the next advisory of this kind:

• Ship appliance logs off the device. The hunting steps above depend on ns.log, /var/log/messages and the HTTP access and error logs. Logs that live only on the appliance are available to whoever compromises it. Our piece on logging for incidents rather than dashboards covers what to retain.
• Default-deny outbound traffic from the appliance. Google recommends permitting only approved destinations such as DNS, NTP, certificate status checks and the backend applications. A tunneling tool is far less useful on a device that cannot open arbitrary connections.
• Keep management interfaces off the internet. Restrict the NSIP management address, SSH and the NITRO API to administrative networks.

For triage of the rest of your queue, an actively exploited flaw on an internet-facing device is the case that should jump every line. We cover that prioritization in the vulnerability backlog that never shrinks, and the general response sequence in what a zero-day is and how to respond to one.

Sources and verification

Checked on October 3, 2026. We could not load the Citrix bulletin page directly, so bulletin details are taken from the CVE records NetScaler published and from vendors quoting the bulletin; those rows are marked Qualified.

FirewallSync has not tested these vulnerabilities or run the hunting commands against a compromised appliance. This is research-based analysis of the sources above.

Vulnerability ManagementIncident Response