Citrix published security bulletin CTX697096 on Sunday, September 27, covering eight vulnerabilities in NetScaler ADC and NetScaler Gateway. CISA added two of them, CVE-2026-88771 and CVE-2026-88772, to the Known Exploited Vulnerabilities catalog the same day with a due date of Wednesday, September 30. Exploitation ran ahead of the bulletin: GreyNoise reported a malicious attempt against a then-undetected NetScaler zero-day on Thursday, September 24, and by Saturday customers were being told to disconnect their servers. Mandiant has since traced exploitation of CVE-2026-88772 back to early September. Citrix Systems, Inc. files with the SEC from 851 West Cypress Creek Road, Fort Lauderdale.
What the bulletin actually fixes
The "What Customers Should Do" section names four fixed builds:
- Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.37 and later releases
- Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.23 and later releases of 13.1
- Citrix NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS and later releases of 14.1-FIPS
- Citrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.279 and later releases of 13.1-FIPS and 13.1-NDcPP
Then, separately, a sentence that is not a build at all: "NetScaler deployments impacted by CVE-2026-88778 should apply the TCP configuration change."
CVE-2026-88778 is TCP initial sequence number prediction — CWE-342, predictable exact value from previous values, CVSS v4.0 8.8. The fix is a global TCP parameter called enhancedISNgeneration, and NetScaler's documentation for it says this: "When enabled, the parameter increases the variance of the initial sequence numbers (ISN) generated by NetScaler while establishing a TCP connection... By default, the parameter is disabled."
A setting that ships disabled does not get enabled by a firmware upgrade. An appliance moved to 14.1-73.37 and marked closed against CTX697096 still has the eighth one open.
The practice: record the config state next to the build number
The bulletin's own precondition test for CVE-2026-88778 is a config state rather than a version. Two conditions, both required: at least one virtual server of a listed type (27 of them, including HTTP, SSL, SSL_BRIDGE, TCP, FTP, MYSQL, ORACLE and MQTT), and this command returning DISABLED:
show ns tcpparam | grep "Enhanced ISN Generation"
One line, from the vendor, with an observable answer. Almost every NetScaler in production meets the first condition, so the second line decides it.
The structural reason this recurs on every edge vendor is that remediation tracking is keyed to version strings, because that is what asset inventories and vulnerability scanners hold. A configuration fix has no version string to match, so it falls out of the pipeline that closes the ticket. The same bulletin demonstrates the other half of the problem, which is that the precondition clause rather than the severity score decides what can reach you, and preconditions are config state too. CVE-2026-88772's precondition is DTLS, which the bulletin notes is "Enabled by default on VPN vServer" — the gate most teams assume is shut ships open.
Severity would not have sorted these either. NVD scores CVE-2026-88773 at CVSS v3.1 10.0, the highest of the eight, and it is not in KEV; CVE-2026-88772 scores 8.1 and it is. Citrix's own v4.0 numbers reverse that order, putting 88772 at 9.5 above 88773 at 9.3. Which argues for treating your own configuration as the patch trigger instead of KEV membership: the catalog says what is exploited somewhere, the config says what is exposed here.
Enabling the parameter costs a set ns tcpparam -enhancedISNgeneration ENABLED change to a global setting on a device in the traffic path, which means its own ticket and its own window rather than riding along with the firmware upgrade — which is exactly why it gets dropped. It is global, not per-vserver, so you cannot stage it one application at a time. The documentation scopes the behaviour to TCP connections where NetScaler acts as the server, which keeps the blast radius small but does not remove the window.
If you cannot take that window this month, the honest position is to leave the CTX697096 ticket open with CVE-2026-88778 named in it and a date attached, rather than reporting the bulletin closed on the strength of seven out of eight.
One sequencing note: Mandiant's Charles Carmakal said customers should check for compromise before upgrading, because patching may not resolve an already-infected system. On an appliance that was reachable during the exposure window, evidence collection comes before the upgrade.
What to check this week
- On every NetScaler, run
show ns tcpparam | grep "Enhanced ISN Generation"and record the output in the same place you record the build number. - Find any change ticket referencing CTX697096 that reads "upgraded to 14.1-73.37, bulletin closed." It is wrong by one CVE until that line says ENABLED.
- FIPS and NDcPP appliances take a different number, 13.1.37.279 rather than 13.1-64.23, and the bulletin punctuates it two ways:
13.1.37.279in the fixed list,13.1-37.279in the affected list. - For each VPN vServer, is
-dtls OFFexplicitly set? If it is absent, DTLS is enabled by default and CVE-2026-88772's precondition is met. - Does your remediation tracking have a field that can hold a non-version answer? If the only closeable state is a build number, every configuration fix in every future advisory gets dropped silently.
North InfoSec runs AI-assisted penetration testing and security assessments, including verifying that a remediation actually landed rather than that a version number changed. northinfosec.com