Citrix NetScaler: Patch First or Preserve Evidence First?

Citrix NetScaler: Patch First or Preserve Evidence First?

On 27 September 2026, CISA amplified Citrix's disclosure of eight new vulnerabilities in NetScaler ADC and NetScaler Gateway. Two of them, CVE-2026-88771 and CVE-2026-88772, were added to the Known Exploited Vulnerabilities catalog the same day, both marked as actively exploited, both with a remediation due date of 30 September 2026. That is three days.

Three days is not really the interesting part. The interesting part is that the government guidance and the vendor guidance, taken together, ask you to do two things that pull in opposite directions.

CISA's alert says to check for signs of compromise before patching, and warns that updates "may result in loss of forensic visibility." The KEV entries for both CVEs carry "forensicTriage": "Yes". Meanwhile the same alert says exploitation is already underway globally, and the usual operational instinct for a live RCE at the perimeter is to install the fix immediately. If your patch window is three days and the appliance is internet-facing, "collect evidence first" is exactly the instruction people skip.

Eight CVEs, two of them burning

The Citrix bulletin CTX697096 covers all eight. Only two are in the exploited catalog, and they are the two that matter for this week:

Read the first row carefully, because it removes the usual comfort of "we don't run that optional feature." Citrix's own wording is that no additional features or settings need to be enabled for a deployment to be vulnerable — CVE-2026-88771 applies to all NetScaler ADC and Gateway deployments, including those running the default configuration. There is no configuration audit that narrows your exposure here.

Fix versions are 14.1-73.37 and 13.1-64.23 and later, plus 14.1-73.37 FIPS and 13.1-37.279 for the FIPS and NDcPP builds. Secure Private Access Hybrid deployments running NetScaler instances are in scope too, and the bulletin only covers customer-managed appliances — Citrix upgrades its own managed cloud services and Adaptive Authentication separately.

Why the edge is worth breaking into

NetScaler is deployed as the internet-facing box that terminates remote access and fronts internal applications. Compromising it hands an attacker a foothold at the perimeter, which is a considerably better starting position than compromising a laptop inside your network. The timeline BleepingComputer reconstructed shows how the warning actually spread: administrators reporting that IT suppliers advised shutting NetScalers down over a weekend, CERTs reaching out to organisations, watchTowr reacting publicly to the rumours, and NCSC-NL sending pre-notification to organisations in the Netherlands. Citrix found the bugs while investigating customer incidents, and NCSC-NL's notification asked Citrix to also file under the EU's Cyber Resilience Act.

The instruction that fights the clock

Here is the tension, stated plainly. You have an unpatched, actively exploited unauthenticated RCE on your perimeter. The remediation guidance is a firmware upgrade on an appliance class where upgrades are complex and may require downtime — Citrix and NCSC-NL both said so. And the evidence you would need to know whether you were already owned might live only in the appliance's memory and its own logs, some of which the upgrade replaces.

Citrix's own guidance for a suspected compromise, CTX694799, is honest about the limits. It says explicitly that Cloud Software Group does not support forensic investigations. What it can give you is a collection procedure, and the procedure is worth reading closely because two of its steps are themselves destructive:

VPX  — snapshot the instance BEFORE isolation; document system time,
       timezone and NTP config first; preserve remote syslog + Console
       logs alongside local logs; generate a technical support bundle
MPX  — power down only after memory preservation; pull the disks and
       image them through a hardware write-blocker; keep two copies
       (one to analyse, one as evidence) and document chain of custody

Then the step that trips people up: to capture a core dump of the Packet Engine, "the system will perform a warm restart during this process and SSH connections will disconnect." The dump lands in /var/core/<N> where N is the highest numbered folder, files prefixed NSPPE-, gzipped after a short delay.

So the investigation you have been told to prioritise restarts the box. That is not an argument against following the procedure — a warm restart is vastly cheaper than losing the memory — but it does mean the order of operations is the whole game. Snapshot first, isolate second, and note the time gap you created rather than discovering it later.

Your three-day window, in commands

The pragmatic version: capture from the host side, make no changes to the appliance, and keep the raw artefacts. The running configuration on the appliance is what decides whether the preconditions in that table are actually met for you, and ns.conf is where that configuration lives — so pulling it is both your baseline and the answer to "was I in scope".

# Read-only capture. Do this before the upgrade, not after.
mkdir -p netscaler-prepatch-$(date +%F)
cd netscaler-prepatch-$(date +%F)

# Baseline config: the file that decides whether the preconditions above are met.
cp /nsconfig/ns.conf ./ns.conf.before

# CVE-2026-88772 (DTLS) and CVE-2026-88775 (Gateway / AAA vserver) preconditions.
grep -nE "add (vpn|authentication) vserver" ns.conf.before > dtls-gateway-vserver.txt

# A VPN vserver with no "-dtls OFF" means DTLS is enabled — the precondition is MET.
grep -nE "add vpn vserver" ns.conf.before | grep -v "dtls OFF" > dtls-exposure.txt

# CVE-2026-88777 preconditions (FTP ALG, health monitors, NAT64, DNS64).
grep -inE "add (lb|cs) vserver .* FTP|add service .* FTP|add lsn group|add nat64|dns64" \
  ns.conf.before > l7-preconditions.txt

# Checksum it. If the config changes before the upgrade, you want to know.
sha256sum ns.conf.before > ns.conf.before.sha256

Then the two NetScaler-side checks, which are ADC CLI commands and not shell commands. Together they answer the questions the upgrade will not:

netscaler> show ns version
...record the Release and Build ID lines here — they are your baseline...

netscaler> show ns tcpparam | grep "Enhanced ISN Generation"
Enhanced ISN Generation: DISABLED:

DISABLED: means the precondition for CVE-2026-88778 is met, and it stays met after you patch. TCP initial sequence number prediction is a design weakness, not a code bug — the bulletin sends you to the enhanced ISN generation configuration rather than to a patch. "We are on the fixed build" is not a complete answer for this one.

A data gotcha if you script against the feed

If you pull the KEV catalog as JSON, do not trust it blindly. Reading the feed directly, the entry for CVE-2026-88771 lists "cwes": ["CWE-119"], while Citrix classifies 88771 as CWE-20 (improper input validation) and reserves CWE-119 for 88772. Both entries also carry the same notes block, and that block ends with an NVD link pointing at CVE-2026-88772 — so following the note automatically sends you to the wrong record for the input-validation bug.

None of this changes what you patch. It does mean a dashboard keyed off the cwes array will group two different bug classes under one CWE, and an automated enrichment pipeline that trusts notes will silently attach the wrong NVD entry. If your tooling derives "which CWE do I have" from the KEV feed, resolve the authoritative classification from the vendor bulletin instead.

What the deadline actually forces

For federal civilian agencies in the United States, 30 September is a hard requirement, and the KEV requiredAction text is unusually pointed: apply mitigations per vendor instructions, follow the BOD 26-04 patching guidance, and for cloud services follow the applicable guidance or discontinue use of the product. Both entries also record ransomware use as "Unknown" — which is not "no", it is "nobody has said".

For everyone else, the deadline is what it always is: the shortest acceptable window. The organisations that handled this well were not the ones who patched fastest. They were the ones that, before anyone touched the appliance, could answer three questions: what was this box running, is it in scope, and if it is already compromised, what did the attacker reach. CISA's alert and Citrix's remediation runbook give you the material for all three. The only thing they cannot give you is a fourth upgrade cycle's worth of memory if you patch first and ask later.

This is the same shape of problem as the ArcGIS critical vulnerability wave we covered earlier — internet-facing infrastructure, a short disclosure-to-patch interval, and the temptation to treat the firmware upgrade as the end of the incident rather than the start of the investigation.

Sources

• CISA: Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway
• Cloud Software Group (Citrix): Citrix NetScaler ADC and NetScaler Gateway Security Bulletin CTX697096
• Cloud Software Group (Citrix): Steps to Take if NetScaler ADC is Suspected to be Compromised (CTX694799)
• BleepingComputer: Citrix confirms two NetScaler RCE zero-days exploited in attacks
• CISA: Known Exploited Vulnerabilities Catalog