Citrix NetScaler Zero-Days: The Gateway Holds Your Service Accounts, So Rotate Them After You Patch

A NetScaler gateway is the device that sits between the internet and your directory, so it holds the credentials to reach it. On 27 September Citrix disclosed eight vulnerabilities in NetScaler ADC and NetScaler Gateway. Two of them, CVE-2026-88771 and CVE-2026-88772, are critical remote code execution flaws, and Citrix says it has observed both being exploited on unmitigated deployments. CISA added both to the Known Exploited Vulnerabilities catalog the same day.

Upgrading is the first step. The second is the one people skip: deciding which passwords, service accounts, certificates and keys that appliance knew about, and treating them as exposed if you cannot show it was never reached.

Updated 1 October. When this article was first published on 29 September, nobody had said what the attackers did after getting in. Google Threat Intelligence Group and Mandiant have since published that analysis, and it changes the order of operations: the web shells they found survive an upgrade, and the actor carried out credential theft and lateral movement in some environments. The new section below covers it, and the response order further down has been revised to match.

What is confirmed

Citrix's security bulletin CTX697096 lists eight CVEs. Two are marked as exploited: CVE-2026-88771, an improper input validation flaw that allows remote code execution, and CVE-2026-88772, a memory overflow that can lead to remote code execution or denial of service. Both are rated 9.5 on CVSS v4.0. The other six (request smuggling, a policy bypass, several memory overflows and predictable TCP sequence numbers) are not listed as exploited.

Secondary reporting adds two details that matter for scoping. CVE-2026-88771 affects default configurations and needs no unusual feature, while CVE-2026-88772 is described as requiring DTLS to be enabled. The bulletin lists no workaround for these two; the fix is an upgrade. The single workaround Citrix does publish is a TCP configuration change for CVE-2026-88778, which is not one of the exploited flaws.

Fixed builds are 14.1-73.37 and later, 13.1-64.23 and later, 14.1 FIPS 14.1-73.37 and later, and 13.1 FIPS/NDcPP 13.1-37.279 and later. Check your own build against the bulletin rather than against this summary.

CISA's alert of 27 September, revised on 28 September, says threat actors are exploiting the two flaws globally. Its actions are practical: check for indicators of compromise before patching, preserve forensic evidence before applying updates, and follow Citrix's compromise assessment guidance.

What is still not known

No public source we reviewed names an actor or a victim, and Google's analysis offers no attribution. Our first version noted that post-exploitation behaviour was unpublished, which Rapid7 said on 28 September and watchTowr's FAQ did not document. That gap has since been partly filled; the next section describes what is now documented. What remains open is how many organisations were reached, which credentials were taken in which environment, and whether the several actors involved are connected.

Scale is also unclear. Cybersecurity Dive relays a Shadowserver figure of more than 20,000 exposed instances, which counts exposure, not compromise, and the same report says confirmed cases are not widespread. Both statements can be true at once, and neither tells you whether your appliance was touched. Treat them as context, not as reassurance.

One gap shapes the rest of this article. Citrix's vulnerability bulletin contains no post-compromise guidance. That guidance lives in a separate document, the NetScaler compromise response guide (CTX694799), so a team that reads only the bulletin will patch and stop.

Update: what Google and Mandiant found after the compromise

On 30 September Google Threat Intelligence Group and Mandiant published an analysis of exploitation they responded to, which they date to at least early September, before Citrix's 27 September notification. Cybersecurity Dive also reports that GreyNoise saw malicious activity days before disclosure. Their account centres on CVE-2026-88772, the DTLS memory-corruption flaw, which they say gave root-level code execution without authentication. Citrix lists both flaws as exploited, so treat CVE-2026-88771 as in scope too. Google reports government, financial services, technology, education, and legal and professional services targets in North America and Europe, and names no actor.

What matters for secrets is what the actor did next:

Persistence that outlives the patch. A self-installing web shell edits the appliance's web server configuration so that files with non-script extensions are run as PHP, and Google describes a second variant disguised as image requests. It also describes setting the SUID bit on the system shell so that root access persists. Google and Mandiant warn that patching alone might not remove the infection, so check for compromise before you upgrade.
Two named tools. WHIPSHOT is a PHP web shell that hides Base64-encoded commands in HTTP headers. SLAPSHOT is a Python TCP tunneller that proxies traffic into the internal network.
Credential theft and lateral movement. Google says the actor moved into internal networks in some of the organisations it analysed. Its guidance treats the appliance's stored credentials as exposed: administrator accounts, LDAP, RADIUS and TACACS service accounts, SNMP community strings, API credentials, TLS certificates and private keys, SSH keys and session tokens.

To be precise about the evidence: Google documents the tooling and the credential theft and lateral movement, and its remediation lists name the material to treat as exposed. It does not publish a per-victim account of exactly which secrets were taken, so “rotate everything on the list” is a precaution proportionate to a root-level compromise, not a finding that each item was stolen from each appliance.

Google's checks are concrete. Look in the web server configuration for handler or alias directives that treat .deb, .sig or image requests as PHP, look for PHP code inside non-PHP files under the VPN scripts directory, check whether the system shell has the SUID bit, and look for the temporary files the tunneller creates. Google also provides detection rules and network indicators; use those rather than copying fragments from a summary. Take a snapshot, including memory on virtual appliances, before any reboot.

What Citrix says to do if you were compromised

The compromise response guide is where the secrets lesson comes from, and it is more specific than most vendor advice. As we read it, Citrix tells administrators to isolate the device, preserve evidence, and rebuild or replace the appliance rather than clean it in place. On the credential side it points to several classes of material:

Service account passwords the appliance uses, such as LDAP, RADIUS, OAuth, API keys and SNMP.
User accounts that authenticated through the compromised platform.
Certificates and their associated private keys, which are to be revoked and replaced, not merely renewed.
Local account passwords on the appliance.
Key encryption keys used on the device.

It also says to inspect connected systems, including authentication servers, sensitive systems and management hosts, and to keep watching for suspicious activity for an extended period afterwards. Restore only from a known-good backup that predates the compromise, and upgrade before restoring configuration. Both watchTowr and secondary reporting give the same advice in shorter form: rotate what is stored on or used through the appliance, and forward its logs to your SIEM.

The point of the list is that a gateway is a credential concentrator. To authenticate users it has to reach the directory, so a bind account lives in its configuration. To terminate TLS it has to hold private keys. To integrate with SAML or OAuth it holds shared secrets. An attacker with code execution on it does not need a second exploit to reach any of these, only the same access.

A response order that does not lose evidence

Find every NetScaler you run. Include the ones a previous team deployed, disaster-recovery pairs and lab copies exposed to the internet. Check each build against the bulletin.
Look before you patch. Following CISA, snapshot the instance, capture logs and support bundles, and note system time and NTP configuration first. Patching reboots the box and can overwrite what you would have wanted to read.
Upgrade on an emergency basis, and check again afterwards. Rapid7 recommends going outside the normal patch cycle. Citrix's bulletin lists no workaround for the exploited flaws, so the upgrade is the fix. If you truly cannot upgrade yet, Google lists stopgaps for the DTLS flaw only: disable DTLS if you do not use it, block inbound UDP 443 upstream, or restrict by source address. Those do not cover CVE-2026-88771. Because web shells survive patching, an upgraded appliance is not proof of a clean one.
Decide whether you can prove it was untouched. If you cannot, treat the appliance as compromised and follow the Citrix guide, including rebuilding rather than trusting the running system.
Revoke active sessions, then certificates and private keys, then rotate the rest. Google puts session revocation first. A private key that may have left the box stays useful to whoever holds it until the certificate is revoked, and a password rotation does nothing about that. Also review the systems behind the gateway, such as StoreFront and delivery controllers, because the actor moved laterally in some cases.
Rotate service accounts starting with the ones that can do the most. A directory bind account that can read many objects matters more than an SNMP community string, but do both. Give each service account only the access it needs while you are there.
Reset users who signed in through the gateway. That is potentially your whole remote workforce, so plan the communication before you announce it.
Write down what you could not establish. Public information about what attackers did is thin. Record unknowns as unknowns.

The delivery step everyone improvises

Rotating a service account means a new value must reach whoever configures the system that uses it: a directory team, a network team, a vendor. Under time pressure those values end up pasted into the incident chat, the ticket, or an email to a distribution list. Every one of those places keeps a copy for far longer than the incident.

Sort the work by who needs what. Most replacement values need to reach exactly one person once. Send those over a one-time channel, and send the notification that a value is waiting separately. Keep rotated values out of the incident record entirely, since that record is read by everyone who joins the bridge and again during the postmortem. Where the gateway is also how staff normally sign in to chat and ticketing, do not assume those tools are safe for this handover. A channel that works even if your sign-in path is under suspicion is worth agreeing before you need it.

Where Secretus fits, and where it does not

Secretus covers one narrow step: an authorised person handing a small, temporary text value to another authorised person over a one-time link that does not persist it the way chat and ticketing do. A break-glass administrator password for the rebuilt appliance is a reasonable example, and Team Split can require several holders to reconstruct a high-value text secret.

It is not a NetScaler tool, a certificate authority or a secrets manager. It cannot patch an appliance, revoke a certificate, rotate a directory account, push configuration to your fleet, or tell you whether these flaws were used against you. Do the patching, evidence collection, revocation and rotation with the right tools, and use a one-time channel for the moment a person has to hand another person a value.