Hunt NetScaler CVE-2026-88771 and 88772: authority before sign-in

Open the running configuration on your NetScaler Gateway and find the line that begins with add vpn vserver. If it does not carry -dtls OFF, DTLS is on, because that is the default. Then read the build. Anything below 14.1-73.37, or below 13.1-64.23 on the 13.1 branch, falls inside the range of two flaws that Citrix says attackers have already used. Those two checks are the first hour of this case.

Citrix bulletin CTX697096, published Sunday, 27 September 2026, lists eight CVEs. Two of them come first, and Citrix is unusually direct about why: "Exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated NetScaler deployments have been observed." Both carry a CVSS v4.0 score of 9.5. CISA added the pair to the Known Exploited Vulnerabilities catalog the same day, with a 30 September due date under BOD 26-04, which gave federal civilian agencies three days. The bulletin names no indicators, no attacker, and no victim count, and neither does this post.

If you run NetScaler ADC or Gateway, you have four questions to answer this week. Which appliances, lab and disaster recovery included, are running below the fixed builds? Which virtual servers accept DTLS? What did each appliance do, and who signed in through it, before you upgraded? And what evidence would mak

How the attack works

Command authority with no identity attached

A gateway is supposed to settle two questions, in order: who is this, and what may this identity do? CVE-2026-88771 skips the first one entirely. Citrix describes improper input validation (CWE-20) that "can allow an unauthenticated attacker to execute arbitrary commands," and it affects "All NetScaler ADC and NetScaler Gateway deployments (Default configuration / No additional feature required)." Read that scoping line twice, because it is the whole problem. The appliance hands its highest authority, command execution on itself, to a requester who has proven nothing at all. There is no feature to turn off and no listed workaround. The upgrade is the fix.

A gateway is supposed to settle two questions, in order: who is this, and what may this identity do? CVE-2026-88771 skips the first one entirely. Citrix describes improper input validation (CWE-20) that "can allow an unauthenticated attacker to execute arbitrary commands," affecting "All NetScaler ADC and NetScaler Gateway deployments (Default configuration / No additional feature required)." Read that scoping line twice, because it is the whole problem. The appliance hands its highest authority, command execution on itself, to a requester who has proven nothing at all, and there is no feature to turn off and no listed workaround. The upgrade is the fix.

A DTLS listener reachable without credentials

CVE-2026-88772 is a memory overflow (CWE-119) "leading to Remote Code Execution or Denial of Service," and DTLS is "Enabled by default on VPN vServer." DTLS is TLS over UDP, so the exposed surface includes UDP 443 on the gateway, not just the login page your team actually watches, and the CVSS vector lists no privileges required. The denial of service outcome is worth sitting with for a second. If a gateway dropped unexpectedly in the last few weeks and nobody ever established why, that ticket deserves a second look. Outages do have ordinary causes, so this is a reason to check, not a reason to conclude.

CVE-2026-88772 is a memory overflow (CWE-119) "leading to Remote Code Execution or Denial of Service," and DTLS is "Enabled by default on VPN vServer." Since DTLS is TLS over UDP, the exposed surface includes UDP 443 on the gateway rather than just the login page your team actually watches, and the CVSS vector lists no privileges required. The denial of service outcome is worth sitting with for a second. If a gateway dropped unexpectedly in the last few weeks and nobody ever established why, that ticket deserves a second look, though outages do have ordinary causes and this is a reason to check rather than to conclude.

Why your last emergency upgrade may not count

This is the part that catches careful teams. If the emergency upgrade you did for CVE-2026-8452 landed you on 14.1-73.32 or 13.1-63.21, those builds sit below the new floors, so the work you already did does not cover this. Having patched recently is not the same as being patched now.

Risk: what the gateway holds

A NetScaler Gateway is where remote identity enters the network, so command execution on one is not a single-host problem. Citrix's own compromise guidance, CTX694799, spells out what an attacker in that position can reach.

Start with what lives on the box: LDAP service accounts, RADIUS shared secrets, OAuth tokens, API keys, SNMP community names.

Then the people who passed through it: every account that authenticated through the gateway or an AAA virtual server needs a password change.

Then the certificates and private keys, because the TLS identity of your public services may live on the appliance.

And then everything the ADC could reach from there: authentication servers, web tier systems, management jump hosts.

None of that is proof your organization lost all of it. It is the list of things to investigate, in an order that starts with ownership: who administers the appliances, which directories they bind to, and what sits behind them.

Mitigate and reduce risk

Install the fixed builds

Citrix lists these as the remediated releases:

• NetScaler ADC and Gateway 14.1-73.37 and later

• NetScaler ADC and Gateway 13.1-64.23 and later releases of 13.1

• NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS and later

• NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.279 and later

One detail is easy to miss. The 13.1 branch reached End of Maintenance on 15 September 2026, less than two weeks before this bulletin, and Citrix shipped a fix for it anyway. If someone on your team has already concluded that 13.1 is unsupported and therefore stuck, that is wrong, and it is the kind of wrong that leaves a gateway on the internet for another month.

Read the DTLS condition exactly as Citrix wrote it

Citrix states that "a NetScaler Gateway is vulnerable if DTLS is not explicitly disabled, and other virtual servers are vulnerable if they are configured with type DTLS." So a VPN virtual server carrying -dtls OFF genuinely does not meet the precondition for CVE-2026-88772, and that is worth confirming rather than assuming. Just do not let it become false comfort. Disabling DTLS does nothing at all for CVE-2026-88771, which needs no feature enabled and has no workaround.

Keep management off the internet

CTX694799 is blunt: NetScaler management services should never be exposed to the public internet.

Preserve before you rebuild

If you suspect compromise, CTX694799 puts evidence first. Record time and NTP settings, snapshot VPX instances, keep remote syslog and NetScaler Console logs, generate a support bundle, and capture a packet engine core. Then isolate, rotate stored secrets and user passwords, revoke certificates and keys, and rebuild from a backup that predates the compromise. After restoring, change local passwords, rotate key encryption keys, and monitor for at least 90 days. CISA's KEV entry adds that running the IOCs Citrix provides in NetScaler Console may help.

An upgrade closes the flaw. It tells you nothing about what happened before you applied it, and on an appliance that brokers every remote login, that gap is the part worth staffing.

How to hunt the activity

Citrix published preconditions rather than indicators, so the four hunts below follow the preconditions and the compromise guidance: sessions through the appliance, connections it started, administrative commands, and DTLS configuration. Use your full retention window, because the bulletin gives no start date.

Hunt in KQL: identities that crossed the gateway

let NetScalers = dynamic(["ns-gw-01", "ns-gw-02"]);   // your appliance hostnames
let Lookback = 30d;
union isfuzzy=true
  (Syslog
   | where TimeGenerated > ago(Lookback)
   | where Computer in~ (NetScalers)
   | project TimeGenerated, Appliance = Computer, Msg = SyslogMessage),
  (CommonSecurityLog
   | where TimeGenerated > ago(Lookback)
   | where DeviceVendor has "Citrix" or DeviceProduct has "NetScaler"
   | project TimeGenerated, Appliance = DeviceName, Msg = Message)
| where Msg has_any ("SSLVPN LOGIN", "AAA LOGIN", "LOGIN_FAILED", "TCPCONNSTAT", "UDPFLOWSTAT")
| extend User = extract(@"User\s+(\S+)", 1, Msg),
         ClientIP = extract(@"Client_ip\s+(\d{1,3}(?:\.\d{1,3}){3})", 1, Msg)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Events = count(), ClientIPs = make_set(ClientIP, 50)
            by Appliance, User
| order by FirstSeen asc

Field mapping: ns.log session events land in Syslog or CommonSecurityLog depending on your connector, so confirm one known login parses before you trust the output.

False positives: every legitimate remote worker shows up, which is the point. This is the rotation list CTX694799 asks for.

Empty results: no rows means session events are not reaching Sentinel, not that nobody signed in.

Hunt in Falcon CQL: connections the appliance started

// Firewall or flow logs ingested into LogScale. Replace with your NSIP/SNIP addresses.
(#type=/firewall|netflow|syslog/i)
| src_ip =~ in(values=["10.0.0.10", "10.0.0.11"])
| !cidr(dst_ip, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"])
| groupBy([src_ip, dst_ip, dst_port, protocol], function=[count(as=Hits), min(@timestamp, as=First), max(@timestamp, as=Last)])
| sort(First, order=asc, limit=1000)

Field mapping: swap in your firewall parser's address and port fields. Falcon sensors do not run on the appliance, so this hunt lives or dies on network telemetry.

False positives: update checks, NTP, DNS, and cloud identity providers will appear. Allowlist them after review, not before.

Empty results: no rows means no outbound traffic reached these logs, not that none left by another path.

Hunt in Splunk: admin commands and config changes

index=netscaler (sourcetype=*netscaler* OR sourcetype=*citrix* OR sourcetype=syslog)
  ("CMD_EXECUTED" OR "UI CMD" OR "GUI CMD")
| rex "User\s+(?<ns_user>\S+)\s+-\s+Remote_ip\s+(?<remote_ip>\d{1,3}(?:\.\d{1,3}){3})"
| rex "Command\s+\"(?<ns_cmd>[^\"]+)\""
| search ns_cmd IN ("add system user*", "set system user*", "bind system user*",
                    "rm system user*", "set vpn vserver*", "add vpn vserver*",
                    "set ns ip*", "shell*", "save ns config*", "set ssl certkey*")
| table _time host ns_user remote_ip ns_cmd
| sort 0 _time

Field mapping: test the rex patterns against one real admin change in ns.log first.

False positives: planned maintenance, including this week's upgrade, will match. Compare against change records and known admin addresses.

Empty results: no rows means no audited command matched. Code run through CVE-2026-88771 does not have to pass through the command audit, so silence is not a clean verdict.

Hunt in Kibana: DTLS exposure and management reachability

(message:"add vpn vserver" and not message:"-dtls OFF")
or (message:"vpn vserver" and message:DTLS)
or (message:"lb vserver" and message:DTLS)
or (destination.ip:("10.0.0.10" or "10.0.0.11") and destination.port:(22 or 80 or 443)
    and not source.ip:("10.0.0.0/8" or "172.16.0.0/12" or "192.168.0.0/16"))

Field mapping: the configuration clauses assume /nsconfig/ns.conf or show ns runningConfig text is in Elastic, and the last clause uses ECS fields with your NSIP addresses.

False positives: a DTLS match is a precondition, not a compromise, and internet hits on management ports may just be scanners.

Empty results: no rows means nothing ingested matched. Check unshipped appliances by hand.

Interpret before you escalate

Build below 14.1-73.37 or 13.1-64.23	Exposed to both CVEs	Preserve evidence if exposure was public, then upgrade
VPN vserver without -dtls OFF, or a DTLS vserver	CVE-2026-88772 precondition met	Upgrade; review UDP 443 history on that address
Unexpected admin command or new system user	Possible post-exploitation change	Follow CTX694799: snapshot, isolate, rotate, rebuild
Outbound internet traffic from NSIP or SNIP	Possible callback after command execution	Identify the destination, capture flows, escalate if unexplained
Management reachable from the internet	Hardening gap that widens exposure	Restrict immediately and review who connected
Empty results	Unknown, not clean	Confirm log forwarding and retention before closing

Sources

• Citrix CTX697096, NetScaler ADC and Gateway Security Bulletin for CVE-2026-88771 through CVE-2026-88778: https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096 (mirror: https://support.citrix.com/external/article/CTX697096)

• Citrix CTX694799, Steps to Take if NetScaler ADC is Suspected to be Compromised: https://support.citrix.com/external/article/CTX694799/steps-to-take-if-netscaler-adc-is-suspec.html

• CVE record CVE-2026-88771: https://cveawg.mitre.org/api/cve/CVE-2026-88771

• CVE record CVE-2026-88772: https://cveawg.mitre.org/api/cve/CVE-2026-88772

• CISA Known Exploited Vulnerabilities catalog (both CVEs added 2026-09-27, due 2026-09-30): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

• CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

What this means for your team

This case opens on configuration, not on a crash. Every NetScaler ADC and Gateway below the fixed builds is exposed to CVE-2026-88771, and every VPN virtual server that never had DTLS switched off carries CVE-2026-88772 on top of it. Upgrade first, obviously. Then treat the weeks before that upgrade as an open question, because a patched appliance and a clean appliance are not the same claim.

Pull the list of users who signed in through the gateway. Look for commands and outbound connections the appliance had no business making. And be honest about which logs you never collected in the first place. That last part is where most teams stop, not because they are careless, but because ns.log was never forwarded anywhere, retention on what was forwarded is seven days, and nobody has ever read a NetScaler admin command line. If that describes your estate, the answer is not that nothing happened. The answer is that you cannot tell, and those are very different things to put in front of an executive.y below the fixed builds is exposed to CVE-2026-88771, and every VPN virtual server that never had DTLS switched off carries CVE-2026-88772 on top of it. Upgrade first, obviously. Then treat the weeks before that upgrade as an open question, because a patched appliance and a clean appliance are not the same claim.

Pull the list of users who signed in through the gateway. Look for commands and outbound connections the appliance had no business making. And be honest about which logs you never collected in the first place. That last part is where most teams stop, not because they are careless, but because ns.log was never forwarded anywhere, retention on what was forwarded is seven days, and nobody has ever read a NetScaler admin command line. If that describes your estate, the answer is not that nothing happened. The answer is that you cannot tell, and those are very different things to put in front of an executive.o

Inception Protection

Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have, including Defender and Sentinel. For an edge appliance like NetScaler, we bring the gateway's syslog and session events into the same investigation as the identities that used it, so a suspicious admin command or an odd outbound connection is read next to the sign-ins that followed. You keep patching and rebuilding, and we keep watching the accounts that crossed the box.

Inception Foresight

If you want to know how well your Microsoft 365 environment would surface activity from identities that came in through a compromised gateway, the free Inception Foresight M365 Assessment is a good place to start: https://www.inceptionsecurity.com/m365assessment. If this was useful, follow Inception Security on LinkedIn and @inceptionsec on X for the next hunt.