top of page

Patched Your NetScaler Last Week? Patch It Again. CVE-2026-88779 Is the Fifth NetScaler Bug on CISA's Exploited List in 39 Days.

Writer: Patrick Duggan
Patrick Duggan
44 minutes ago
7 min read

If you run a NetScaler with SAML sign-in and you patched it last week for the September zero-days, you are not done. On Friday, October 2, attackers started crashing appliances that already had those patches. Citrix shipped a fix for the new bug on Saturday night, US time. CISA added it to its Known Exploited Vulnerabilities catalog on Sunday and gave federal agencies until Wednesday, October 7. Same appliance, same month, second upgrade.


CVE-2026-88779 is the sixth NetScaler entry in CISA's catalog this year and the fifth since August 26. That is five in 39 days. Last Tuesday we wrote that four in 32 days was not bad luck. One week later the count went up again, and this one landed on boxes that had done everything right.



What happened


Citrix bulletin CTX697174, published late on October 3 US time, describes a memory overflow in how NetScaler ADC and NetScaler Gateway handle SAML. It scores 8.7 on CVSS version 4. Citrix calls it a denial of service. Its exploitation statement: "Citrix has observed targeted attacks on unmitigated NetScaler deployments which can lead to Denial of Service."


You are affected only if your configuration contains add authentication samlAction (NetScaler as a SAML service provider) or add authentication samlIdPProfile (NetScaler as a SAML identity provider). If neither line is in your ns.conf, this bug does not apply to you. The September bugs still might.


Fixed builds: 14.1-73.41, 13.1-64.28, 14.1-73.41 FIPS and 13.1-37.282 FIPS/NDcPP. Versions 12.1 and 13.0 are end of life and get no fix. If you upgraded to 14.1-73.37 for the September bulletin (CTX697096), you are still vulnerable to this one.


The crash path, as administrators describe it: crafted SAML requests kill the authentication daemon, nsaaad. After enough crashes the appliance restarts, then its high-availability partner does too. Some shops powered their appliances down to stop the restarts. On a remote-access gateway, that means nobody can work from home until it is fixed.





Why "denial of service" undersells it


Citrix's label is DoS. The evidence from the field is messier, and you should plan for the worse reading.


Administrators found authentication requests with shell commands hidden in the username field. Kevin Beaumont reported that the attack script tried to install persistent web shells, and that one of his honeypots, already patched for the September bulletin, downloaded and ran a malware binary. One administrator quoted in the coverage said there was no definitive proof the script ran on production devices. Citrix has not said it allows code execution. CISA's catalog entry also says denial of service, but it marks the entry as requiring forensic triage, which means federal agencies have to look for signs of compromise, not just patch.


There is also an earlier sighting. The security firm Lupovis logged a long, padded SAML request with the user agent probe/1 on September 17, more than two weeks before the crashes began and before anyone had a name for this bug. That is a lead worth hunting on, not proof the campaign started then.


So the honest framing is this. The vendor confirms crashes. Researchers report commands in the requests and at least one patched honeypot that ran a payload. Treat any SAML appliance that was reachable between October 2 and your upgrade as possibly compromised until you have looked.



What to do today, if you are a small shop


Step one: check whether SAML is configured. Search your ns.conf for samlAction and samlIdPProfile. No match, no exposure to this bug.


Step two: upgrade to 14.1-73.41 or 13.1-64.28. If you cannot do it today, Citrix offers Global Deny List signatures through NetScaler Console, or a responder policy from Citrix Support. The policy has to be bound with type AAA_REQUEST on every Gateway and AAA virtual server. A policy bound with type REQUEST never sees the sign-in traffic, and a global binding does not count.


Step three: hunt. Look for nsaaad core files and crash lines in your logs. Look for authentication log entries where the username contains shell syntax. Look for very long requests to /saml/login or /cgi/samlauth, and for the user agent probe/1. Look in LogonPoint/custom for files you did not put there, including randomly named .receiver files. Thomas Poppelgaard's free, read-only checker for both bulletins does all of this and tags each finding as before or after your fix date. It is on GitHub as netscaler-ctx697096-checker.


Step four: kill every session after you patch. This is the lesson from CitrixBleed in 2023. Organizations patched, and attackers kept walking in, because the session tokens they had already stolen still worked. Patching closes the bug. It does not log anyone out. After the upgrade, end all active and persistent sessions: kill aaa session -all, kill icaconnection -all, kill rdp connection -all, kill pcoipConnection -all, and clear lb persistentSessions. Then rotate any credential that crossed the appliance while it was exposed. A gateway sees your users' passwords and tokens in the clear. That is why attackers want it.



The patch window, measured


Here is the timing problem in one line. The attacks started October 2. The fix shipped October 3. CISA's deadline is October 7.


That means the attackers had a full day on patched appliances before any fix existed, and possibly two weeks of probing before that. Your window does not start when you hear about the bug. It starts when the fix is published, and the attacker is already inside it. For a shop with one network admin, a Saturday-night fix and a Sunday KEV listing means a weekend change window or a Monday spent exposed.



What our data shows, and what it cannot show


Our edge honeypots are fake endpoints on our Cloudflare workers. They pretend to be leaked config files, WordPress logins and admin panels, and they record whoever shows up. As of this morning they hold 133,834 records, 11,306 of them since our September 29 post.


We searched every record for NetScaler-shaped paths again. Since September 29 there are exactly two: /vpn/index.html and /logon/LogonPoint/index.html, one second apart, from a single US mobile-carrier address, a few hours after our last post named those exact paths. That is a reader checking our work, not an attacker. NetScaler exploitation attempts against our sensors: zero.


That zero means nothing about the threat. It reflects our sensors. Our honeypots do not look like a NetScaler, so nobody who is hunting NetScalers has a reason to touch them. Last week we proposed adding NetScaler-shaped decoys. As of today, October 5, that has not shipped. When it ships we will say so with a date.



What we put in the feed, and what we did not


On September 29 we wrote that nobody had published indicators for the September campaign. That changed within days. A community compilation, maintained in Poppelgaard's checker and on PitScaler.com, now lists 98 addresses and dozens of file hashes, from Mandiant, Unit 42, Arctic Wolf, Beazley Security, LevelBlue, TENEX, Rapid7, Gotham Technology Group and others.


Today we ingested 21 of them under the source manual-batch-netscaler-cve-2026-88779. Fifteen are SHA-256 hashes from the October 2 SAML attack set: the dropper and the downloaded script, attack kit versions, tunnel and implant binaries. Six are IP addresses: the dropper's exfiltration host, two addresses Mandiant named for the September campaign, and three from Beazley Security's second-wave advisory. Every record cites who found it. None of it is our discovery. At publication, 20 of the 21 were confirmed by reading them back from the index. The last address was still queued behind other writes, and we will confirm it the same way.


We set the confidence at 70 for the hashes and 75 for the addresses. We took the vendor-attributed IPs second-hand from the compilation rather than from each vendor's own page, so they sit below our own edge shield's 80 blocking floor. They still ship in the default CSVs, because those default to a confidence of 30. If you pull with min_confidence=80 they will not be in your set. That is your setting to choose, not ours.


Two of the 21 were already in public feeds we carry: the dropper hash in MalwareBazaar on October 3, and the exfiltration host in tweetfeed on October 2. A September web shell hash from the same compilation was in ThreatFox on October 3. The exfiltration host was also in OTX back in February, which says the infrastructure is older than this campaign. That is corroboration from other people's feeds. It is not a lead, and we are not claiming one.


The other roughly 90 addresses from the September campaign are not in our feed yet. That is a gap, it is ours, and we are naming it rather than letting a partial ingest look complete.



This is not just a Citrix problem


Of the 250 entries CISA has added to its exploited list in 2026, 45 come from the vendors whose boxes sit at the network edge: Fortinet 8, Citrix 6, Ivanti 5, SonicWall 4, F5 2, Palo Alto Networks 2, and Cisco 18 across its product lines. Fortinet's most recent was added October 1.


The same three lessons apply to every one of them. First, the device sits outside your endpoint detection, so nobody is watching it the way they watch a laptop. Second, it handles credentials in the clear, so getting in once pays off for a long time. Third, patched is not the same as clean. In 2025 Fortinet disclosed that attackers had kept read-only access to patched FortiGate devices through a symbolic link planted before the patch. Ivanti Connect Secure customers learned in 2024 that the vendor's own integrity checker could miss a compromise. The NetScaler honeypot that was patched and still ran a payload this week is the same story with a different logo.


For any edge appliance, the sequence is the same: patch, hunt, kill sessions, rotate credentials. If you skip the last three steps, you have only done the part the attacker was expecting.



The opinion


Five exploited bugs in 39 days, the last one landing on appliances that had already been patched, is someone with a budget working methodically through one product. A small organization cannot out-patch that. What it can do is shrink what the appliance is trusted with: take SAML off the internet-facing gateway if you do not need it there, put the admin interface on a separate network, and keep session lifetimes short so a stolen token goes stale quickly. Then start the budget conversation about whether a NetScaler should still be your front door in 2027. We hold that view with about 90 percent confidence. The other 10 percent is that Citrix's fix-in-a-day response this time is a sign the hardening is catching up. One fast patch is not a trend yet.


Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.




Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.



Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=patched-your-netscaler-last-week-patch-it-again-cve-2026-88779-is-the-fifth-netscaler-bug-on-cisa



bottom of page