Citrix NetScaler CVE-2026-88771 and CVE-2026-88772: Check for Compromise Before You Upgrade

Take a support bundle off every internet-facing NetScaler before you install the fixed build. The upgrade is the right move, and it is also the step most likely to erase the only record of whether somebody reached the appliance first.

Cloud Software Group published bulletin CTX697096 on September 27, covering eight flaws in NetScaler ADC and NetScaler Gateway. Two of them, CVE-2026-88771 and CVE-2026-88772, were already being exploited when the patches shipped. Both score CVSS v4.0 9.5. Each one gives an unauthenticated attacker code execution on the appliance without help from the other. Citrix put it in one line: "Exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated NetScaler deployments have been observed."

CISA added both to the Known Exploited Vulnerabilities catalog the same day and set the remediation due date at September 30 under BOD 26-04. That is a three-day clock for federal civilian agencies, and a defensible clock for everyone else. Shadowserver counts roughly 23,000 IP addresses answering with a NetScaler fingerprint, about 22,000 of them ADC and just over 1,500 Gateway. Nobody knows how many are on a fixed build.

Who this reaches, and who can stop reading

Close the tab if every NetScaler capability you consume is a Citrix-managed cloud service. Cloud Software Group patches its own infrastructure and Adaptive Authentication, and there is nothing on your side of the line. One exception is worth checking before you walk away: Secure Private Access Hybrid deployments run customer-managed NetScaler instances, and those instances are yours to upgrade.

This one is yours if you run NetScaler ADC or NetScaler Gateway as an appliance you own, virtual or physical, on an affected build. A common way to talk yourself out of it fails here. CVE-2026-88771 carries no feature precondition at all. Citrix lists it as affecting the default configuration, so "we only use it for load balancing, not VPN" does not exempt you from the worse of the two bugs. It only exempts you from the second one.

Managed service providers carry this twice. You own the inventory question for every client appliance you touch, including the ones a client bought years ago and forgot to tell you about. A NetScaler that nobody has logged into since the last certificate renewal is still answering on 443 today.

What the two exploited bugs require

CVE-2026-88771 is an improper input validation flaw that lets a remote, unauthenticated attacker execute arbitrary commands on the appliance. Network reachability is the whole precondition. No account, no feature flag, no unusual configuration.

CVE-2026-88772 is a memory overflow that can end in remote code execution or a denial of service. It requires DTLS to be enabled, which sounds like a narrowing condition until you remember that DTLS is on by default for VPN virtual servers. If you run NetScaler Gateway for remote access and nobody has explicitly turned DTLS off, assume you meet the condition and verify it rather than guessing.

The other six flaws in the same bulletin are not on the KEV catalog and have preconditions worth reading before you triage: CVE-2026-88773 (HTTP request smuggling, 9.3, HTTP configuration enabled), CVE-2026-88774 (feature policy bypass through HTTP URL expressions, 7.0), CVE-2026-88775, CVE-2026-88776 and CVE-2026-88777 (memory overflows leading to denial of service, 8.8 each, tied to Gateway or AAA virtual servers, Oracle load balancing, and non-HTTP L7 features respectively), and CVE-2026-88778 (TCP initial sequence number prediction, 8.8).

Establish your build and your DTLS state from the appliance itself, not from a spreadsheet:

# From the NetScaler CLI. Record the exact build string, not just 14.1.
show ns version

# Which VPN virtual servers exist, and is DTLS on for each one?
show vpn vserver
show vpn vserver <vserver-name> | grep -i dtls

# Same answer straight from the saved config, useful for a fleet sweep.
# An absent "-dtls OFF" on a VPN vserver line means DTLS is at its default: ON.
shell
grep -iE "add vpn vserver|set vpn vserver" /flash/nsconfig/ns.conf | grep -i dtls
grep -c "add vpn vserver" /flash/nsconfig/ns.conf

The August patch is not this patch

This is the detail that will bite the teams who feel current. CVE-2026-19490, the SAML unsigned-assertion bypass from August, was fixed in 14.1-73.32 and 13.1-63.21. Those builds do not fix either of the exploited zero-days. An appliance patched six weeks ago and left alone is fully exposed to CVE-2026-88771 today.

The builds that carry the fix, per CTX697096:

• NetScaler ADC and Gateway 14.1: 14.1-73.37 or later
• NetScaler ADC and Gateway 13.1: 13.1-64.23 or later
• NetScaler ADC 14.1-FIPS: 14.1-73.37 FIPS or later
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP: 13.1-37.279 or later

Anything on 12.1 or 13.0 is past end of life and receives nothing. If that describes a box on your perimeter, the remediation is a migration, and the interim control is taking it off the internet.

Capture the evidence, then upgrade

CISA ordered the sequence explicitly in its September 27 alert: check for indication of compromise prior to patching, and preserve forensic data first, because applying the update "may result in loss of forensic visibility." On an appliance you cannot freely shell into, that collection has a short list of places to look and a shorter window to look in.

Off the appliance, before the maintenance window

# 1. Full technical support bundle. Writes a tarball under /var/tmp/support/.
#    Do this from the CLI, then copy the archive off the box.
show techsupport

# 2. Everything that would be rotated or reinitialized by an upgrade.
shell
ls -la /var/core/                 # crash cores: a memory-overflow bug leaves these
tar czf /var/tmp/ns-evidence-$(date +%Y%m%d).tgz \
    /var/log/ns.log* /var/log/httpaccess.log* /var/log/httperror.log* \
    /var/log/auth.log* /var/nslog/ /var/core/ \
    /flash/nsconfig/ns.conf /flash/nsconfig/ssl/

# 3. Pull both archives to a host that is not the appliance.
exit
scp nsroot@<nsip>:/var/tmp/support/collector_*.tar.gz  ./
scp nsroot@<nsip>:/var/tmp/ns-evidence-*.tgz           ./

If the appliance is a virtual machine, take a hypervisor snapshot that includes memory before you touch the guest. A memory-overflow bug under active exploitation is exactly the case where RAM holds the answer and a graceful reboot discards it:

# VMware: 4th argument = 1 includes memory, 5th = 0 skips quiesce.
vim-cmd vmsvc/getallvms | grep -iE "netscaler|adc|gateway"
vim-cmd vmsvc/snapshot.create <vmid> "pre-CTX697096-2026-09-28" \
        "evidence before 14.1-73.37 upgrade" 1 0

Then run the compromise check. Citrix exposes generic indicators through the NetScaler Console Security Advisory workflow, which needs telemetry enabled and Console 14.1-73.36 or later, through the Console service or on-premises Console with Cloud Connect. Customers without that path go to Citrix Support for the indicators.

What the indicator scan can and cannot tell you

Citrix is unusually direct about the limits of its own tooling. The indicators "might be of limited forensic value and might fail to identify actual compromises," and the vendor recommends engaging experienced forensic investigators where activity is suspected. CERT-EU went further and advised European organizations to run a compromise assessment on any internet-facing appliance that was running an affected build, whatever the scan says.

Take that seriously in the order you plan your week. A clean scan result and a fixed build tell you the appliance is no longer exploitable by these two bugs. Neither tells you the box was never exploited during the window when no patch existed. Every hour an affected build was reachable from the internet is an hour in which CVE-2026-88771 needed nothing but a route to your edge.

The evidence that survives is the evidence that never lived on the appliance. Your firewall, flow collector, reverse proxy, and DNS resolver all hold a record of what the NetScaler did, and none of it is erased by an upgrade:

# Outbound connections initiated BY the appliance. A load balancer that starts
# calling the internet on its own behalf is the signal worth chasing.
nfdump -R /var/cache/nfdump -t 2026-08-15/2026-09-28 \
       "src ip 10.20.4.10 and not dst net 10.0.0.0/8 and not dst port 53" \
       -s dstip/bytes -n 40

# Same question from Zeek, including short-lived beacon-shaped sessions.
zeek-cut id.orig_h id.resp_h id.resp_p duration orig_bytes \
    < conn.log | awk '$1=="10.20.4.10" && $3!=443 && $3!=53'

# And from the resolver: names the appliance looked up that you did not configure.
grep "10.20.4.10" /var/log/named/query.log \
  | awk '{print $6}' | sort | uniq -c | sort -rn | head -30

Set the baseline first. A NetScaler in steady state talks to a small, boring set of destinations: your authentication servers, your backend pools, an NTP source, Citrix licensing and telemetry endpoints. Anything outside that list, especially on a non-standard port or to a host registered in the last few months, is worth an hour of somebody's time.

Two configuration changes the upgrade does not finish for you

The fixed builds change SAML behavior. They stop accepting unsigned SAML assertions, and any configuration with samlRejectUnsignedAssertion set to OFF is converted to the secure default during the upgrade. That is the correct behavior, and it will break authentication for any identity provider that has been sending unsigned assertions. Confirm your IdP signs assertions before the maintenance window rather than discovering it from a help desk queue on Monday morning.

CVE-2026-88778, the TCP sequence number prediction flaw, is the one bug in the bulletin that the update alone does not close. It also needs the Enhanced ISN Generation setting applied per the NetScaler TCP configuration documentation. If you close the ticket when the build number changes, that one stays open.

I would add a third item that Citrix does not ask for. On any appliance that was internet-facing on a vulnerable build, rotate what the box could hand over: the local administrative credentials, any bind account the appliance uses to reach LDAP or RADIUS, the session keys, and the certificates and private keys stored in /flash/nsconfig/ssl/ if you cannot rule out unauthenticated code execution during the exposure window. Rotation is cheap this week. It is expensive after the assessment finds something.

Build the list of exposed NetScalers before Wednesday

The KEV due date is September 30. Work backward from it. Today, produce the list of every NetScaler ADC and Gateway your organization exposes, with its exact build string and its DTLS state next to it, and include the appliances a client or a business unit owns rather than only the ones your team administers. Tomorrow, capture evidence and run the indicator check on every one that was on an affected build. Then upgrade, apply the ISN setting, verify the SAML signing assumption, and rotate the secrets the appliance held.

If that list turns up a box that was exposed on an affected build and you have no telemetry to say what happened to it, treat the gap as the finding. That is the point where a compromise assessment stops being optional and becomes the only way to answer the question your leadership will ask.