Citrix NetScaler Zero-Day: Detecting and Investigating CVE-2026-88771 and CVE-2026-88772

For most of September, attackers broke into Citrix NetScaler appliances through two zero-day flaws, CVE-2026-88771 and CVE-2026-88772, that had no patch. Citrix fixed both on September 27, and CISA added them to its Known Exploited Vulnerabilities (KEV) catalog the same day, giving federal civilian agencies until September 30 to act. Security researcher Kevin Beaumont, who is tracking the intrusions, reports two details that matter for the response. Each compromised appliance received its own web shell, and the attackers ran cleanup commands to delete the traces they left behind.

Patching stops new break-ins, but it cannot tell you whether anyone got in during the weeks before the fix. That is the first question leadership will ask. Answering it takes three pieces of work: understanding what the two flaws expose, hunting for access the attackers built to leave little evidence, and investigating anything the hunt finds before the remaining evidence is gone. The method for the last part is the same one used in any web shell investigation. On a NetScaler, though, the evidence comes from different sources than it does on a Windows server.

{{ebook-cta}}

What We Know About the Citrix NetScaler Zero-Day

The Citrix NetScaler zero-day is a pair of critical flaws in NetScaler ADC and NetScaler Gateway, both rated 9.5 under CVSS 4.0. CVE-2026-88771 is an input validation flaw that lets an unauthenticated attacker run arbitrary commands, and Citrix says it affects deployments without any special configuration. CVE-2026-88772 is a memory overflow that can lead to remote code execution or denial of service. It requires DTLS, which is on by default for VPN virtual servers, so many Gateway deployments meet the condition.

Fixed builds are 14.1-73.37 and 13.1-64.23, plus 14.1-73.37 FIPS and 13.1-37.279 for the FIPS and NDcPP editions. Versions 12.1 and 13.0 are end of life and will not get a fix. The same bulletin, CTX697096, also patches six additional flaws. Shadowserver counted more than 23,000 internet-exposed NetScaler IP addresses.

The timeline matters for scoping. watchTowr warned publicly on September 26 that exploits were circulating, after the flaws surfaced during forensic investigations. In the days around the disclosure, IT suppliers, CERTs, and national cybersecurity agencies privately contacted affected organizations, and at least one supplier told a customer to shut its appliances down. Beaumont also said the attacks had been unfolding for the entire month. No actor has been named publicly. Beaumont assessed the activity as likely nation-state aligned and focused on espionage. Attribution for appliance attacks in general is likely to get harder. AI has made vulnerability research cheap enough that less sophisticated attackers, with no known profile, can now use exploits that once took a nation-state budget. That matters for scoping, because investigators who know the attacker can work out what they were likely after.

As with the recent SharePoint zero-day, attackers here turned an unauthenticated exploit into lasting access by planting a web shell on an internet-facing server. Two things make the Citrix NetScaler zero-day harder to investigate than that case. A NetScaler appliance runs no EDR agent, so the process telemetry behind a typical EDR alert investigation does not exist on the device. The attackers also worked to remove what the appliance did record.

Why a Patched NetScaler Can Still Be Compromised

An upgrade replaces the vulnerable code. It does not remove files the attacker already wrote, and it does not revoke credentials they already read. CISA advised agencies to check for signs of compromise before patching and to preserve evidence, because the update itself may destroy forensic visibility. The Dutch NCSC recommended backing up appliance memory and at least a month of logs first.

Patching an edge appliance is rarely quick. The upgrade usually takes remote access down, so it waits for change approval and a maintenance window, and new builds sometimes bring bugs of their own. The hunt has to cover every day until the last appliance is upgraded, as well as the weeks before the fix.

Citrix provides an IOC scan through NetScaler Console, and it warns that those indicators might fail to identify real compromises. Beaumont added a practical limit: the scan only works if the appliance logs have not rotated. After weeks of exploitation, on a device with limited local storage, many of them will have.

The credentials stored on the appliance raise the stakes. In the 2023 campaign against CVE-2023-3519, documented in CISA advisory AA23-201A, attackers read the NetScaler configuration and key files to decrypt stored Active Directory credentials, then queried the domain with ldapsearch. There is no public report yet that this campaign did the same. Teams should still test for it, because the appliance usually holds a service account with directory access.

Hunting for Citrix NetScaler Zero-Day Exploitation

For the Citrix NetScaler zero-day, a retrospective hunt is part of remediation. It follows the by-exclusion approach used in threat hunting generally: assume compromise, then work to prove absence. The hunt starts with an inventory, then accounts for three facts about this campaign.

Asset inventory first. List every NetScaler you run, its build number, and whether DTLS is on. The network team usually owns this list, and the logs a SOC collects rarely name an appliance's model or firmware build. Guessing the build from traffic produces false positives, so get the list from the team that manages the devices. For DTLS, check the configuration: a Gateway virtual server is exposed to CVE-2026-88772 unless its configuration includes -dtls OFF, and any virtual server of type DTLS is exposed. Configuration lines to look for:

• add vpn vserver vpn1 SSL 10.0.0.0 443 -Listenpolicy NONE: DTLS is not disabled, so it is on by default
• add vpn vserver vpn1 SSL 10.0.0.0 443 -dtls OFF -Listenpolicy NONE: DTLS is disabled
• add vpn vserver vs1 DTLS 10.11.1.1 443: DTLS is enabled
• add lb vserver vd_dtls DTLS 10.146.111.74 443 -persistenceType NONE -cltTimeout 120: DTLS is enabled

File comparison instead of hashes. If every appliance got a different shell, a published file hash will not match yours. Find the shells by comparison instead: list every script file in the directories the appliance serves, and flag anything newer than the firmware install or absent from a clean build of the same version. In 2023 the shells were PHP files in /netscaler/ns_gui/vpn/ and /var/vpn/, and AA23-201A shows the find command used to surface them by modification date. The NCSC-NL check script from 2025 also looks for files that indicate compromise, and its authors say it is not tied to one CVE.

• find /netscaler/ns_gui/ -type f -name *.php -newermt [DATE]

Local logs against forwarded logs. The attackers deleted artifacts, so the local record may be clean. Logs forwarded to a SIEM or syslog server are the copy they could not reach from the appliance, so compare the two. Three patterns deserve an investigation: a local log that starts partway through September, an empty shell history on an appliance your admins log into, and a gap in forwarded events that matches no maintenance window. For the 2023 campaign, AA23-201A pointed to these log files and search terms:

• httperror.log*: search for .sh and .php
• sh.log* and bash.log*: search for ldapsearch, openssl, and ns_gui/vpn

Published log indicators. Beaumont suggested searching SIEM data for these patterns:

• A base64 string placed directly after the User-Agent field, with no space between them
• pitboss*IFS
• pitboss*b64decode

A hit is strong evidence of compromise, but a miss does not clear the device, because the attackers deleted logs.

The hunt also has to cover the rest of the network. Search for LDAP or LDAPS traffic from the NetScaler to domain controllers outside its normal authentication pattern, new logons from the service account it uses, and SMB connections from its internal address. Those were the network signs of the 2023 intrusions, and most teams already collect the logs needed to see them. Writing these queries is quick. Working through the hits they return is slow, since each one needs the provenance work described in the next section, and that backlog is why many hunting programs stall.

Investigating a Suspected NetScaler Web Shell

When the hunt turns up an unexplained file or a suspicious gap, run the same four questions used for any shell: provenance, request history, execution, and scope. The web shell detection guide linked above covers that sequence in full. On a NetScaler, each question draws on different evidence. Before those questions, deciding whether a new CVE even applies to an appliance named in an alert depends on the model and build information from the inventory step.

Provenance and request history come from the appliance HTTP access logs and from any reverse proxy or firewall logs in front of it. Those outside logs matter more here, because the attacker had no access to them. Execution evidence comes from the appliance shell logs, if they survived, and from outbound connections the device made. Scope determines how severe the incident is. If the service account on the appliance could have been decrypted, treat every system that account can reach as in scope, and follow its logons through your identity logs. This is ordinary alert triage discipline applied to a device that records less than a server does.

Some appliances will not resolve cleanly, because the evidence was deleted. The honest result is an inconclusive determination with a containment decision attached. Record which evidence was missing and why, so the finding holds up when it reaches incident response or an insurer.

Containment and Recovery After a NetScaler Compromise

The order of these steps matters, because patching first can destroy evidence. Preserve first: snapshots, logs, technical support bundles, and core dumps. Then isolate the appliance, upgrade to a fixed build, and rotate every credential it stored, starting with directory service accounts. Replace any appliance on 12.1 or 13.0, since no fix is coming. Citrix also recommends bringing in experienced forensic investigators, which fits a campaign built to leave little behind.

Network appliances have always been the first thing attackers try to breach, and AI has not changed that order. They are likely to be the first part of security where AI-driven vulnerability discovery outpaces the people responsible for them. That includes the vendors who fix these devices, the teams who patch them, and the investigators who respond when they are breached. Vendor detections, and even managed detection engineering programs, will struggle to keep pace with new appliance CVEs. A one-time sweep covers this campaign. Running the same file and log comparisons across edge devices on a schedule would surface the next campaign sooner, because those checks do not depend on a disclosure. That is the case for hunting with AI, where the queries run on a cadence and the hits get investigated rather than queued. If a retrospective NetScaler sweep is on your list, see how Prophet AI Threat Hunter runs hunts for emerging threats.