Citrix Confirms Active Exploitation of Two Critical NetScaler Vulnerabilities

Citrix confirmed on September 27 that attackers are exploiting two critical vulnerabilities in customer managed NetScaler ADC and NetScaler Gateway. Both can allow remote code execution without authentication, and Citrix has released fixes.

An attacker can exploit an affected appliance without first stealing an employee’s password or convincing someone to click a link. One of these flaws affects default configurations on vulnerable builds. The other requires DTLS, which is enabled by default on VPN virtual servers.

These appliances can handle remote access and authentication into your environment. An attacker who gains control there has a foothold on infrastructure your organization trusts. That deserves immediate attention.

If you run NetScaler, identify the affected appliances and get the response moving. Preserve evidence while containing the exposure, and install the appropriate fixes. The build numbers and collection guidance are below.

Then comes the question a successful upgrade cannot answer: did somebody get in before you patched, and what did they do next?

What Citrix confirmed

The Citrix security bulletin, CTX697096, covers eight vulnerabilities. Citrix reports observed exploitation of CVE-2026-88771 and CVE-2026-88772. Both have a CVSS v4.0 score of 9.5.

CVE-2026-88771 is an input validation flaw that can let an unauthenticated attacker execute arbitrary commands. On affected builds, the default configuration is enough. No additional feature needs to be enabled.

CVE-2026-88772 is a memory overflow flaw that can allow remote code execution or denial of service when DTLS is enabled. DTLS is enabled by default on VPN virtual servers unless explicitly disabled. Other virtual servers configured for DTLS also meet that precondition.

Disabling DTLS does not address the first vulnerability. Do not mistake a configuration change affecting one attack path for protection against both.

Depending on its configuration, NetScaler handles remote access, authentication, application delivery, and traffic into internal systems. Successful exploitation gives an attacker a foothold on infrastructure you already trust. What they can reach from there depends on your environment, which is exactly why the investigation has to keep going.

The bulletin establishes active exploitation. It does not establish that every exposed customer was compromised, who attacked your appliance, or how long anyone was there. Those answers have to come from evidence.

Check the actual build

These are the minimum fixed builds listed in the bulletin. Use the appropriate build or a later supported release for that branch.

Secure Private Access Hybrid deployments using NetScaler instances are also in scope. Include them in the inventory.

“We patched recently” needs a version number attached to it. Builds such as 14.1-73.32 and 13.1-63.21 are below the fixes listed here. A successful update for an earlier advisory does not make this one go away.

Check the current bulletin and release notes before choosing the target build. Include every appliance, every member of a high availability pair, and the instances that somehow never make it onto the spreadsheet. Unsupported appliances need a supported replacement or removal from service.

There is also a separate configuration step for CVE-2026-88778, the TCP sequence number prediction issue in the same bulletin. For affected deployments, Citrix directs customers to enable Enhanced ISN Generation:

set ns tcpparam -enhancedISNgeneration ENABLED

Verify the setting with show ns tcpparam and save the configuration. This setting addresses that specific issue. It does not replace the firmware updates for the two exploited vulnerabilities.

Preserve what you will need to investigate

Patching and rebooting can change or destroy evidence. Make preservation part of the response from the beginning, while containing the exposure. Do not leave a vulnerable appliance reachable for hours while everyone debates how perfect the collection needs to be.

Citrix’s compromise response guidance, CTX694799, starts with preserving evidence. For a VPX instance, that includes a snapshot, system time and timezone details, local and remote logs, and a technical support bundle. Packet Engine memory is another collection target. Citrix documents the NSPPE- core files under /var/core/ and warns that generating the dump causes a warm restart. Coordinate that step with the people managing the incident.

For physical appliances, follow the documented imaging process with your response team. Preserve external logs too. You want records that an attacker on the appliance could not simply rewrite along with everything else.

If you have already patched, keep investigating. Preserve what remains, establish what changed during the upgrade, and use the authentication, firewall, application, and management logs around the appliance to reconstruct the timeline. Losing one source of evidence makes the job harder. It does not make the questions disappear.

A clean scan still needs context

Use the NetScaler Console indicators of compromise feature, check its prerequisites and current detection coverage, and contact Citrix Support for the applicable guidance if you cannot use it. Keep the detection logic current and retain the scan results.

Citrix says its indicator coverage does not include every technique an attacker might use and can miss actual compromises. That limitation matters when someone turns a scan result into a claim that the entire environment is safe.

I want to know what the scan checked, whether it completed, what evidence was available, and what period that evidence covers. A result from an appliance with missing logs deserves a very different level of confidence from an investigation with a usable timeline and supporting records from connected systems.

Follow the activity beyond the appliance

Start with changes that need an explanation: unexpected files, altered permissions, new scheduled jobs, configuration changes, unusual management access, and connections the appliance should not be making. Compare them with known good configurations and authorized maintenance.

Historical hunt ideas include unexpected PHP files in web directories, unusual SUID permissions on /bin/sh, suspicious files under /tmp, and unexplained Packet Engine crashes. Use those to frame questions and direct the investigation. They are not confirmed indicators for these two September vulnerabilities, and a crash by itself does not prove an attack.

For each suspicious event, build the surrounding sequence. What happened immediately before it? Which account was involved? Where did the appliance connect next? Do the destination system’s logs support the same explanation?

Pay particular attention to authentication servers, administrative systems, and the accounts and secrets the appliance used. If someone obtained access elsewhere before you patched, that access needs its own investigation and remediation.

This is where hunting earns its keep. A file change, a strange login, and an unusual connection may each look inconclusive on their own. Together, with timestamps and supporting evidence, they may tell you what happened. They may also turn out to be legitimate maintenance. Prove the connection before declaring a compromise.

Recover the environment you can trust

When compromise is suspected, follow Citrix’s recovery guidance: isolate the appliance, address exposed credentials and keys, investigate connected systems, and rebuild from trusted software. Restore a configuration that predates the compromise, verify it, and rotate the restored secrets. Keep management interfaces off the public internet. Citrix recommends close monitoring for at least 90 days after recovery.

Be explicit about the scope. Rebuilding one appliance will not revoke every credential an attacker stole or remove access they established on another system. The investigation determines what else needs to be reset, rebuilt, or watched.

Before someone tells me we are finished, I want to see which appliances were exposed, when they were fixed, what evidence was preserved, what the investigation found, and where our visibility ends. If we do not know something, say so and assign someone to work on it.

The team that stayed up to get the patches installed deserves credit. Give the investigation the same urgency.

The ticket can be closed. The unanswered questions still belong to us.