Citrix NetScaler zero-days: what happened and what to do now
Two critical flaws in Citrix NetScaler ADC and NetScaler Gateway were being exploited in the wild before the public heard about them. Over a weekend at the end of September, administrators on Reddit reported that their IT suppliers and managed detection providers had told them to take appliances offline. By the time Citrix published patches, attackers already had root on devices in several sectors.
This post is a snapshot written on October 8, 2026, from public reporting by BleepingComputer, SecurityWeek, and Bitsight, with Mandiant and GreyNoise findings as quoted by those outlets. Details change quickly in incidents like this. Check Citrix's own advisory and CISA's catalog entry before you act on anything here, and treat my checklist as a starting point for your own plan.
The two vulnerabilities
Citrix tracks them as CVE-2026-88771 and CVE-2026-88772. Both carry a CVSS score of 9.5. Some researchers have taken to calling the pair "PitScaler," though that's a nickname and not an official name.
CVE-2026-88771 is an unauthenticated remote code execution bug. According to SecurityWeek's reporting, it affects NetScaler ADC and Gateway deployments in their default configuration. Unauthenticated means the attacker needs no account, no stolen password, nothing except network access to the appliance.
CVE-2026-88772 is a memory overflow that can lead to remote code execution or a denial of service, and it matters when DTLS is enabled. DTLS is the datagram flavor of TLS, used for UDP-based VPN traffic, and reporting says it's turned on by default for VPN virtual servers. That detail makes the bug reachable on a lot of gateways that were set up with defaults.
Citrix's advisory covered more than these two. SecurityWeek says the company acknowledged eight vulnerabilities in total across these products, including request smuggling, denial of service, and security bypass issues. If you only patch because you saw the headline CVEs, you still end up on the fixed release, but read the whole advisory so you know what else you're closing.
How the attacks worked
Mandiant's description, as quoted by BleepingComputer, says attackers sent "specially malformed or fragmented record headers" that corrupted heap memory on the FreeBSD system underneath the appliance. In plain terms, the attacker feeds the DTLS handler something it can't parse correctly, memory gets overwritten, and the attacker steers that corruption into running their own code with root privileges.
Once inside, the activity looks like a standard edge-device intrusion, only fast. Attackers dropped password-protected PHP web shells disguised as CSS files in hidden directories. They edited httpd.conf so that files with non-executable extensions would be handled as PHP, which is how a file named like a stylesheet ends up running code. Mandiant named two malware families. WHIPSHOT is a PHP-based web shell that acts as an HTTP proxy and was stored in VPN script directories. SLAPSHOT is a Python TCP tunneling tool that lets attackers reach into the internal network and harvest credentials.
Think about what a NetScaler Gateway sees. It terminates VPN sessions, so it handles usernames and often passwords or session tokens in the clear at the moment they pass through. A root shell on that box isn't just access to one machine. It's a position from which an attacker can watch people log in to everything behind it.
The timeline, as far as it's known
This is the part where I'd be careful, because outlets don't agree on every date and I'm not going to pretend they do.
Mandiant says exploitation began at least as early as September, with victims in North America and Europe across government, financial services, education, legal, and professional services. GreyNoise reported seeing exploitation attempts about three days before the public disclosure, with September 24 mentioned as the date of the first sighting. Over the weekend before Citrix's announcement, administrators said they were told to shut appliances down immediately, and SecurityWeek traced that warning to a private notice from the Dutch National Cyber Security Centre (NCSC-NL), shared under TLP:AMBER, saying exploitation had been found at several customers worldwide.
Then came the patches and the confirmation of active exploitation. CISA added both CVEs to its Known Exploited Vulnerabilities catalog and gave federal civilian agencies until September 30 to secure their appliances.
The gap between the first exploitation and the first public word is the whole story. For somewhere around three weeks, anyone who ran an exposed NetScaler had no patch to install and no warning to heed. That's what zero-day means in practice, and it's why the response can't start with "wait for the patch."
Why edge devices keep getting hit
VPN gateways, load balancers, firewalls, and remote access appliances share three traits that attackers love. They sit on the internet by design, so there's no firewall in front of them to bypass. They run privileged, they handle credentials, and they often see all traffic that matters. And they're black boxes: many organizations can't install their own endpoint detection on them, can't easily inspect the filesystem, and only learn something is wrong when a vendor or a government agency calls.
That last point deserves some attention. If you can't see inside a device, you can't tell a clean one from a compromised one by looking at it. You have to rely on the vendor's integrity tooling, on logs sent somewhere the device can't tamper with them, and on network behavior. Plenty of defenders haven't built any of those for their appliances.
What to do today
If you run NetScaler, the order of operations matters, and it differs from the usual "patch first" reflex.
Start by finding every instance, including the forgotten ones. Test environments, disaster recovery sites, and an appliance an acquired company left behind all count. Anything reachable from the internet and running an affected build is in scope.
Then check for compromise before you patch. CISA recommended exactly this, and Citrix advised reviewing indicators first. Patching and rebooting can destroy volatile evidence and overwrite files you'd want to examine. Take a snapshot or a forensic image if your platform allows it, and then patch.
The indicators Mandiant listed, as reported by BleepingComputer, give you somewhere concrete to look:
- Unexpected PHP handlers in
httpd.conf, meaning extension mappings that make non-script files run as code. - Strange
.debor.sigfiles that contain PHP. - Unexpected crashes of the NSPPE process, which can show up when exploitation attempts fail.
- Changed permissions on
/bin/sh, such as a setuid root bit that wasn't there before.
If you find any of those, treat the appliance and everything it touched as compromised. That means rotating every credential that passed through it, invalidating VPN sessions and tokens, and hunting for the attacker's next hop inside the network, because SLAPSHOT-style tunnels exist to make that hop easy.
If you can't patch right away, the reported mitigation is to disable DTLS where your setup allows it and to block inbound UDP/443 upstream of the appliance. That addresses the DTLS-related bug only, and it may break UDP-based VPN clients, so test it. It's a way to buy a few hours, not a substitute for the fix.
After patching, don't stop at the green checkmark. Confirm the running version, re-check the indicators on the patched box (a patch doesn't remove an attacker who's already in), and review authentication logs for logins from unusual places during the window when you were exposed.
Explaining this to people who don't read advisories
If you're the person who has to brief a manager, a client, or a board, the technical detail won't help. A short version that stays honest goes something like this.
A device that sits at the front door of our network had a flaw that let strangers run commands on it without logging in. Criminals, and possibly state-backed groups, were using the flaw for weeks before the manufacturer knew. A fix now exists. We're checking whether anyone got in before we installed it, because installing the fix doesn't evict someone who's already inside. If we find signs of a break-in, we'll change the passwords of everyone who connected through the device and look for where the intruder went next.
Then give the decisions you need from them: permission for a short outage to patch, budget for outside forensic help if indicators turn up, and a named person who can approve taking remote access offline if the situation gets worse. Managers don't need to understand heap corruption. They need to understand that the cost of waiting grows every day and that you need authority to act fast.
Questions to ask your vendor or managed provider
Plenty of organizations don't run their own NetScalers. A supplier or MSP does it for them, and the weekend instructions to shut things off came through those channels. If that's your situation, some questions are worth asking in writing.
Did you identify every appliance of ours that runs the affected software, and can you send the list? Did you check for the published indicators of compromise before patching, and what did you find? When was each device patched, and which version is it running now? What credentials passed through these devices, and have those been rotated? Where are the appliance logs stored, and for how long?
The answers tell you a lot about the quality of the service. A provider who can respond with specifics within a day is doing the job. One who replies with reassurance and no detail may not have looked.
A note for small shops
Most of the advice above assumes a security team. Say you're a two-person IT department, or a developer who also administers the company's infrastructure. You can still do the essentials. Make a list of what's exposed to the internet (your router's admin page, VPN, mail gateway, and any appliance with a web interface). Subscribe to the vendor's security notifications for each, since the email you'll actually read is the one that arrives when something breaks. Keep configuration backups off the device. And ask yourself honestly whether you need a self-managed appliance at all. A hosted remote-access service moves some of this patching burden to a vendor who does it all day, though that trades one risk for another, and you should read the provider's security record before you decide.
Habits that make the next one less painful
A zero-day on an edge device will happen again, probably with a different vendor's logo. A few things shorten the response next time.
Keep an accurate inventory of internet-facing assets, with owners and versions. When the advisory lands, you want to answer "do we run this?" in minutes.
Send appliance logs to a collector off the device. Logs stored only on the box are the first thing a competent attacker edits.
Limit what a compromised gateway can reach. If a VPN appliance can talk to every server on the network, then root on the appliance is root everywhere. Segmentation turns a breach into a smaller one.
Plan the "pull the plug" decision in advance. At the end of September some teams had to decide in hours whether to take their remote access offline. The ones with a written plan, a backup access path, and someone with authority to say yes had a calmer weekend than the ones debating it in chat.
Subscribe to your national CERT and to CISA's alerts. The warning that mattered in this case traveled through a government channel before it reached public advisories.
What's still unclear
As of this writing, I don't know how many appliances were compromised, who's behind the attacks, or whether other flaws from the same advisory are being used in combination. Reporting so far describes the exploitation as widespread and global, and I'd expect the numbers to grow as more victims find out. If you read something that contradicts a detail here, believe the vendor advisory and the CISA entry over my summary.
The practical advice isn't complicated: find your appliances, check them before you patch, patch, rotate what they saw, and build the inventory and logging so the next incident takes a day and not a month.