Containment and Remediation Strategies
Organizations that have not yet applied the latest security updates should immediately assess their exposure and risk. Broad internet isolation or strict IP allow-listing on NetScaler Gateways can create significant disruption for organizations supporting remote workforces through Citrix Virtual Apps and Desktops (formerly XenApp and XenDesktop). For this reason, Mandiant recommends a targeted, phased approach that prioritizes patching while applying appropriate containment and compensating controls based on the organization’s risk profile.
Immediate Mitigation
Organizations should evaluate the following options based on their risk tolerance, evidence of compromise, and operational requirements.
Option 1 — Apply the Latest Citrix Build (Mandiant Recommended)
Implement the latest Citrix build that addresses the in-scope vulnerabilities. Organizations should upgrade to the following fixed releases (or later) depending on their current deployment track:
Note: Specific patched builds are also available for 14.1-FIPS and 13.1-FIPS/NDcPP deployments
Organizations that cannot locate specific builds in the Citrix customer downloads portal should open a Severity 1 support case with Citrix to confirm and obtain the latest build containing the required fixes.
Option 2 — Isolate Compromised or Suspected Appliances
For confirmed or suspected compromise, isolate affected NetScaler appliances from the network. This option can introduce significant business disruption, particularly when the appliance provides remote access or other critical services.
If the hunting strategies described above identify indicators of compromise, Mandiant recommends implementing the following containment actions:
-
Isolate the node. Immediately remove the confirmed or suspected appliance from the network.
-
Halt HA synchronization. For NetScalers deployed in High Availability (HA) pairs, assess both nodes independently. Disable configuration synchronization until both nodes have been validated to prevent a compromised node from replicating malicious changes, such as modified httpd.conf files, to the standby node.
-
Restrict egress. Block observed threat actor infrastructure and restrict outbound internet connectivity from the appliance. In particular, prevent arbitrary outbound TCP/UDP traffic and block outbound SMTP over TCP/25 unless explicitly required.
-
Review hypervisor network isolation. If the NetScaler runs as a VPX appliance in a virtualized environment, review vSphere vSwitch and Port Group configurations. Confirm that the NetScaler VPX is appropriately segmented and does not share a Layer 2 network with hypervisor management interfaces, such as ESXi vmk0 or vCenter, or other highly sensitive infrastructure tiers. Refer to the Mandiant hardening guidance for vSphere for additional recommendations.
Option 3 — Apply Targeted Compensating Controls
If immediate patching is not possible, organizations should implement targeted controls to reduce the exposed attack surface until the affected appliances can be updated. The DTLS and UDP/443 controls below are specific to CVE-2026-88772 and should not be relied on to mitigate CVE-2026-88771. Installing a fixed NetScaler build remains required to address both vulnerabilities.
Part A — Network Restrictions
-
Disable DTLS where operationally feasible. If patching is delayed, disable DTLS on internet-facing NetScaler Gateway virtual servers where it is not required. In this campaign, the exploit payload is delivered over UDP/443 using Datagram Transport Layer Security (DTLS).
-
Restrict inbound UDP/443 upstream. Block inbound UDP/443 to affected appliances unless DTLS is explicitly required. This control should be implemented on an upstream perimeter firewall or edge router. Relying exclusively on local NetScaler ACLs allows traffic to reach the vulnerable packet-processing engine (nsppe) before it is dropped.
-
Implement upstream IP allow-listing where feasible. Organizations using NetScaler strictly for load balancing, or operating Access Gateways that serve a predictable set of external source IP addresses, should consider upstream network ACLs that drop unauthorized traffic before it reaches the appliance.
For public-facing VPNs supporting large remote workforces, this approach may not be practical because dynamic residential IP addresses can create significant administrative and operational overhead.
-
Preserve virtual appliance state for forensic analysis. For NetScalers deployed as virtual appliances, including NetScaler VPX on VMware vSphere or other hypervisors, take a full VM snapshot with memory state included before rebooting whenever operationally possible.
Part B — Credential Rotation and Session Termination
Organizations should operate under the assumption that credentials stored on a compromised appliance may have been exposed. Credential rotation and session termination should be coordinated across the appliance and connected systems.
-
Revoke active sessions. Invalidate existing administrative, Gateway, and VPN sessions to remove potentially compromised session tokens. For organizations using the appliance as a gateway for Citrix Virtual Apps and Desktops, this should include terminating active ICA/HDX sessions where appropriate. Refer to Citrix CTX584227 for additional guidance.
-
Rotate appliance secrets. Rotate NetScaler administrator credentials, local appliance accounts, Secure Shell (SSH) keys, TLS certificates, and associated private keys.
-
Rotate integration credentials. Rotate LDAP bind and service accounts, RADIUS shared secrets, TACACS credentials, SNMP community strings, and NITRO/application programming interface (API) credentials.
-
Audit downstream Citrix infrastructure. Review systems that the NetScaler communicates with directly, particularly Citrix StoreFront servers, Citrix Delivery Controllers (DDCs), and internal Citrix Virtual Apps and Desktops hosts. Review Windows Event Logs for anomalous interactive logons, unexpected remote desktop protocol (RDP) activity, signs of credential dumping, and other evidence of lateral movement.
Organizations should also consider revoking and rotating TLS certificates and associated private keys stored on compromised appliances.
Note: Organizations should rotate credentials after the appliance has been successfully patched.
