Citrix NetScaler zero-days: web shells and credential theft extend the response

Updated October 2: a more precise timeline and additional hunting leads

This update concerns the September vulnerabilities in CTX697096. The new October 2 SAML issue has separate coverage. The September fixed builds and hunting guidance below do not establish that the separate issue is resolved.

Reconnaissance and web-shell activity have different dates

Unit 42's September 30 update identifies requests consistent with version fingerprinting on August 21 and 22, followed by requests to .deb web-shell files from September 4. The August observations are reconnaissance, not proof of compromise on those dates. Where retained evidence permits, SecurityAlert recommends extending the timeline into August while recording reconnaissance, attempted exploitation and subsequent execution separately.

Additional artifacts to investigate

LevelBlue's September 30 investigation provides hunting leads from authentication events and analysis of referenced payloads:

• An unexpected sec_monitor account with superuser privileges.
• A .local_journal PHP web shell under /var/netscaler/logon/LogonPoint/.
• Unexpected replacement or execution of /var/python/bin/customsnmpd.
• Configuration staged in insight-new.js, xua.html or /tmp/update_result_3567cs.tgz.

The analyzed payload attempts to upload a configuration archive and then removes artifacts. That does not establish successful theft from every targeted appliance, and missing files cannot rule out earlier execution. Correlate these leads with account changes, filesystem evidence and outbound traffic. Do not classify an appliance from a filename alone.

A suspicious login is not an execution verdict

Unit 42 cautions that its CVE-2026-88771 log-poisoning query does not establish successful exploitation on patched devices. LevelBlue also warns that a failed authentication event does not prove the exploit failed. Follow the sequence into process, file and network evidence before deciding whether the activity was an attempt or a compromise. Neither a malicious username nor a reboot alone proves a patch bypass or identifies the new SAML issue.

Updated September 29: the investigation now reaches beyond the weekend

New incident-response reporting dates the campaign to at least early September, before the September 26 and 27 emergency. Investigators associate successful intrusions with CVE-2026-88772. This extends the period defenders should review; it does not establish the first attack against every appliance.

What the new intrusion evidence shows

Mandiant's investigation identifies WHIPSHOT, a PHP web shell, and SLAPSHOT, a Python tunneler. In at least one intrusion, the tunnel supported internal reconnaissance and credential theft. These are malware names, not attribution to a named actor.

The findings give responders specific places to inspect:

• Unauthorized PHP handlers and aliases in httpd.conf, including .deb or .sig files treated as scripts.
• An unexpected setuid bit on /bin/sh, and SLAPSHOT artifacts /tmp/.uxdport or /tmp/.uxdlock.
• Packet-engine failures near DTLS handshake errors, and unusual responses from apparently static web resources. A 404 response can conceal a working web shell; the status code alone cannot clear a request.

Separate sensor evidence records a September 24 CVE-2026-88771 exploitation attempt. The attacker tried to install .ctxs.receiver and disguise access behind CSS paths. That sensor did not suffer a successful foothold. It is evidence of attempted exploitation, not another confirmed victim or proof that both vulnerabilities must be chained.

Attacks were underway before the Sunday fixes

The NetScaler incident developed across the weekend of September 26 and 27, 2026. Public warnings on Saturday described exploitation discovered during forensic investigations, before CVE identifiers and fixed builds were available. On Sunday, Citrix published security bulletin CTX697096, confirming exploitation of two vulnerabilities and releasing updates.

The weekend was when the emergency became public, not the beginning of the campaign. Review retained evidence from before September 26 and document any gaps in retention. No reliable total victim count is established by the sources reviewed here.

The two exploited vulnerabilities are:

• CVE-2026-88771: improper input validation permits unauthenticated command execution. Vulnerable builds are affected in their default configuration; no optional feature needs to be enabled.
• CVE-2026-88772: a memory overflow can cause code execution or denial of service when DTLS is enabled. DTLS is enabled by default on VPN virtual servers unless explicitly disabled.

Both carry a CVSS 4.0 score of 9.5. Disabling DTLS does not address CVE-2026-88771. Likewise, an appliance used only for load balancing should not be dismissed as unaffected just because it does not provide a VPN login.

What to upgrade, and the 13.1 trap to check first

The bulletin lists these fixed releases, or later releases in the applicable branch:

• ADC and Gateway 14.1: 14.1-73.37.
• ADC and Gateway 13.1: 13.1-64.23, subject to the upgrade caveat below.
• ADC 14.1-FIPS: 14.1-73.37 FIPS.
• ADC 13.1-FIPS and 13.1-NDcPP: 13.1-37.279.

This applies to customer-managed appliances, including NetScaler instances used in Secure Private Access hybrid deployments. Citrix handles updates for its own managed cloud services. Patching an earlier NetScaler vulnerability does not establish that these fixes are installed.

Citrix's accompanying guidance identifies a specific operational problem with 13.1-64.23. Before choosing that build, run the read-only command show ns variable. If it lists configured variables, Citrix advises 13.1-64.24 to avoid a cyclic reboot during the upgrade. This is a configuration-dependent upgrade defect, not another security vulnerability.

Citrix also warns that Console may temporarily flag 13.1-64.23 incorrectly until its advisory logic updates. Verify the actual installed build and applicable configuration instead of treating that badge alone as proof that patching failed.

Citrix's September 29 update also identifies the 15.1 Technology Preview as vulnerable, with a fix still forthcoming at that update. It is intended for evaluation and testing, not production. Include exposed evaluation instances in the inventory and check current vendor guidance before deciding they are remediated.

The upgrade also enforces signed SAML assertions. Check that the identity provider signs them before the change window; an existing samlRejectUnsignedAssertion OFF setting no longer preserves the previous behavior.

The bulletin covers more than the two exploited flaws

CTX697096 addresses eight CVEs. The other six concern request smuggling, policy bypass, memory-related failures and predictable TCP sequence numbers. Citrix's exploitation statement names 88771 and 88772, not all eight.

CVE-2026-88778 needs a configuration change as well as attention to the release guidance. Review Enhanced ISN Generation, which increases variation in TCP initial sequence numbers. Citrix documents it as disabled by default. Check the current setting and use the documented configuration procedure where applicable; do not close the whole bulletin solely because firmware was upgraded.

For a high-availability deployment, the completion record should identify every node, its running build, relevant settings and validation results. A successful failover is useful operational evidence, but does not by itself prove that every member has been remediated.

Run the IOC assessment, and understand what it can tell you

Citrix is distributing generic indicators through NetScaler Console Security Advisory. Its release guidance specifies Console service or on-premises Console with Cloud Connect, starting at 14.1-73.36. The telemetry channel must be enabled, the IOC functionality must have been released, and the required terms must be accepted before a manual scan. Customers unable to use it should request the applicable indicators or assistance from Citrix Support.

The IOC documentation distinguishes a potential compromise from a scan that found no matching indicators. It also reports skipped, failed and still-running scans. Keep those outcomes separate: a scan that never completed is missing evidence.

A clean IOC result is not proof that the appliance was never compromised. Detection logic changes as indicators become available, and Citrix explicitly warns that it can miss actual compromises. Record the scan time, detection-logic revision and result for each appliance, retain the earlier results, and reassess when the logic changes.

Preserve evidence before changes erase it

Citrix's suspected-compromise procedure, CTX694799, puts evidence preservation first. It covers VPX snapshots, local and remote logs, system-clock information, support bundles and packet-engine memory collection. The documented packet-engine core collection causes a warm restart, so coordinate it with the incident-response and service teams.

Where compromise is suspected, the procedure calls for isolation, investigation of connected systems, credential and secret rotation, certificate/private-key revocation, and recovery onto a trusted installation. Restored configuration must come from a verified clean backup. Rebuilding without replacing exposed secrets can leave a separate route back into the environment.

SecurityAlert recommends comparing each appliance against its own approved configuration and change history. Preserve suspicious files and their metadata before cleanup; a filename, file extension or isolated error is an investigation lead, not a verdict. A list of known filenames will miss renamed payloads.

Confirm which logs actually reach the SIEM. Standard NetScaler audit forwarding does not automatically include the FreeBSD system log or all web-server logs. For suspected compromise, assess both HA nodes independently, contain configuration synchronization, and examine connected identity and application systems. Coordinate session termination and secret replacement with trusted recovery so replacement credentials are not exposed again.

SecurityAlert recommends assigning two accountable owners: one for reducing current exposure and restoring service, and one for establishing what happened before containment. Give both the same appliance inventory and timeline. Preserve original evidence, record collection times and document any gaps rather than letting an urgent upgrade silently become the end of the investigation.

The new CISA entries also require attention

The CISA Known Exploited Vulnerabilities catalog added both CVEs on September 27. Its entries list September 30, 2026 as the due date and explicitly flag forensic triage. Covered federal agencies should follow the applicable directive and implementation guidance; the catalog date is not a universal legal deadline for every organization.

For other organizations, the practical question remains immediate: which appliances were reachable before remediation, what evidence survives, and who is responsible for resolving suspicious findings? An exposure window should be documented even when no compromise has yet been established.

What we can conclude now

Exploitation is confirmed, fixed builds are available, and the new intrusion evidence makes a version-only response inadequate. Public reporting does not establish a particular threat actor, a total number of victims, or that the two bugs must be chained together. A patched appliance still needs a documented assessment of earlier exposure and any suspicious activity.

Close the response with evidence for three outcomes: every applicable appliance is remediated, suspicious activity has been investigated, and any credentials or trust relationships exposed by a compromise have been addressed. Those are separate decisions, and each needs an owner.