Two NetScaler Zero-Days, Two Different Problems: From Log Poisoning to a SAML Crash Loop

On 27 September there were just over 50,000 NetScaler appliances reachable from the internet. A lot of them were patched in the week that followed. On 3 October a second flaw landed on the ones that had been.

These two bugs are not versions of each other. One lets an unauthenticated stranger run commands on your appliance. The other only knocks it over. They have different causes, different things to hunt for, and different answers to the question everyone asked first: is there anything I can do short of upgrading?

Executive summary

Both are confirmed exploited in the wild. The second one is the reason an appliance patched in late September may still need work: the September build does not contain the October fix.

Attack overview

CVE-2026-88771 needs nothing from you. No optional feature, no unusual configuration, no credentials. If the appliance is reachable, it is in scope. That is why exploitation spread the way it did, from a handful of quiet intrusions in early September to broad scanning once the bulletin landed.

CVE-2026-88779 is narrower on paper. It needs SAML authentication configured, as either the service provider or the identity provider, alongside a Gateway or AAA virtual server. SAML is the protocol that hands sign-in off to Entra ID, Okta or ADFS, so in most estates that describes the main gateway rather than some corner of the config. Reported targeting has concentrated on government and finance.

Root cause

CVE-2026-88771 is a log poisoning chain, and it is simpler than it sounds. The appliance writes what you send it into its own log files. A maintenance script on the box, /netscaler/ns_monuploadd_err.pl, later reads those log files and hands parts of what it finds to a shell. So an attacker who can get text into a log can get a command onto the system. Nothing is checking that the log line is data rather than an instruction.

CVE-2026-88779 is a parser that does not count bytes. A SAML endpoint has to decode and parse XML from an unauthenticated stranger before it can check whether the signature is valid, because the signature is inside the XML. Send an oversized structure and the authentication daemon, nsaaad, writes past the end of its buffer and faults.

The CVSS vector for the second one is worth reading literally: confidentiality none, integrity none, availability high. It does not read your data. It stops your appliance.

Attack flow

The first chain runs in three moves. Base64-encoded commands go in the User-Agent header of an ordinary request, which lands in /var/log/httpaccess-vpn.log. A second step forces login failures carrying extra text, which lands in /var/log/ns.log dressed up as a pitboss PPE missed too many heartbeatsNSPPE; line. When the Perl script processes those entries, the command runs. Spaces are written as ${IFS} so the payload survives naive filtering.

What follows is standard appliance tradecraft. A web shell at /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver, reachable only when the CsrfToken cookie matches a fixed value and commands arrive URL-encoded in NSC_TASS. The Apache config is patched to add an alias and enable PHP. All of it sits in directories that survive a reboot, and a firmware upgrade.

The second chain is one move. Malformed SAML arrives, nsaaad crashes, the watchdog restarts it, and if the appliance is hit on a loop the restarts turn into reboots. Administrators saw this before anyone had a CVE number for it: appliances patched days earlier rebooting for no apparent reason. Some of the crafted usernames also carried shell commands pulling a payload from 213.209.159[.]55 and saving it as /v. Logs showed the attempt and the crash. watchTowr's analysis concluded the bug itself only crashes systems.

Impact

Code execution on a NetScaler is code execution where sessions are minted and secrets are stored. An attacker can take authenticated sessions without a password, read bound certificates and configuration, and move inward along paths the appliance is already trusted to use. Upgrading the firmware closes the hole; it does not remove a web shell written before the upgrade.

The crash bug costs you availability and nothing else, which sounds mild until you remember what the box does. If the gateway is where everyone signs in, a sustained crash loop locks out every remote user and every SAML-backed application behind it.

Indicators of compromise

CVE-2026-88771

• Web shell /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver, plus /var/vpn and the wider LogonPoint/custom directory
• pitboss heartbeat lines in ns.log that carry trailing text, and ${IFS} in place of spaces
• Base64 after INDEX: in User-Agent strings in httpaccess-vpn.log
• httpd.conf modified to add an alias or enable PHP; CsrfToken and NSC_TASS cookies in access logs
• Source addresses seen pre-disclosure: 77.83.199[.]39, 78.47.24[.]217, 139.180.152[.]138

CVE-2026-88779

• Unexplained nsaaad crashes, daemon restarts and reboots since late September
• Pitboss system failure messages correlated with SAML authentication traffic
• Payload host 213.209.159[.]55, file written as /v
• Oversized or malformed SAMLRequest values in authentication logs

Detection methods

Run these before you upgrade, not after. Some evidence only exists in memory.

# CVE-2026-88771: injection markers and log tampering
zgrep -E 'died NSPPE;|heartbeats.*;|\$\{?IFS|pitboss.*;' /var/log/ns.log* /var/log/messages*

# CVE-2026-88771: web shells in directories that survive upgrades
grep -rlE '<\?php|passthru|NSC_TASS' /var/netscaler/logon/LogonPoint/custom /var/vpn

# CVE-2026-88779: am I in scope at all
grep -E "add authentication saml(Action|IdPProfile)" /nsconfig/ns.conf

From the CLI, show system user should list only accounts you created, and show ns tcpparam should show Enhanced ISN Generation enabled, which is the configuration half of the fix for CVE-2026-88778. Citrix ships an indicator-of-compromise scan through NetScaler Console; run it against every appliance and expect some false positives.

Mitigation and remediation

CVE-2026-88771 has no workaround. Citrix published none, and there is no feature to disable because the vulnerable path is in the default configuration. Upgrading is the only fix.

CVE-2026-88779 does have interim options, which is the practical difference between the two. If you are stuck on a September build between 14.1-73.37 and 73.40, or 13.1-64.23 and 64.27, Citrix has pushed signatures usable through the Global Deny List feature in NetScaler Console. They need virtual patching enabled and a managed, non-FIPS appliance, and show appfw signatures will tell you whether the signatures are present. The second option is a responder policy that drops oversized or malformed SAML, bound with -type AAA_REQUEST and filtering SAMLRequest values beyond roughly 8,000 bytes, alongside web application firewall signatures at version 24 or later. Both are bridges, not destinations.

One upgrade note that has bitten people: samlRejectUnsignedAssertion OFF is no longer supported and the upgrade forces it on. If your identity provider does not sign assertions, sign-in breaks the moment the new build boots. Check that before the change window, not during it.

Lessons learned

These two bugs sit in the same appliance for the same underlying reason. An edge device has to read untrusted input in several formats at once: HTTP headers, its own log files, XML from strangers. Every one of those is a parser, and a parser that trusts its input or forgets to count bytes is the whole vulnerability.

The practical lesson is narrower than the architectural one. Patching is an event with a date, and the attacker's calendar does not match yours. Know which build each appliance is on, know whether SAML is configured on it, and treat "we patched" as the start of the work rather than the end of it.