Checking a NetScaler for compromise
What to look for on a NetScaler ADC or Gateway after the September 2026 exploitation of CVE-2026-88772, and three ways to look: a free check in your browser, the Integrity check over SSH, and support bundle forensics.
.sig file in the gateway’s plug-in folders (the advisory names nsgclient.sig); lines in httpd.conf that hand .sig or .deb files to PHP or map a public icon address onto a plug-in file; /bin/sh with the setuid bit; /tmp/.uxdport or .uxdlock (the tunneler); a static file answered “404” at many different sizes (a program answering, not a missing file); and a failed DTLS 1.0 handshake just before a packet engine crash. Any one of these needs a closer look. Two or more of the advisory’s own signs together are that campaign’s pattern: keep the evidence, then rebuild the appliance from a clean image rather than cleaning it in place.The signs, and where each one shows
| Sign | Where it is | What it usually means |
|---|---|---|
A .sig, a script or a package among the plug-in images | /var/netscaler/gui/vpn/scripts/ and the other plug-in folders | a web shell served from the gateway’s own folders |
PHP given to a non-PHP extension, or an AliasMatch onto a plug-in file | /etc/httpd.conf, /nsconfig/httpd.conf, /flash/nsconfig/httpd.conf | the web shell being wired in; the stock files do neither |
A guard the firmware ships on, commented out (# Require all denied) | the same three files | protection switched off by hand |
/bin/sh setuid; new setuid files | /bin, /var, /flash, /tmp | a way back to root kept for later |
/tmp/.uxdport, .uxdlock; a Python process reading them | /tmp and the process list | the tunneler the advisory describes |
| A static path answered 404 at several body sizes, some slow | the web access logs | a program answering requests behind a fake “not found” |
| A failed DTLS 1.0 handshake, then a packet engine crash | ns.log | the exploit attempt itself |
| The web server account running a shell or a network tool | the process list | commands run through the web server |
| Crash dumps deleted | shell history, /var/core | covering tracks (also how a full disk is freed, so ask first) |
A firmware build below the fixed builds is exposure, not a sign of compromise, and is reported apart.
Three ways to check
- The free NetScaler Compromise Check in the Vantage Toolkit. Give it a support bundle, or paste the output of a short read-only command block. It runs in your browser: the page is not allowed to send anything, so the bundle stays on your disk. Access is by request.
- The Integrity check in DTR Vantage (Utilities). Reads every node of the pairs you choose over SSH with read-only commands, compares the two nodes of a pair, and keeps each run. It can also run as a scheduled report.
- Support bundle analysis, or the same analysis read live on a schedule with no bundle. Adds the logs: the fake 404s, the advisory’s addresses, DTLS before a crash, what was typed at the shell and from where, and a verdict on crash, compromise and resources.
What a clean result means
It means none of these signs was found in what was read. It does not prove nothing happened: logs rotate, a bundle may not reach back far enough (the analysis names the hours it is missing), and an intruder can tidy up. Run Citrix’s own IOC scanner as well; it checks file hashes and addresses that these checks do not, and these checks find things it misses, such as a setuid /bin/sh.
Questions
Does upgrading the NetScaler remove a web shell?
Not reliably. The root filesystem is rebuilt at boot, but /var, /flash and /nsconfig are kept, and that is where the advisory's web shell and httpd.conf changes live. Check after upgrading.
Do I need a support bundle?
No. The Integrity check reads the appliance live over SSH. A bundle adds the logs; DTR Vantage can also read those live on a schedule.
Does the free check upload my bundle?
No. It runs in your browser under a policy that blocks every network request from the page, and nothing is kept once you clear it.
What should I do if it finds something?
Keep the evidence first (the bundle, the files, the logs), then rebuild the appliance from a clean image, rotate every credential it held, and follow Citrix's guidance.
Checked against build b614, 2026-10-18. Where a statement is product knowledge rather than a tested capture, it says so.