JFrog Artifactory authentication bypass advisory<\/a>, where the upstream community template was an active exploit that minted admin tokens and ours was a passive version check.<\/p>\nWhat attackers did after landing is better documented than usual and worth reading as a hunting list. Rapid7 observed command injection running tar<\/code> over \/flash\/nsconfig<\/code>, writing the archive under the web root so it could be retrieved with a single unauthenticated GET. That archive contains ns.conf<\/code>, TLS private keys and stored credentials. Mandiant and others report a PHP web shell at \/var\/netscaler\/logon\/LogonPoint\/custom\/.ctxs.receiver<\/code> with SHA256 ed082f744f035035900f67edf438f2f7d0528ac501234f63d476d65273cdb9a1<\/code>, modifications to httpd.conf<\/code>, and two named implants, WHIPSHOT and a Python tunneler called SLAPSHOT. Some web shell variants answer attacker requests while returning HTTP 404, so a status-code-only sweep of the web root will miss them.<\/p>\nAm I affected? Quick manual checks<\/h2>\n
The authoritative check is local.<\/strong> On the appliance:<\/p>\nshow ns version\n<\/code><\/pre>\nCompare against the table above, being careful about which line you are on. Then confirm DTLS state for CVE-2026-88772, remembering that this only narrows the second CVE:<\/p>\n
show vpn vserver <name>\n<\/code><\/pre>\nA Gateway virtual server is exposed unless its configuration shows -dtls OFF<\/code>, and any virtual server of type DTLS is exposed by definition. Disabling DTLS is not remediation. CVE-2026-88771 remains independently exploitable and needs no DTLS at all.<\/p>\nThe external fingerprint is harder, which is the interesting part.<\/strong> NetScaler advertises no version to unauthenticated clients. The HTTP response headers carry nothing. The login HTML and the JavaScript bundles are byte-identical across builds. That is precisely why Shodan and Censys records for these appliances have no version field, and why a version check adds genuine value over a banner grab.<\/p>\nThere are two usable oracles, and neither requires authentication.<\/p>\n
The better one is the firmware compile timestamp, a technique originally published by Fox-IT. Every build ships a static language resource at \/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz<\/code>. The gzip format stores a modification time in the header, bytes 4 through 8, and the firmware build process sets it at compile time. That value maps one to one onto a published build. You can read it by hand:<\/p>\ncurl -sk https:\/\/vpn.example.com\/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz \\\n | head -c 8 | tail -c 4 | xxd -e -g4 | awk '{print strtonum("0x"$2)}'\n<\/code><\/pre>\nThe second oracle is the pre-logon endpoint analysis package. Gateway has to serve the EPA client to users who have not authenticated yet, so \/epa\/scripts\/linux\/nsepa.deb<\/code> is readable pre-auth, and its length changes between builds. Reading the Content-Length<\/code> header is enough; there is no need to download eleven megabytes.<\/p>\nWhat the external signal can and cannot tell you: a resolved build is solid evidence of the firmware level and nothing more. It says nothing about whether the box was compromised during the three weeks before the patch existed. And a failure<\/em> to resolve a build means “unknown, go and check by hand”, never “patched”. More on that blind spot below, because it is the honest limit of this whole approach.<\/p>\nNuclei detection template for CVE-2026-88771<\/h2>\n
Two templates ship: a reusable firmware fingerprint, and a CTX697096 verdict built on top of it. Both are passive. Both issue nothing but plain GET requests for static files.<\/p>\n
The verdict template works by set membership rather than version comparison, and the reason is worth a paragraph. The public build table currently maps 219 firmware builds to compile timestamps, and every single one of them predates every CTX697096 fix floor. We verify that mechanically every time the template is regenerated. So a timestamp hit cannot resolve to a patched appliance, and there is no four-way cross-branch version comparison to get wrong. The 14.1, 13.1, 13.1-FIPS and NDcPP floors stop being a problem because we never compare versions at all.<\/p>\n
id: netscaler-ctx697096-patch-gap\n\ninfo:\n name: Citrix NetScaler ADC \/ Gateway - CTX697096 Patch Gap (CVE-2026-88771, CVE-2026-88772)\n author: xer0dayz\n severity: critical\n description: |\n Builds below the CTX697096 fix floors are affected by CVE-2026-88771, an improper\n input validation flaw allowing unauthenticated command execution, and\n CVE-2026-88772, a DTLS memory overflow leading to RCE or DoS. Both were added to\n CISA KEV on 2026-09-27 and both were exploited as zero-days before disclosure.\n\n This template is NON-DESTRUCTIVE and PASSIVE. It issues a single GET for the static\n resource \/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz and reads the firmware compile\n timestamp from the gzip header MTIME field. It sends no command injection, no SAML\n message, no DTLS record and no oversized buffer. It does not touch the login\n endpoint.\n remediation: |\n Upgrade to 14.1-73.37, 13.1-64.23, 14.1-73.37 FIPS, or 13.1-37.279 (FIPS \/ NDcPP).\n Branches 12.1 and 13.0 are end of life and have no fix; migrate them.\n Disabling DTLS mitigates CVE-2026-88772 only. CVE-2026-88771 is independent.\n reference:\n - https:\/\/support.citrix.com\/support-home\/kbsearch\/article?articleNumber=CTX697096\n - https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2026-88771\n - https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2026-88772\n - https:\/\/github.com\/fox-it\/citrix-netscaler-triage\n classification:\n cvss-metrics: CVSS:4.0\/AV:N\/AC:L\/AT:P\/PR:N\/UI:N\/VC:H\/VI:H\/VA:H\/SC:H\/SI:H\/SA:H\n cvss-score: 9.5\n cve-id: CVE-2026-88771\n cwe-id: CWE-20\n metadata:\n verified: false\n max-request: 2\n vendor: citrix\n product: netscaler_application_delivery_controller\n patched-versions: 14.1-73.37,13.1-64.23,14.1-73.37-FIPS,13.1-37.279\n kev: true\n kev-date: 2026-09-27\n shodan-query: title:"NetScaler Gateway"\n tags: cve,cve2026,netscaler,citrix,rce,kev,patch-gap,version-detect,passive\n\nhttp:\n - method: GET\n path:\n - "{{BaseURL}}\/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz"\n - "{{BaseURL}}\/rdx_en.json.gz"\n\n stop-at-first-match: true\n redirects: false\n matchers-condition: or\n\n matchers:\n # Supported branch below its fix floor. A fixed build exists.\n - type: dsl\n name: netscaler-known-vulnerable-build\n dsl:\n - "status_code == 200"\n - "starts_with(hex_encode(body), '1f8b')"\n - "gzip_mtime(body) > 0"\n - "contains('|1690503901|1762655407| ...219 stamps... |',\n concat('|', to_string(gzip_mtime(body)), '|'))"\n condition: and\n\n # 11.x \/ 12.x \/ 13.0: end of life, no fixed build exists at all.\n - type: dsl\n name: netscaler-eol-branch-no-fix-available\n dsl:\n - "status_code == 200"\n - "starts_with(hex_encode(body), '1f8b')"\n - "gzip_mtime(body) > 0"\n - "contains('|1535167752|1762830097| ...EOL stamps... |',\n concat('|', to_string(gzip_mtime(body)), '|'))"\n condition: and\n\n extractors:\n - type: dsl\n name: firmware_stamp\n dsl:\n - "concat('rdx_en_mtime=', to_string(gzip_mtime(body)), ' compiled=',\n date_time('2006-01-02T15:04:05Z07:00', gzip_mtime(body)))"\n<\/code><\/pre>\nNuclei does the hard part for you here. gzip_mtime()<\/code> is a first-class DSL function in the engine, so pulling a firmware compile time out of a gzip header is one expression rather than hand-rolled byte slicing. As far as we can tell nobody had pointed it at NetScaler before.<\/p>\nSave and run:<\/p>\n
nuclei -t netscaler-ctx697096-patch-gap.yaml -u https:\/\/vpn.example.com\nnuclei -t netscaler-ctx697096-patch-gap.yaml -l netscaler-hosts.txt -jsonl\n<\/code><\/pre>\nA match looks like this:<\/p>\n
[netscaler-ctx697096-patch-gap:netscaler-known-vulnerable-build] [http] [critical]\nhttps:\/\/vpn.example.com\/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz\n[rdx_en_mtime=1762655407 compiled=2025-11-08T21:30:07-05:00]\n<\/code><\/pre>\nPass that stamp to the bundled cve-2026-88771-detect.py<\/code> and it resolves to an exact build, in this case 14.1-56.74, below the 14.1-73.37 floor.<\/p>\nWhy this template is passive, and why that is not just caution<\/h3>\n
There is an obvious active check available. Plant a crash-diagnostic-shaped string in a login field, then look at whether the response reflects it unsanitized. An open community template upstream does roughly that.<\/p>\n
We will not ship it, and the reason is specific rather than squeamish. An active check for this bug writes attacker-shaped text into the exact log file that incident responders need in order to establish prior compromise.<\/strong> This is an appliance CISA has flagged for forensic triage, exploited for three weeks before anyone had a patch, where the vendor’s own detection script only works if the logs have not yet rotated. Scanning it with a log-poisoning probe contaminates the primary evidence, burns log retention you may need, and makes your own scanner indistinguishable from the intrusion you are trying to rule out. On a fleet of a few hundred appliances you would be manufacturing a few hundred false leads for your own IR team.<\/p>\nA passive build check answers the same question with none of that.<\/p>\n
Two blind spots, stated plainly<\/h3>\n
The build table ends on 11 November 2025.<\/strong> The newest builds it maps are 14.1-56.74 and 13.1-61.23. Anything released after that date is unmapped, which means a genuinely vulnerable 14.1-66.x through 14.1-73.36 appliance produces no finding from this template<\/strong>. Silence means undetermined. It does not mean patched. This is the honest cost of a false-positive-free design, and the companion fingerprint template plus the EPA package size oracle exist to narrow the gap. For anything you care about, confirm with show ns version<\/code>.<\/p>\nSome firmware images are compressed with gzip -n<\/code><\/strong>, which zeroes the timestamp field. The matcher guard rejects a zero, so those hosts also report nothing. Same rule: undetermined, not clean.<\/p>\nA practitioner note while we are here, because it cost us some time: Nuclei’s date_time()<\/code> does not use strftime tokens. In the %<\/code> form, %m<\/code> yields the minute and %M<\/code> the month, and a bare Go layout such as 2006-01-02 15:04:05<\/code> is mangled into a run of digits. Only an offset-bearing layout like 2006-01-02T15:04:05Z07:00<\/code> renders correctly, and it renders in the scanning host’s local zone, not UTC. If you are comparing output against the Fox-IT table, which is published in UTC, use the raw epoch.<\/p>\nDetecting CVE-2026-88771 across your attack surface with Sn1per<\/h2>\n
A patch-gap template is only as good as your host list, and for edge appliances the host list is the actual problem. NetScaler appliances are bought by network teams, deployed for one application, inherited through acquisitions, and stood up as a disaster-recovery pair that nobody has logged into for two years. The ones that stay vulnerable are not the ones your vulnerability scanner knows about. They are the ones nobody remembered they had.<\/p>\n
So treat it as a discovery problem before a scanning problem.<\/p>\n
# Discover first: subdomains, certificate transparency, ports, services\nsniper -t example.com -m recon -w citrix-audit\n\n# Then the web pass, which fires the CTX697096 templates on every HTTPS port\nsniper -t vpn.example.com -m web -w citrix-audit\n\n# Sweep a known fleet\nsniper -f netscaler-hosts.txt -m webscan -w citrix-audit\n<\/code><\/pre>\nBoth templates drop into \/sniper\/templates\/nuclei\/server\/<\/code> and need no configuration change, because NUCLEI_TEMPLATES<\/code> is a directory list that Nuclei recurses. Findings surface as P1 CRITICAL in the workspace, carrying the matcher name and the build stamp. Pull them out of a Professional or Enterprise install over the API:<\/p>\ncurl -sk -H "X-API-Key: $SN1PER_API_KEY" \\\n "https:\/\/sn1per.local\/pro\/api.php?action=vulnerabilities&workspace=citrix-audit" \\\n | jq -r '.[] | select(.name | test("CTX697096")) | [.host, .severity, .details] | @tsv'\n<\/code><\/pre>\nOne more reason this particular job belongs on infrastructure you control. The output of this scan is a ranked list of your unpatched internet-facing VPN concentrators, during a window when a working exploit is public. That is not a document to hand to a multi-tenant SaaS scanner and hope about. Sn1per runs on your own hardware, in your own network, and the results stay there. We wrote about the general version of this argument in external attack surface management with Sn1per<\/a> and compared the self-hosted options in open source self-hosted attack surface management tools<\/a>.<\/p>\nWhich Sn1per edition fits<\/h2>\n
\n\n\n| Capability<\/th>\n | Community<\/th>\n | Professional 2026<\/a><\/th>\n | Enterprise<\/a><\/th>\n<\/tr>\n<\/thead>\n\n\n| Run the CTX697096 templates<\/td>\n | Yes<\/td>\n | Yes<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| Curated Nuclei set maintained for you<\/td>\n | Partial<\/td>\n | Yes<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| Workspaces and scan history<\/td>\n | Basic<\/td>\n | Yes<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| Web UI with asset risk ranking<\/td>\n | No<\/td>\n | Yes<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| JSON API for finding export<\/td>\n | No<\/td>\n | Yes<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| Scheduled recurring surface sweeps<\/td>\n | No<\/td>\n | Limited<\/td>\n | Yes<\/td>\n<\/tr>\n | \n| Multi-user, delegated workspaces<\/td>\n | No<\/td>\n | No<\/td>\n | Yes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n For a one-off answer to “are any of our NetScalers unpatched”, Community plus the template is enough. For the recurring version of that question, which is the one that actually matters given NetScaler has produced five KEV entries in 2026 alone, you want scheduling and history. There is more on that trade-off in our write-up of automated penetration testing tools<\/a>.<\/p>\nRemediation and mitigation<\/h2>\n\n- Upgrade to the CTX697096 builds now.<\/strong> 14.1-73.37, 13.1-64.23, 14.1-73.37 FIPS, or 13.1-37.279 for FIPS and NDcPP. The federal deadline was 30 September; there is no reading of this where waiting is reasonable.<\/li>\n
- Migrate 12.1 and 13.0 appliances.<\/strong> There is no patch. A CVSS 9.5 with no vendor fix path on an internet-facing VPN concentrator is an architectural problem, not a patching one, and it should sit above the merely-unpatched boxes in your queue.<\/li>\n
- Patch both HA nodes.<\/strong> Check the standby by address, not through the VIP.<\/li>\n
- Assume breach, and do it before you reboot into the new image.<\/strong> Exploitation ran for roughly three weeks before a fix existed. Preserve the appliance logs and a configuration snapshot first. Citrix offers IOC scanning through NetScaler Console on 14.1-73.36 or later with telemetry enabled, but states its own IOC set does not cover every known technique, and the vendor script depends on logs that may already have rotated. A clean IOC scan is weak evidence.<\/li>\n
- Hunt for the known artifacts.<\/strong> The web shell path
\/var\/netscaler\/logon\/LogonPoint\/custom\/.ctxs.receiver<\/code> and its SHA256, unexpected httpd.conf<\/code> modifications, stray archives under the GUI web root, and DTLS handshake failures followed by a packet engine crash. Remember the 404-returning web shell variants and the up-to-24-hour delay between injection and execution, which means your log review window needs to start well before the first suspicious execution.<\/li>\n- Rotate everything the appliance held.<\/strong> TLS private keys, service account credentials in
ns.conf<\/code>, LDAP and RADIUS bind passwords, session signing material. If the configuration archive was exfiltrated, all of it is burned. Patching does not revoke a credential.<\/li>\n- Reduce the surface afterwards.<\/strong> Management interfaces should not be internet-facing. Turn DTLS off where no client needs it, understanding that this narrows CVE-2026-88772 only.<\/li>\n<\/ol>\n
Frequently asked questions<\/h2>\nWhat is CVE-2026-88771?<\/strong>
\nIt is an improper input validation vulnerability, CWE-20, in Citrix NetScaler ADC and NetScaler Gateway that lets an unauthenticated attacker run arbitrary commands as root. The attacker gets their text into an appliance log, and a Perl crash-handling script later reads that text back and interpolates it into a shell command. Citrix scores it CVSSv4 9.5 and NVD scores it CVSS 3.1 9.8. It affects the default configuration, so no special feature needs to be enabled.<\/p>\nWhich NetScaler versions are affected by CVE-2026-88771 and CVE-2026-88772?<\/strong>
\nNetScaler ADC and Gateway before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, and before 13.1-37.279 for the FIPS and NDcPP lines. Branches 12.1 and 13.0 are end of life and get no fix for either CVE. Patching for the earlier CVE-2026-19490 does not cover these.<\/p>\nAre CVE-2026-88771 and CVE-2026-88772 being exploited in the wild?<\/strong>
\nYes. Both were exploited as zero-days before Citrix published CTX697096, and CISA added both to the KEV catalog on 27 September 2026 with a three-day remediation deadline. Google Threat Intelligence Group and Mandiant date the campaign to early September, affecting government, financial services, education, legal and professional services organizations in North America and Europe. A public proof of concept for CVE-2026-88771 appeared on 27 September.<\/p>\nHow do I detect CVE-2026-88771 remotely if NetScaler does not report its version?<\/strong>
\nRead the firmware compile timestamp out of the gzip header of \/vpn\/js\/rdx\/core\/lang\/rdx_en.json.gz<\/code>, which maps one to one onto a published build. The Nuclei template above does this with the engine’s native gzip_mtime()<\/code> function, and the bundled Python script resolves the timestamp to an exact build string. Be aware the public build table ends in November 2025, so a newer appliance will come back undetermined rather than clean.<\/p>\nIs disabling DTLS enough to fix this?<\/strong>
\nNo, and this is the most common mistake being made with this bulletin. Disabling DTLS removes exposure to CVE-2026-88772 only. CVE-2026-88771 needs no DTLS and remains fully exploitable against an unpatched appliance in its default configuration. Only the firmware upgrade addresses both.<\/p>\nIs the Nuclei template safe to run against production appliances?<\/strong>
\nYes. It sends two plain GET requests for static files and reads metadata from the response. No command injection, no SAML message, no DTLS record, no oversized buffer, and it never touches the login endpoint. We deliberately avoided the available active check because it would write attacker-shaped strings into the same logs your incident responders need, on appliances flagged for forensic triage.<\/p>\nClosing<\/h2>\nThe interesting thing about CVE-2026-88771 is not that an edge appliance had a command injection. It is that the delivery vehicle was a log file. The vulnerable code was never reachable directly, the entry point was any one of a dozen unrelated pre-auth paths, and execution happened up to a day later. Signature-based detection struggles with all three properties. Knowing precisely what firmware every appliance on your perimeter is running does not struggle with any of them, which is why a boring build inventory keeps outperforming clever detection on exactly this class of bug.<\/p>\n NetScaler has produced five CISA KEV entries in the first nine months of 2026. There will be a sixth. The build fingerprint template is the part of this work that keeps paying, because it answers the next advisory too.<\/p>\n Grab the templates, run them across every HTTPS port you own rather than just the hosts you remember, and if you find an appliance below the floor, preserve the evidence before you reboot it.<\/p>\n | |