Citrix NetScaler again: two exploited zero-days, and why patching is only half the job

If your organisation runs a Citrix NetScaler ADC or NetScaler Gateway, this is the most urgent item on your desk today. Two vulnerabilities in those products are being exploited in the wild by attackers who need no credentials and no foothold inside your network, only the ability to reach the appliance over the internet, which is precisely what the appliance exists to allow. Both carry a CVSS score of 9.5. The United States added them to its Known Exploited Vulnerabilities catalogue on 27 September and gave federal agencies until 30 September to act; the UK's National Cyber Security Centre issued its own advisory on 28 September; and the Dutch authorities reported that exploitation had been seen at multiple Citrix customers worldwide before the flaws were public. If you take one thing from this article, take this: identify your appliances, get them to a fixed build, and then read the second half, because with these devices the update is where the work starts, not where it ends.

The two flaws being exploited

There are eight vulnerabilities in the September NetScaler bulletin, tracked as CVE-2026-88771 through CVE-2026-88778, and Citrix has published them together under bulletin CTX697096. Two of them are the emergency.

CVE-2026-88771 is an improper input validation flaw that lets an unauthenticated remote attacker execute arbitrary commands on the appliance. In plain terms, a request arriving from the internet, of the kind the device is built to accept, can be shaped so that part of it is treated as a command to run rather than as data to process. There is no login step for the attacker to pass. This is the one that reaches every affected deployment.

CVE-2026-88772 is a memory-safety flaw, an improper restriction of operations within the bounds of a memory buffer, which leads to remote code execution or, at the least, to knocking the appliance over. It has one precondition: the DTLS protocol must be in use, and DTLS is enabled by default on VPN virtual servers, which is the common Gateway configuration. So for most organisations running NetScaler as a remote-access gateway, the precondition is simply met out of the box.

Both are rated 9.5 out of 10, which is about as serious as the scale goes, and both are confirmed as being actively exploited rather than merely theoretically dangerous. The reporting from The Hacker News and BleepingComputer on 27 and 28 September aligns with the national advisories on the essential point: these are being used now, against unpatched appliances, by attackers who found them before the defenders did.

Which versions, and the ones with no fix

The affected releases are NetScaler ADC and NetScaler Gateway 14.1 before build 14.1-73.37, and 13.1 before build 13.1-64.23. The FIPS and NDcPP variants have their own fixed builds: 14.1-73.37-FIPS, and 13.1-37.279 for the 13.1 FIPS and NDcPP line. Updating to the relevant build or later is the fix.

There is a harder case buried in that list, and it is the one that catches people out. NetScaler 12.1 and 13.0 have reached end of life. An appliance on one of those versions is very probably vulnerable to the same class of flaw and will receive no fix, because the product is no longer supported. If that is you, there is no patch to install; the honest options are to migrate to a supported version at speed or to take the function off NetScaler altogether. An unsupported internet-facing security appliance is not a risk to be managed with a firewall rule; it is a decision that has already been made against you if you leave it running.

Why "shut it down" is the responsible advice, not an overreaction

It is unusual for national authorities to suggest taking a production appliance offline, and the instinct in most businesses is to treat that as alarmism. It is not, and the reason is worth understanding, because it is the same reason this keeps happening to this particular class of device.

A NetScaler sits at the perimeter. Its whole job is to be reachable from the internet and to broker access from there into the applications and networks behind it. That makes it the single most valuable thing on your estate for an attacker to own, because a foothold on the appliance is not a foothold on some peripheral server; it is a position astride the front door, with visibility of the traffic passing through and a direct path inward that does not require compromising a single laptop or phishing a single user. When a remote-access gateway has an unauthenticated remote-code-execution flaw under active exploitation, the appliance can be taken over faster than most organisations can patch, and the difference between an appliance that is merely vulnerable and one that is already compromised is not something you can tell by looking at it. Taking it offline removes the exposure while you get to a fixed build in a controlled way, rather than racing an attacker who has already started.

This is not NetScaler's first time in this position, and the history is the reason for the second half of this article. The "CitrixBleed" flaw of 2023 and its 2025 successor both turned on the same devices, and both taught the same lesson the hard way: attackers who reach these appliances steal the things that let them come back through the front door legitimately, and patching does not take those things away.

The part everyone gets wrong: patching does not evict the intruder

Here is the mistake I expect to see made across the country this week. An administrator learns of the flaws, updates the appliance to the fixed build, ticks the item off, and moves on. If that appliance was compromised at any point before the update, the update has changed nothing about the compromise. It has closed the window the attacker climbed in through, while the attacker is already inside the house.

The reason is specific to how these devices are attacked. An intruder on a NetScaler does not merely run a command and leave. They harvest what the appliance holds: active session tokens, which let them resume a legitimate user's authenticated session without a password; cached credentials; the appliance's own secrets and configuration. A session token or a stolen credential keeps working after you patch, because it is not the vulnerability, it is a valid key the attacker copied while the door was open. So the update must be followed, on any appliance that was exposed while exploitation was in the wild, by the assumption that it may have been reached, and by the steps that actually revoke what an intruder would have taken.

Concretely, once you are on a fixed build, terminate every active session on the appliance rather than letting existing sessions persist across the upgrade; the command set for clearing ICA and other active sessions is in Citrix's bulletin, and the point is that a session established before the patch must not survive it. Rotate the secrets the appliance holds and any credentials it stores or that pass through it, on the assumption they are known to someone else. Then hunt for the signs of an intruder who was already in: unexpected files or web shells on the appliance and on the systems immediately behind it, configuration changes you did not make, new local accounts, and authenticated sessions or logins that resume from addresses or at times that do not fit your users. The NCSC's guidance is explicit about using Citrix's published indicators of compromise, applying file integrity monitoring, and threat hunting rather than assuming a clean patch means a clean device. If you find evidence of compromise, this is an incident: treat it as one, preserve the appliance's state for forensics before you rebuild, and report it to the NCSC.

Seeing it: detection while you get to a fixed build

NetScaler appliances give a defender less to work with than a normal server, because they are closed FreeBSD-based devices you do not run your own agent on. What you can and should do is forward their syslog to your monitoring platform and watch it, and put strong file integrity monitoring and behavioural detection on the systems immediately behind the gateway, because inward movement from the appliance is often easier to see than the appliance compromise itself.

Our SOC runs Wazuh across client estates, and for a live advisory like this we write detections the same day rather than waiting for a signature. Assuming NetScaler syslog is being forwarded into Wazuh, the highest-value signals are shell or command execution on an appliance that should almost never spawn a shell, configuration changes outside a change window, and authenticated sessions resuming from anomalous sources. The ruleset below is a starting point keyed on those behaviours; treat the field matches as a template to fit to your own NetScaler log format and tune the IDs into your own range. Ours sit in the 150000 block with the rest of our web and edge rules.

<group name="citrix,netscaler,edge,attack,">

  <!-- Base: any syslog from a NetScaler appliance. Do NOT use
       <decoded_as>syslog</decoded_as> — 'syslog' is not a decoder name and
       wazuh-analysisd will refuse to load. Anchor on message content instead,
       and tune the match to how your appliances tag their messages. -->
  <rule id="152010" level="0">
    <match>NetScaler|nsppe|PPE-|ns.log</match>
    <description>NetScaler appliance syslog (base rule for correlation)</description>
  </rule>

  <!-- A shell or command execution on an appliance that should not be
       spawning shells from the request-handling path -->
  <rule id="152011" level="12">
    <if_sid>152010</if_sid>
    <match>/bin/sh|/bin/bash|nsapimgr|cli_script|freebsd shell</match>
    <description>NetScaler: unexpected shell or command execution — possible exploitation of CVE-2026-88771</description>
    <mitre>
      <id>T1190</id>
      <id>T1059</id>
    </mitre>
    <group>netscaler_rce,</group>
  </rule>

  <!-- Configuration change or new file written outside a change window.
       Pair with a scheduled "change window" active-response toggle if you have one -->
  <rule id="152012" level="10">
    <if_sid>152010</if_sid>
    <match>save config|rm /var|/netscaler/portal/scripts|write to /flash|create system file</match>
    <description>NetScaler: configuration or filesystem change — verify against an approved change</description>
    <mitre>
      <id>T1505.003</id>
    </mitre>
    <group>netscaler_persistence,</group>
  </rule>

  <!-- A DTLS-related crash or restart of the packet engine can accompany
       attempts against the memory-overflow flaw -->
  <rule id="152013" level="10">
    <if_sid>152010</if_sid>
    <regex type="pcre2">DTLS.*(core dump|packet engine|crash|restart)</regex>
    <description>NetScaler: DTLS packet-engine crash or restart — possible probing of CVE-2026-88772</description>
    <group>netscaler_dos,</group>
  </rule>

  <!-- Correlation: an RCE indicator and a persistence/config indicator from the
       same appliance in quick succession is a hands-on-keyboard intrusion -->
  <rule id="152014" level="14" frequency="2" timeframe="300">
    <if_matched_sid>152011</if_matched_sid>
    <same_source_ip />
    <description>NetScaler intrusion in progress: command execution followed by a filesystem or config change on the same appliance</description>
    <group>netscaler_rce,attack_success,</group>
  </rule>

</group>

The base rule is silent; 152011 fires on the shell-spawn fingerprint that unauthenticated command execution tends to leave; 152012 on configuration or filesystem changes you should be able to reconcile against a change record; 152013 on the packet-engine crashes that probing of the memory flaw can cause; and 152014 raises the alarm loudly when it sees an intrusion actually progressing. Behind the gateway, your ordinary file integrity monitoring and behavioural rules do the rest, catching the web shell, the new account or the lateral movement that follows a successful compromise. None of this replaces getting to a fixed build and clearing sessions; it is how you find out whether you were reached while you did.

Worth saying plainly: the attackers behind flaws like these do not keep office hours, and the quietest time to move against a perimeter appliance is a Friday evening or a weekend, when the people who would notice a NetScaler behaving oddly are least likely to be watching. Continuous monitoring is not a luxury on an edge device; it is the only thing standing between "exploited at 02:00" and "found at 09:00 on Monday". That is the daily work of a managed SOC, and it is why SOC365 writes and deploys detections like the above the day an advisory lands rather than the week after.

The wider lesson: the edge is the target

I wrote a few days ago about the Elementor flaw and the way a plugin becomes part of your attack surface. The NetScaler story is the same argument at the other end of the estate. The devices that exist to let people in are, by their nature, the devices most exposed to people you did not invite, and the security appliance at the perimeter is a piece of software like any other, with bugs like any other, run by a vendor whose patch cadence you inherit. The organisations that come through weeks like this one intact are not the ones with no vulnerable devices; almost everyone had one. They are the ones who knew they had it, got to a fixed build the same day, assumed compromise rather than hoping against it, and were watching closely enough to tell the difference. That is not a heroic posture. It is an inventory, a maintenance habit and a pair of eyes on the logs, and it is available to any organisation that decides the edge is worth the attention.

Frequently asked questions

Which NetScaler versions do I need, and how do I check mine? The fixed builds are 14.1-73.37 and later on the 14.1 line, and 13.1-64.23 and later on 13.1, with 14.1-73.37-FIPS and 13.1-37.279 for the FIPS and NDcPP variants. You can see your version in the appliance's administration interface or with the CLI. Versions 12.1 and 13.0 are end of life and will not be fixed: migrate to a supported release or remove the function.

We patched already. Are we safe? You have closed the way in, which is essential, but if the appliance was internet-facing while these flaws were being exploited, patching alone does not remove an intruder who got in first. Terminate all active sessions after the upgrade so that pre-patch sessions cannot persist, rotate the appliance's secrets and any credentials it handles, and hunt for signs of compromise using Citrix's published indicators. If you find any, treat it as an incident.

Why are we being told to take the appliance offline rather than just patch during a maintenance window? Because the flaw is being exploited faster than a typical maintenance schedule can respond, and a compromised perimeter appliance gives an attacker a direct route into your network. Taking it offline removes the exposure while you upgrade in a controlled way, rather than racing an attacker who may already be mid-exploit. If taking it offline is genuinely impossible, prioritise the upgrade above all other work and monitor the appliance intensively until it is done.

How would we know if we had already been compromised? Look for shells or unexpected processes on the appliance, web shells or new files on it and on the systems directly behind it, configuration changes and new accounts you cannot account for, and authenticated sessions that resume from unfamiliar addresses or at odd hours. Citrix has published specific indicators of compromise through the NetScaler Console and its bulletin; the NCSC recommends file integrity monitoring and active threat hunting rather than assuming a clean patch means a clean device.

Is this related to CitrixBleed? It is the same class of problem on the same class of device. CitrixBleed in 2023 and its successor in 2025 were also NetScaler flaws that let attackers steal session material and re-enter as legitimate users, and the eviction lesson is identical: the value an attacker extracts from these appliances outlives the patch, so recovery has to revoke sessions and credentials, not merely close the hole.