Citrix NetScaler administrators are starting the week with an incident-response problem, not just another update notification. CISA says attackers are exploiting two newly disclosed vulnerabilities globally, and either one can independently enable remote code execution. Citrix published its security bulletin on September 27. Fixed releases are available.

The two flaws, CVE-2026-88771 and CVE-2026-88772, affect NetScaler ADC and NetScaler Gateway. For an organization relying on these appliances, the practical question is no longer whether someone might eventually build an attack. It is whether the exposed system was reached before its defenders could update it.

Two different routes through the perimeter

Citrix rates both vulnerabilities 9.5 under CVSS 4.0. The first involves improper input validation and can let an attacker execute commands without signing in. It affects vulnerable deployments in their default configuration; no extra feature has to be switched on.

The second is a memory-overflow flaw that can cause remote code execution or denial of service when DTLS is enabled. Citrix says that setting is enabled by default on VPN virtual servers. Turning off that feature is therefore not an answer to the separate default-configuration flaw.

Security company watchTowr explains why the location matters: these appliances handle remote access, authentication and traffic distribution at the edge of enterprise networks. A compromised gateway can give an intruder a foothold toward internal systems. This is infrastructure entrusted with controlling access, which makes a failure there more consequential than its unglamorous hardware suggests.

Patch promptly, but keep the evidence

CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog. Its warning also acknowledges an awkward operational reality: updating these systems can be complicated and require downtime. Where possible, organizations should check for compromise before updating; suspected intrusions call for preserving forensic evidence because an upgrade can erase useful traces.

That is not a recommendation to leave a vulnerable gateway exposed while conducting an open-ended investigation. It is a reason to coordinate containment, evidence collection and remediation rather than treating a successful software installation as the entire response. A patched version answers one question. Whether someone already got in is another.

Citrix lists fixes beginning with 14.1-73.37 and 13.1-64.23 for the main release branches, with separate FIPS and NDcPP builds in the bulletin. The scope is customer-managed appliances, including affected NetScaler instances in Secure Private Access hybrid deployments; Citrix handles updates to its managed cloud services.

There is an important qualification for the 13.1 branch. Citrix’s companion guidance warns that configured variables can trigger a reboot loop during an upgrade to 13.1-64.23. Affected administrators should use 13.1-64.24 instead, following the vendor’s configuration check. Read that guidance before choosing a build.

A clean scan is not a clean bill of health

Citrix is providing generic compromise indicators through NetScaler Console, with access dependent on the documented version, telemetry and feature availability. Customers unable to use that workflow can contact support. Crucially, Citrix warns that those indicators do not cover every attacker technique and can miss actual compromises.

The reviewed advisories do not establish a complete victim count or identify every organization affected. Confirmed exploitation does not mean every vulnerable appliance has been breached. Equally, the absence of a scanner alert cannot establish that an individual appliance escaped.

TINA’s view

This deserves urgent operational attention, even in a news cycle crowded with security warnings. The strongest counterargument is real: an emergency upgrade can disrupt the services it is meant to protect, and Citrix’s reboot caveat makes that risk concrete. But the evidence supports a controlled emergency response, not waiting for a more convenient maintenance cycle.

That judgment would change for a specific deployment if its owner verified that it is outside the affected versions, or demonstrated effective isolation while preparing remediation. It would become more urgent with evidence of compromise. The next useful signals are updated vendor detection guidance, completed remediation and an investigation of prior exposure—not simply a dashboard turning green.