Two Citrix NetScaler Zero-Days Were Probed for Five Weeks Before Anyone Got a Patch, and Updating Does Not Remove the Web Shell

Citrix has confirmed that two critical NetScaler ADC and Gateway flaws, CVE-2026-88771 and CVE-2026-88772, were exploited as zero-days before fixes were available. Both carry a CVSS v4.0 score of 9.5 and allow unauthenticated remote code execution. Citrix disclosed them on 27 September in security bulletin CTX697096, alongside six other fixes, and CISA added both to its Known Exploited Vulnerabilities catalog the same day with a 30 September deadline for federal agencies.

This is a different story from the NetScaler bug we covered in August, where a flaw was under-rated at disclosure. Here the interesting part is the timeline.

What the two flaws are

• CVE-2026-88771 is an improper input validation bug that lets an unauthenticated attacker run commands. Citrix says it affects default configurations of NetScaler ADC and Gateway.
• CVE-2026-88772 is a memory overflow reachable when DTLS is enabled, which Citrix says is the default on VPN virtual servers. It can lead to code execution or a crash.

Fixed builds are 14.1-73.37 and 13.1-64.23, with FIPS and NDcPP builds listed in the bulletin. NetScaler 12.1 and 13.0 are end of life and get no fix, so Citrix says to migrate them.

The five-week gap

Palo Alto Networks Unit 42 reconstructed activity from its telemetry:

• 21 to 22 August: hosts requested files consistent with version fingerprinting, and sent the same requests to more than 100 other systems.
• 4 to 15 September: several virtual private servers requested .deb packages from the appliance's /vpn/scripts/linux/ folder, a directory that normally serves client installers and was also used to host web shells.
• 21 September: a three-stage command injection against a US-based target dropped a PHP web shell.
• 27 September: public disclosure. Unit 42 counted about 50,000 potentially exposed instances through its Xpanse telemetry. Shadowserver's separate count of exposed NetScaler fingerprints was just over 23,000, so treat both as rough.

Unit 42 separates pre- and post-disclosure activity, and cautions that post-disclosure scanners and researchers may not match the original indicators.

How the attack worked

The command injection abuses log poisoning in three steps. A base64 dropper arrives in the User-Agent header and is written to /var/log/httpaccess-vpn.log. A crafted login request writes a marker string, "pitboss," into /var/log/ns.log. A vulnerable script, /netscaler/ns_monuploadd_err.pl, then processes the poisoned entries and executes what it finds.

The payload sets SUID/SGID bits on /bin/sh, drops a hidden PHP shell named .ctxs.receiver, and edits /etc/httpd.conf to serve it under paths that look like CSS files. It reloads Apache with a SIGHUP, so no restart appears in the logs. The DTLS route drops a different shell packaged as nsg64.deb, with RC4-encrypted command-and-control traffic.

Patching is not the finish line

Both Citrix and CISA say the same thing: check for compromise first. Citrix's own statement is that its indicators "might be of limited forensic value." Unit 42's guidance, which we would follow:

1. Confirm exposure against the preconditions in CTX697096.
2. Preserve evidence before patching: a VPX snapshot, remote syslog and NetScaler Console logs, a support bundle, and a packet engine core dump.
3. Hunt for pitboss in ns.log, anomalous User-Agent values in httpaccess-vpn.log, nsg64.deb and nsgclient18.deb under /vpn/scripts/linux/, and /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver.
4. Patch, then assume any session or credential that passed through the appliance during September needs review.

Unit 42 notes that a hunting query for the marker does not prove exploitation on a patched device. Absence of a hit on a patched box is weak evidence for the weeks before the patch.

The data your responders are about to handle

An incident like this produces exactly the material people are tempted to paste into an AI assistant: raw appliance logs with internal IPs and usernames, httpd.conf diffs, shell scripts they cannot read quickly, and ticket text with customer names. With a three-day federal deadline and a night of triage ahead, a consumer chatbot is the fastest tool in reach.

That is a data-handling decision made under pressure, and it is rarely logged. Appliance logs routinely contain session identifiers, usernames and internal topology. An engineer who pastes a log excerpt to ask "what does this script do" has sent that material to a third party.

Where Obiguard fits: a sanctioned place to ask

Obichat is a governed AI chat workspace built on LibreChat. Security teams get the same speed of "explain this payload" or "summarize these 4,000 log lines" while the conversation stays inside a workspace the organisation controls, connected to the models it has approved, or deployed privately in its own cloud tenant. Each workspace produces an exportable activity log, so afterwards you can answer what was shared during the incident without relying on memory.

It does not patch a NetScaler, find a web shell, or replace forensics. What it removes is one avoidable second incident: sensitive evidence from the first one leaving the building through a chat window.

The question to take away

When your team investigates the next edge-device compromise at 2 a.m., where will the logs go when someone asks an AI what they mean?

See how Obichat works or talk to us about giving your responders a governed place to work.