Citrix NetScaler Zero-Day Exploitation: How Attackers Weaponized CVE-2026–88771 and CVE-2026–88772…

Introduction

On 24 September 2026, the threat intelligence company GreyNoise came across something unusual: a malicious actor was trying to exploit a Citrix NetScaler Gateway appliance, but there was no CVE that described the exploit. A public advisory had not been issued and no patch was available. GreyNoise classified the activity as malicious solely on the basis of behavioural analysis.

Three days later Citrix issued an official security advisory revealing two serious zero-day vulnerabilities in its NetScaler ADC and Gateway products. Both of these vulnerabilities had a CVSS score of 9.5 and both enabled remote code execution; they had also already been used in the wild.

It describes how attackers obtained root access to internet-facing authentication chokepoints in various government agencies, financial institutions and providers of critical infrastructure before the defenders realized that an attack was underway.

The Vulnerabilities

This campaign had two faults. Although they have the same severity rating they differ in their technical features and the requirements for exploiting them.

CVE-2026–88771 is a flaw due to improper input validation which enables a completely unauthenticated attacker to carry out arbitrary commands on affected NetScaler appliances. It does not require any special configuration and every default installation of NetScaler ADC and Gateway that is using an affected build is susceptible. This is the more serious of the two since the attack does not rely on any optional feature being enabled.

CVE-2026–88772 is a memory overflow flaw which can result in either remote code execution or a denial of service. It is necessary for DTLS to be enabled on the target appliance, whereas DTLS is enabled by default on VPN virtual servers, so in most cases NetScaler Gateway deployments that are used for remote access VPN termination satisfy the prerequisite without any intentional action by an administrator. Since UDP is the transport used when exploiting a memory corruption issue over DTLS, such an attack typically requires a higher level of attacker skill than exploiting a simple input validation error. This could be the reason why the number of instances of CVE-2026–88772 being exploited was lower than that of CVE-2026–88771, even though both have the same severity score.

The vulnerabilities also impact customer-managed NetScaler ADC and Gateway deployments; the vendor has patched Citrix-managed cloud services, and Secure Private Access Hybrid deployments that use NetScaler instances are likewise affected and need to be upgraded.

As more information came to light, it was noted that the range of affected versions includes builds 14.1–73.32 and 13.1–63.21. These are the same versions which had previously resolved the authentication bypass vulnerability, CVE-2026–19490, in August 2026. Even those organizations that had promptly applied the patch for that earlier flaw are still vulnerable to these new zero-days and need a separate update.

The Timeline of Exploitation

The timeline of the exploitation shows a major gap between the time when the attacks started and when the defenders got actionable intelligence.

On September 24, GreyNoise noticed an attempt to exploit a NetScaler Gateway. This activity came from the IP address 149.104.78.141. At that time there were no detection signatures specific to these CVEs since the CVEs had not yet been created. Nevertheless, the GreyNoise researchers regarded the activity as malicious on the basis of its behaviour.

The Google Threat Intelligence Group and Mandiant later stated that the exploitation of CVE-2026–88772 had been going on since at least early September, which means that the attackers were active weeks prior to the public disclosure of the vulnerability. The campaign probably started out as a targeted effort aimed at certain organisations before widening.

On September 26 citizens of Citrix NetScaler started to get urgent messages asking them to disconnect their servers because of suspected exploitation activity; some organisations were told by their security teams to turn off the affected devices completely rather than wait for patches to become available.

On the same day, September 27, Citrix published its official security bulletin, which listed a total of eight vulnerabilities, including the two zero-day flaws. Meanwhile, the Cybersecurity and Infrastructure Security Agency also released its advisory on that day and included CVE-2026–88771 and CVE-2026–88772 in its Known Exploited Vulnerabilities catalog, setting a remediation deadline of September 30, 2026, for federal agencies. This three-day period indicates the high level of urgency that CISA has attached to these vulnerabilities.

The patches were included in that bulletin; the fixed versions are 14.1–73.37 or later for the 14.1 branch, 13.1–64.23 or later for the 13.1 branch and the corresponding FIPS and NDcPP versions.

The Attack Surface

The extent of the exposure was considerable. The Shadowserver Foundation stated that over 20,000 NetScaler instances could be seen on the internet and were therefore possibly vulnerable. These devices are located at the network perimeter, accept VPN connections and handle authentication for all the systems behind them. If one NetScaler device is compromised, the attacker gains a direct route into the internal network.

Mandiant has confirmed that it has come across successful compromises in dozens of organisations in North America and Europe. The sectors that have been affected include government, financial services, education, telecommunications, and legal and professional services. No attribution has been made public and researchers have not found a clear pattern in the organisations that have been targeted according to industry or size. In the past, vulnerabilities in NetScaler have been exploited by both state-sponsored groups and by ransomware operators.

Post-Exploitation Activity

This campaign is what sets it apart from ordinary exploitation in the period after the attackers have obtained initial access. A toolkit designed for the purpose of ensuring continued access and for moving laterally on appliances, which generally do not have endpoint detection and response coverage, was documented by Mandiant and the Google Threat Intelligence Group.

Establishing Root Access

The act of exploiting the system allowed for execution of code at the root level. In order to make sure that the privileged access lasted beyond the first point of compromise, the attackers took swift action. GreyNoise noticed an attempt to alter '/bin/sh' by setting its setuid bit, so that commands executed through the shell in the future would also be carried out as root. This is a simple yet effective method of ensuring persistence since it survives rebooting and does not require any external command-and-control infrastructure.

Web Shell Deployment

The attackers used PHP web shells that were concealed within harmless files. GreyNoise noticed an attempt to install a password-protected web shell at the path /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver. In order to make the shell accessible via the web server, the attackers altered /etc/httpd.conf by adding Alias or AliasMatch entries which redirected requests for things that seemed to be static files such as CSS files to the hidden PHP script; for instance, a request for receiver.min.css would cause the web shell to be executed rather than the stylesheet being returned.

A analysis carried out by Google showed that a more advanced form of this method had been used. The attackers included handler directives in httpd.conf so that non-PHP file extensions such as .deb, .sig, .html, .rpm and .tgz would be treated as PHP scripts. They then placed files with these extensions into directories that were accessible via the web and set up alias rules which redirected public paths like /vpn/media/, /vpn/theme/ and /vpn/images/ to the directories holding the hidden shells.

Custom Malware: WHIPSHOT and SLAPSHOT

Mandiant has identified two tools which have not been seen before and show a deliberate effort to keep access to the compromised NetScaler appliances.

WHIPSHOT is a PHP web shell that has been developed with stealth in mind. Instead of reading the commands from the request body or the URL parameters, it retrieves them from within the HTTP headers. Before the commands are transmitted, they are encoded using Base64. After decoding, WHIPSHOT sends them via a local loopback connection to another process or service on the appliance. It always sends back an HTTP 404 Not Found response no matter what the actual result is, which makes it hard to detect by means of checking the web server logs or monitoring the responses.

SLAPSHOT is a TCP tunneling tool based on Python which functions as a bridge within the network. It takes its instructions from WHIPSHOT and forwards arbitrary TCP streams to the internal hosts, enabling attackers to move from the compromised appliance into the victim organisation's internal network.

SLAPSHOT uses a special binary protocol when communicating with the proxy; each message is made up of a 4-byte big-endian length prefix and then a JSON payload. The command actions that are supported are those which allow an outbound TCP socket to be opened to the target hosts, data to be written to open sessions, polling and reading of data from session sockets, the exchange of command-and-control data, the termination of sessions and the carrying out of health checks.

The tool attaches itself to a temporary port on the loopback interface and records the port number it is using in a file like /tmp/.uxdport. In order to make sure that only one instance is running at a time, it employs file locking. SLAPSHOT keeps an eye on connection activity and automatically closes the individual session sockets after 15 minutes of inactivity. When no active sessions or commands have been received within 10 minutes, the daemon deletes both its port and lock files before ending its process in order to reduce its memory usage and lower the risk of being detected.

The degree of operational security shows that the adversary in question is well-resourced and has a continuing interest in keeping access rather than just collecting data and then leaving.

Why Patching Alone Is Not Enough

Both Citrix and CISA have clearly warned organisations to look for signs of compromise before applying updates; the reason for this is that if an attacker had created a means of persistence by means of a web shell, by altering the configuration files or by using a tunneling tool before the patch was applied, then updating the firmware will not eliminate that access.

The advisory issued by CISA says that updates could lead to a loss of forensic visibility and advises organisations to save forensic evidence if a compromise is suspected. This involves taking memory dumps, configuration exports, session and authentication logs as well as support bundles before rebooting or rebuilding the appliance.

Citrix has released a scanner for detecting indicators of compromise and a file integrity monitor in order to check whether the NetScaler has been compromised; yet the company has admitted that the indicators of compromise that it has published might not succeed in identifying real compromises. Independent researchers have observed that web shell artifacts seem to be unique to each compromised device, making it difficult to carry out signature-based scans across a fleet of appliances. Also, the generic IoC checks available in NetScaler Console may fail to detect sophisticated attacks.

The difference between when a vulnerability is disclosed and when a reliable assessment of whether it has been exploited is determined is a continual issue in the case of zero-day vulnerabilities affecting edge appliances. Attackers who manage to gain a foothold before a patch is applied are still able to remain present after the patch has been applied. It is risky for organizations to apply a patch without first checking to see if a compromise has already taken place, as this could leave an existing access point untouched.

Remediation Guidance

The suggested sequence favors carrying out an investigation before applying the patch, which is the opposite of the normal priority in an emergency response and is based on the particular threat presented by pre-patch persistence.

The first step is to search for signs of compromise. Before carrying out any updates, check the /etc/httpd.conf file for unauthorized MIME types, script handler directives or web path aliasing. The presence of any AddHandler or AddType entry that assigns non-PHP file extensions to be executed as PHP scripts, or any AliasMatch directive that redirects public web paths to the appliance's script directories, is a clear sign of compromise.

Check the contents of the native client plug-in paths such as /var/netscaler/gui/vpn/scripts/linux/, /var/netscaler/gui/vpns/scripts/vista/ and /var/netscaler/gui/vpns/scripts/mac/. Valid files in these directories are compiled binaries or archives; any file that is identified as ASCII text or that contains PHP script markers is abnormal. Look for PHP code markers such as <?php, eval(, base64_decode( and shell_exec( in all web-accessible directories.

Check the permissions for the file /bin/sh and look for the .ctxs.receiver file as well as any corresponding Alias or AliasMatch entries. Also examine the web server's access and error logs for any syntax, parsing or execution errors that refer to disguised file extensions.

Two: preserve evidence. Before carrying out a reboot, a rebuild, or applying updates, it is necessary to obtain forensic artifacts. Configure exports, session and authentication logs, memory dumps if possible, and support bundles. Also check out external log sources such as those of the firewall, DNS and authentication systems for any indications of lateral movement from the appliance.

Third step: apply the patches. Upgrade to the versions of the software listed in Citrix's security bulletin. For the 14.1 branch, 14.1–73.37 or a later version is required. For the 13.1 branch, 13.1–64.23 or a later version is needed. FIPS builds must be upgraded to 14.1–73.37 FIPS or to 13.1–37.279 NDcPP or a later version. Since versions 12.1 and 13.0 are not included in the list of patched branches, there will be no fix available for those end-of-life versions. Organizations that are still using them should regard the migration to a supported branch as an emergency action.

In step four, if it is confirmed that a compromise has taken place, all the credentials, API keys, tokens and certificates linked to the appliance should be rotated. The connected authentication systems and management servers should be checked for any signs of lateral movement. It is advisable to consider carrying out a complete rebuild using only trusted software and known-good configurations. The system should then be monitored for at least 90 days after the remediation has been carried out.

Broader Implications

This fourth major NetScaler zero-day incident occurs since the initial CitrixBleed vulnerability was made public in 2023; the fact that serious pre-authentication remote code execution and memory-disclosure flaws have again appeared in the same product line indicates the presence of a fundamental risk rather than a number of separate incidents.

Equipment at the edge — such as Application Delivery Controllers, VPN gateways and firewalls — still attracts the attention of attackers since it is exposed to the internet, lies outside the scope of endpoint detection and response tools and often holds or handles credentials which can then be used to gain access to deeper parts of the network. According to Google's threat intelligence team, this trend has been observed among a variety of threat actors and they anticipate that edge devices will continue to be targeted because this method has been proven to be effective.

The campaign also points out the ongoing tension surrounding vulnerability disclosure. It was at least three weeks before Citrix made public the flaws that attackers had been active. During that period the defenders had no signatures, no patches and no public information regarding the threat. In some cases organisations were told to disconnect their internet-facing NetScaler appliances completely rather than wait for a fix. Such an approach is not a viable stance to take with regard to infrastructure which terminates remote access for thousands of employees.

Any organization that has a long-term dependence on NetScaler as a perimeter authentication bottleneck should see this incident as a reason to reduce the patch service level agreements for internet-facing appliances well below the normal enterprise patch cycles. It is no longer optional for organizations relying on these appliances to establish a dedicated vulnerability response capability that can address zero-day disclosures within hours rather than according to the usual change-management schedule.

Conclusion

The September 2026 Citrix NetScaler zero-day attack shows exactly what a sophisticated attack on an edge device looks like when hackers have weeks of unrestricted access before the vulnerability is made public. Because the attack involves unauthenticated remote code execution, malware that has been specially designed for stealth and to allow movement across the network, and a failure in detection that means persistence remains even after the patch is applied, it is not enough merely to apply the vendor's solution.

Any organization using NetScaler ADC or Gateway should carry the assumption that if an instance was facing the Internet and was running an affected version during September 2026, it may have been compromised until such time as an investigation has proven it otherwise. The investigation has to take place first, the patch can then be applied, and the monitoring must continue well after both of these have been done.