On September 27, 2026, Citrix published bulletin CTX697096 with eight NetScaler ADC and Gateway vulnerabilities. Two of them, CVE-2026-88771 and CVE-2026-88772, were already being exploited before fixed builds existed. Both give remote code execution to an unauthenticated attacker. CISA added both to the KEV catalog the same day and gave federal agencies until September 30 to remediate.
Here’s the short version of the two:
The difference matters. 88772 has a configuration precondition, even if most Gateways meet it. 88771 doesn’t. All vulnerable customer-managed NetScaler ADC and Gateway deployments meet the vendor-listed precondition for CVE-2026-88771. Internet-facing appliances should therefore be treated as exposed to remote exploitation until patched.
Figure 1. Two independent pre-auth paths to code execution
88771 has the broader exposure scope of the two because the advisory doesn’t list any feature or configuration requirement. An ADC doing plain load balancing is in scope just like a Gateway.
The advisory tells us the issue is improper input validation and that successful exploitation allows arbitrary command execution. It doesn’t say which component processes the input or how that input reaches command execution. No public source establishes the affected endpoint, parameter or code path, and there’s no public PoC or root-cause analysis. We also don’t know whether exploitation needs access to the management interface (NSIP) or just a public-facing vserver. Until that’s clear, defenders should assume both.
One detail in the vector is worth noting: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/…. AT:P means Citrix scored it as having attack requirements, some condition outside the attacker’s control that must be present. The advisory doesn’t explain what that condition is, and it doesn’t change the “default configuration” scope, but it’s one more thing we’ll understand only once more details come out.
If you see a write-up naming a specific endpoint or showing “the vulnerable function” without a source, treat it as a guess. For now, the vendor description and “exploited in the wild” are all we actually have.
88772 is classified as CWE-119, a memory buffer bounds issue. Citrix doesn’t name the vulnerable component, but the precondition is DTLS being enabled. On a VPN vserver, the -dtls option starts the UDP (TURN) service used for UDP-based traffic such as EDT for HDX sessions. It runs on the same IP and port as the vserver, over UDP instead of TCP. Its vector is AV:N/AC:H/AT:N/PR:N/UI:N, so Citrix rates the attack complexity as high but lists no attack requirements beyond DTLS being on.
The overflow can lead to RCE or a denial of service. A failed or unreliable memory-corruption attempt may crash the packet engine and leave a core dump, which gives defenders something to look for. More on that in the hunting section.
What’s not public: the vulnerable routine, whether it’s a heap or stack overflow, which handshake or record stage triggers it, and how reliable exploitation is.
Start with the build:
> show ns version
Anything below 14.1-73.37 or 13.1-64.23 is vulnerable to both CVEs (FIPS builds are in the remediation table below). For 88771 that’s the whole check, since it has no other precondition.
For 88772 you need to know which VPN vservers have DTLS on. It’s a per-vserver setting, and its default is ON:
> show vpn vserver
> show vpn vserver <vserver_name>
Go through each VPN vserver’s details and check its DTLS setting. If you’ve never touched it, it’s on.
You might be tempted to turn DTLS off (set vpn vserver <name> -dtls OFF) as a stopgap. It isn’t an official workaround, it does nothing for 88771, and it breaks whatever depends on UDP transport, such as EDT. Its main use is knowing your 88772 exposure.
Figure 2. Exposure check from the NetScaler CLI
Figure 2. Exposure check from the NetScaler CLI
There are no public exploit-level indicators for either CVE yet, so nothing below detects exploitation directly. These checks are based on common post-compromise artifacts on NetScaler: webshells in web-served directories, unexpected setuid binaries, files changed during the exposure window, and crash artifacts. Run them from the shell (shell from the CLI):
# 1. PHP files outside the stock admin UI paths.
# Webshells on NetScaler have typically been PHP.
find / -type f -name “*.php*” \
-not -path “/var/netscaler/gui/admin_ui/*” \
-not -path “/netscaler/websocketd/*” \
-not -path “/netscaler/ns_gui/admin_ui/*”
# 2. Common webshell strings in web-served directories
fgrep -a -e http_response_code -e ‘$_POST’ -r /var/netscaler/ \
| fgrep -v -e ‘/var/netscaler/gui/admin_ui’ \
-e ‘/netscaler/websocketd’ -e ‘/netscaler/ns_gui/admin_ui’
fgrep -a -e http_response_code -e ‘$_POST’ -r /var/vpn/
fgrep -a -e http_response_code -e ‘$_POST’ -r /netscaler/
# 3. setuid binaries owned by root. Compare against a known-good
# appliance on the same build; a setuid /bin/sh is a red flag.
find / -perm -4000 -user root -exec ls -lc {} \;
# 4. Files changed inside your exposure window
# (adjust dates to when you went from vulnerable to patched)
find / -type f -newerct ’09/01/2026 00:00 GMT’ \
-not -newerct ’09/28/2026 00:00 GMT’ -exec ls -lc {} \;
# 5. Packet engine cores and process crashes
ls -laR /var/core/ /var/crash/
Check 4 will be noisy, because logs and config saves change constantly. Filter out /var/log and /var/nslog first and look at what’s left.
For check 5: an NSPPE core in /var/core/ from September on a Gateway with DTLS on is worth investigating. It could have many causes, but it’s the one place a failed 88772 attempt could leave something behind.
Also look for system accounts you didn’t create:
> show system user
Compare the output against a config backup from before September.
If you use NetScaler Console, Citrix has made IoCs available through the Security Advisory page (Console 14.1-73.36 or later, telemetry enabled). You can also request them from Citrix Support. Console’s File Integrity Monitoring can flag modified or newly added files. Citrix notes that its IoCs don’t cover every technique, so a clean result doesn’t close the question.
If anything looks off, preserve evidence before rebooting or upgrading. Take a forensic copy of both disk and memory. Keep remote syslog and NetScaler Console logs as well as the local ones, and record the system time, timezone and NTP settings. An upgrade overwrites much of what you’d want to look at. It also doesn’t remove a webshell that’s already on the box: patched appliances have been found still carrying backdoors in past NetScaler incidents.
Figure 3. Response order when compromise is suspected
This is the second serious pre-auth NetScaler issue in about six weeks. On August 19, Citrix published CTX696939 for CVE-2026-19490, an authentication bypass using an alternate path (CWE-288, CVSS v4 9.3) in SAML handling. It gave an attacker a valid NetScaler session without a corresponding IdP login. A public PoC followed, and CISA added it to KEV on September 9. On builds 14.1-43.56 / 13.1-61.28 and later, only vservers with a SAML action were affected. On earlier builds, any Gateway or AAA vserver was. The same bulletin covered CVE-2026-19489, a memory overflow in SIP ALG on Large Scale NAT that leads to unpredictable behavior or denial of service.
Figure 4. Disclosure and KEV dates, 2026
Public analyses of the CVE-2026-19490 root cause don’t agree. One points to the HTTP-Redirect binding skipping signature validation, another to RelayState handling in the POST flow. It doesn’t matter much for this post.
What matters is that CVE-2026-19490 and the new zero-days are separate bugs. There is no public evidence that CVE-2026-19490 is needed to exploit CVE-2026-88771 or CVE-2026-88772. What they share is where they live: NetScaler processes unauthenticated traffic by design, before anything reaches Active Directory or the IdP, and that code keeps producing critical bugs.
Patching CVE-2026-19490 does not protect against CVE-2026-88771 or CVE-2026-88772. The new vulnerabilities require the current fixed builds.
Remediation
Citrix lists no workaround. Fixed builds:
Product | Fixed build |
NetScaler ADC / Gateway 14.1 | 14.1-73.37 and later |
NetScaler ADC / Gateway 13.1 | 13.1-64.23 and later |
NetScaler ADC 14.1-FIPS | 14.1-73.37 FIPS and later |
NetScaler ADC 13.1-FIPS / 13.1-NDcPP | 13.1-37.279 and later |
12.1 and 13.0 are end of life and won’t get a fix.
Don’t confuse these with the CVE-2026-19490 fixes (14.1-73.32 and 13.1-63.21). If you’re on 14.1-73.32, you’re still vulnerable to both new CVEs.
If compromise is suspected, invalidate existing sessions after you’ve collected the evidence you need. Depending on the services in use, that means AAA, ICA, RDP, PCoIP and load-balancing persistence sessions. These are the commands Citrix has documented for this:
> kill aaa session -all
> kill icaconnection -all
> kill rdp connection -all
> kill pcoipConnection -all
> clear lb persistentSessions
A compromised NetScaler also exposes everything the appliance holds: LDAP bind accounts, RADIUS secrets, certificates and private keys. If you have reason to suspect compromise, rotate those service account passwords and revoke and reissue the certificates.
The other six CVEs
CTX697096 also includes CVE-2026-88773 through CVE-2026-88778, rated CVSS 7.0 to 9.3. They cover HTTP request smuggling, policy bypass and further memory overflows in various configurations. None are reported as exploited. The same release addresses the vulnerabilities, although CVE-2026-88778 also requires Enhanced ISN Generation to be enabled. Which of these CVEs matter for a given environment depends on which NetScaler appliances are reachable from the internet and how they are configured. ThreatMon’s attack surface monitoring shows those exposed appliances, including gateways and virtual servers missing from the official inventory, and matching them against the affected builds and CTI on exploitation status shows where to patch first. The same visibility helps with the exposure window, since the time an appliance stayed reachable and unpatched can be estimated from when it first appeared on the attack surface.
Bottom line
Upgrade to 14.1-73.37 or 13.1-64.23, check DTLS exposure, and run the hunting checks and the Citrix IoC scan. Treat an internet-facing NetScaler that sat unpatched through late September as potentially compromised until you’ve shown otherwise. Patching and hunting alone don’t close a zero-day case. Exploitation starts before a fix is available, so the period between first exploitation and patch deployment needs to be reviewed too. ThreatMon helps here by showing which NetScaler assets are exposed to the internet and linking them to CTI on active exploitation and new IoCs, which makes it possible to scope that window from evidence.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
