On Sunday 27 September, Citrix published fixes for eight vulnerabilities in NetScaler ADC and NetScaler Gateway, the appliances that front remote access for a great many British organisations. Two of them, CVE-2026-88771 and CVE-2026-88772, were already being used against customers before any fix existed. CISA added both to its Known Exploited Vulnerabilities catalogue the same day and gave US federal agencies until Wednesday 30 September to deal with them.

On Monday 28 September the NCSC published its own guidance: seven actions, in order. “Install the latest available updates” is number five. That ordering is the most useful thing anyone has said about these vulnerabilities, and most of this piece is about why.

What happened, and when

According to the security researcher Kevin Beaumont, as reported by Help Net Security, the attacks have been going on for the whole of September. The public story began much later, and it moved fast.

On Friday 25 September a post on Reddit’s r/Citrix forum reported the problem, and one administrator described their IT supplier’s security team phoning to tell them to shut their NetScalers down immediately, without saying why. On Saturday, watchTowr, which said the flaws had been found during forensic investigations, warned publicly that unpatched NetScaler zero-days were being exploited: “While details are scarce, the information is credible.” The Dutch NCSC had reportedly already warned organisations before any public disclosure.

On Sunday Citrix published bulletin CTX697096, with fixed builds for all eight flaws and one sentence on the part that matters: “Exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated NetScaler deployments have been observed.” CISA’s catalogue entry and the Dutch NCSC’s alert followed that day. On Monday the UK NCSC published its guidance, and watchTowr published a full technical analysis of CVE-2026-88771.

Citrix has not said how widely the flaws have been exploited, by whom, or since when, and nobody has attributed the activity publicly. Beaumont’s own read is “probably nation state aligned as well resourced, espionage rather than teens”. If he is right, that shapes the response, because quiet, well-resourced intruders are the ones most likely to have tidied up after themselves.

The UK NCSC says it is still working to understand the impact on UK organisations. The Shadowserver Foundation counts more than 20,000 NetScaler instances visible from the internet, though not every one of them will be vulnerable.

The two that are being exploited

CVE-2026-88771 is the more serious of the pair. Citrix describes it as improper input validation that lets an unauthenticated attacker execute arbitrary commands, scores it 9.5 under CVSS 4.0, and says it affects every deployment, including the default configuration. The Dutch NCSC’s summary is blunt: it gives an attacker full control of the gateway and direct access to the internal network behind it.

CVE-2026-88772 is a memory overflow that can lead to remote code execution or a denial of service. It needs DTLS to be enabled, which is the default on the VPN virtual servers that make a NetScaler a Gateway, so the precondition narrows the field less than it sounds. Citrix scores it 9.5 as well, rates its attack complexity as high, and the Dutch NCSC notes that it can crash the appliance and take VPN, gateway and load-balancing services down with it.

The other six are not known to be exploited. CVE-2026-88773 is an HTTP request smuggling flaw scored 9.3, and CVE-2026-88774 lets requests slip past policies built on HTTP URL expressions. CVE-2026-88775, 88776 and 88777 are memory overflows that can crash the appliance when it runs a Gateway or AAA virtual server, an Oracle load-balancing virtual server, or non-HTTP layer-7 protocols on load-balancing, content-switching or CGNAT services.

CVE-2026-88778 lets an attacker predict TCP initial sequence numbers. The upgrade is Citrix’s answer to all eight, but for this one it also asks affected deployments to apply a TCP configuration change, enabling a setting called Enhanced ISN Generation; show ns tcpparam | grep "Enhanced ISN Generation" shows whether it is off.

Two scoping details also matter. Secure Private Access hybrid deployments that use NetScaler instances are affected too, and Cloud Software Group is upgrading the Citrix-managed cloud services and Citrix-managed Adaptive Authentication itself.

How a log line becomes a root shell

watchTowr’s write-up of CVE-2026-88771 is worth reading in full if you run these boxes, because the bug is one of the oldest mistakes in the book, sitting in one of the least glamorous corners of the appliance.

NetScaler’s packet engine processes occasionally crash, and a monitoring component called pitboss records the fact in the logs. A housekeeping script, /netscaler/ns_monuploadd_err.pl, later reads those messages back to find the matching core dump. It pulls the core file name and process ID out of the log line with a grep, sed and awk pipeline, and drops the result, unchecked, into a shell command that runs find.

The script never checks that what it extracted really is a core file name and a number. Meanwhile the appliance logs plenty of text that an unauthenticated stranger controls: failed login attempts, users blocked by rate limits, request parameters and User-Agent headers. An attacker who gets a line into the log that looks like a pitboss crash message, with a shell command where the file name should be, has written the next command the script will run.

That command runs as root, because, in watchTowr’s words, “pretty much everything on a Citrix NetScaler runs as root”. Their demonstration went through the Gateway’s login handler, but they note that any endpoint or port that logs attacker-controlled header data can carry the payload.

One feature of this bug matters for anyone investigating. The command does not run when the request arrives; it runs when the script next does, which watchTowr says can take up to 24 hours. They hint that they may have found a way to make it fire at once, and they have not published it.

In your logs, then, the request that planted the command and the command itself can sit hours apart. Because the script takes the file name and process ID as whitespace-separated fields, the injected command also has to do without spaces. That fits the indicators Beaumont has suggested searching for: base64 straight after the User-Agent field with no space, and log lines where pitboss is followed by IFS, as in the shell variable ${IFS} that stands in for a space, or by b64decode.

Citrix’s fix replaces the shell pipeline with a strict pattern that accepts only an NSPPE name and a numeric process ID, and calls find without a shell. The lesson generalises well beyond NetScaler. A log is not trusted input; it is a record of untrusted input, and anything that reads it back has to treat it that way.

Who is affected

The affected builds are NetScaler ADC and Gateway 14.1 before 14.1-73.37, 13.1 before 13.1-64.23, 14.1-FIPS before 14.1-73.37 FIPS, and 13.1-FIPS and 13.1-NDcPP before 13.1-37.279. Those are also the fixed builds, so anything at or above them is patched. show ns version at the command line tells you where each appliance stands.

There is a trap here for the diligent. In August Citrix fixed CVE-2026-19490, an authentication bypass that CISA added to its exploited catalogue on 9 September, in builds 14.1-73.32 and 13.1-63.21. If you upgraded to those builds in August you did the right thing, and you are still inside the affected range for September’s flaws.

Versions 12.1 and 13.0 are end of life and receive no security updates, and Citrix has not said whether they are affected. Treat them as vulnerable. No fix is coming, so the only remediation is a supported build or the off switch.

Patching is step five

The NCSC’s list runs in this order. First, read Citrix’s bulletin and the blog that accompanies it, which carries the indicators of compromise. Second, if possible, isolate the affected systems and replace them with new, fully up-to-date ones, noting that this may cause an outage.

Third, investigate fully for evidence of compromise, and fourth, report it if you find some. Only then, fifth, install the updates, before re-introducing the systems and carrying on with monitoring and threat hunting. There are three good reasons for putting the patch that far down.

The first is that the attacks started before the patch existed. An appliance that faced the internet during September may already have been visited, and an upgrade replaces the firmware without undoing whatever an intruder took or left behind. Sophos puts it plainly: “Simply applying the security updates may not remove attacker access from an appliance that was compromised prior to remediation.”

The second is that the upgrade destroys evidence. The Dutch NCSC asks organisations to secure memory dumps and log files covering at least the month before they update. A reboot clears memory and logs rotate, and Beaumont warns that on many appliances the relevant logs have probably rotated already, which makes whatever survives worth keeping.

The third is that we have seen this before. In 2025 the Dutch NCSC investigated CVE-2025-6543 and found it had been used against several critical Dutch organisations since at least early May, around two months before Citrix disclosed it on 25 June. The attackers left webshells and removed their traces, and the NCSC’s conclusion, in translation, was that patching a vulnerability does not mean the problem is solved.

What to do this week

Start with an inventory, because you cannot check a box you have forgotten. Include the disaster-recovery pair, the test appliance, any Secure Private Access hybrid deployment, and the NetScaler a supplier runs on your behalf. For each one, record the build and whether it can be reached from the internet, and treat anything in range and exposed as potentially compromised until someone has looked.

Before you change anything, capture evidence. watchTowr’s checklist is a sensible one: logs, a snapshot, a support bundle and a core dump from each exposed appliance. Copy the logs off the box, rotated archives included, as far back as they go.

If you cannot patch today, isolate the appliance from the internet rather than powering it off. Pulling the plug throws away exactly the memory the Dutch NCSC has asked you to keep. With patches now out, isolation is a holding measure while you capture and look, not a place to stay.

Then look. Citrix’s indicators of compromise come through NetScaler Console, which needs version 14.1-73.36 or later with telemetry enabled, or from Citrix Support on request. Citrix itself says they do not cover every technique, so a clean scan is not proof of a clean box.

Search the logs for Beaumont’s patterns as well, on the appliance and in your SIEM. On the appliance’s shell, a first pass over the current and rotated system logs looks like this:

zgrep -Ei 'pitboss.*(ifs|b64decode)' /var/log/*.log /var/log/*.gz /var/log/messages*

Run the equivalent search in your SIEM across everything the appliance has forwarded, and add a search for base64 immediately after the User-Agent field. Then look for what an intruder leaves: new or changed files in the web directories, scheduled jobs, processes and accounts you do not recognise. The NCSC points to NetScaler Console’s File Integrity Monitoring, which is built to flag unexpected changes to monitored files, and Beaumont’s advice is simply that you will need to check every box for webshells after patching.

If you find something, or you cannot rule it out, Citrix’s recovery steps, as reported by The Hacker News, are the right skeleton. Preserve the evidence and isolate the device. Revoke credentials and access, investigate every system the appliance connected to, rebuild it on the latest firmware, rotate local passwords and the key encryption key, replace SSL certificates if you restore from a known good backup, and harden the result.

I would widen the credential circle further. A gateway sees every password typed into it, and it typically holds the LDAP bind account, the RADIUS secrets and the private keys for every service it publishes. If the box might have been owned, all of those might have been read, and all of them need changing.

In the UK, report a suspected compromise through the NCSC’s reporting service. The NCSC does not pass reports to the ICO, so if personal data may be involved, that is a separate report.

Only then patch, or better, follow the NCSC’s second step and replace the appliance with a clean, current build. Bring it back into service, send its logs off the box to somewhere an intruder cannot edit, and keep File Integrity Monitoring switched on. If you are a UK organisation and not yet signed up to the NCSC’s free Early Warning service, this is a good week to do it.

The fourth time this year

None of this is a surprise, and that is the point a board should take from it. This is the fourth time in 2026 that NetScaler has needed an emergency upgrade because of flaws attackers were using.

In March it was CVE-2026-3055, a memory overread in the SAML identity-provider code, which CISA added to its catalogue a week after disclosure. On 30 June it was CVE-2026-8451, another SAML memory overread, and CrowdSec saw exploitation attempts within a couple of days; I covered it in that week’s round-up.

The same June builds fixed CVE-2026-8452, which Citrix had described as a denial of service until watchTowr showed it gave unauthenticated code execution; CISA added it to its catalogue on 26 August. In August it was also CVE-2026-19490, and I put NetScaler first on the list of things to patch in the August threat landscape.

On the 14.1 branch, that is four emergency builds in six months: 14.1-66.59, 14.1-72.61, 14.1-73.32 and now 14.1-73.37. And this time the attackers were in before any fix existed. I made the general point in July, when it was FortiSandbox: the equipment sold to defend the perimeter has become the softest part of it.

So the questions for a board are practical ones. Do we know every NetScaler we own or depend on, including the ones our suppliers run for us? What is our measured time from a Citrix advisory to a patched appliance in production, given that this year it needed to be days, four times over?

When did someone last check an edge appliance for signs of compromise, rather than for its version number? Do its logs leave the box, and how far back can we see? And could we switch remote access off for a day, or fail over to something else, without stopping the business?

The supplier who phoned that r/Citrix administrator to tell them to shut down was assuming the answer was yes. None of those questions needs new technology to answer, and the organisations that can already answer them will find this week dull, which is the best thing an incident week can be.

The point

The patch is the easy part, and it is fifth on the list for a reason. The valuable work is in steps two to four: keep the evidence, look properly, and rebuild if there is any doubt.

A NetScaler is a computer on the internet that holds your keys and sees your passwords, and it deserves the scrutiny you would give any other machine in that position. Patch it this week, by all means. Just do not mistake patched for clean.