Deyda Consulting Blog

Critical vulnerabilities in NetScaler ADC and NetScaler Gateway require a structured approach: assess exposure, select a secure target version, update affected systems, and then determine whether there are any indications of compromise.

This checklist summarizes the key steps for dealing with new NetScaler CVEs. The current vendor security bulletin, supported firmware builds, and the specifics of your own environment should always be considered authoritative. Do not assess only the current patch status. CVE-specific prerequisites, the period during which the appliance was publicly exposed, and potential indicators of an earlier compromise must also be taken into account.

Latest Citrix findings: eight NetScaler vulnerabilities

Updated 28 September 2026: Citrix has published Security Bulletin CTX697096 covering eight vulnerabilities in NetScaler ADC and NetScaler Gateway: CVE-2026-88771 through CVE-2026-88778. Citrix confirms that exploitation of CVE-2026-88771 and CVE-2026-88772 has been observed. Affected systems should be updated to a fixed build as soon as possible.

CVE	Summary	Citrix precondition
CVE-2026-88771	Unauthenticated remote code execution (RCE)	All deployments; no additional feature required
CVE-2026-88772	Memory overflow that may lead to RCE or denial of service (DoS)	DTLS enabled; enabled by default on VPN virtual servers unless explicitly disabled
CVE-2026-88773	HTTP request smuggling	HTTP configuration enabled
CVE-2026-88774	Policy bypass	HTTP URL-based policy expression configured
CVE-2026-88775	Memory overflow that may cause unexpected behavior or DoS	Gateway or AAA virtual server
CVE-2026-88776	Memory overflow that may cause unexpected behavior or DoS	Oracle load-balancing virtual server
CVE-2026-88777	Memory overflow that may cause unexpected behavior or DoS	Non-HTTP Layer 7 feature enabled on an LB/CS or CGNAT-LSN/NAT64 appliance
CVE-2026-88778	TCP Initial Sequence Number (ISN) prediction	TCP configuration enabled; Citrix recommends an additional ISN configuration change

Citrix fixed-build thresholds:

• NetScaler 14.1: 14.1-73.37 or later
• NetScaler 13.1: 13.1-64.23 or later
• NetScaler 14.1 FIPS: 14.1-73.37 FIPS or later
• NetScaler 13.1 FIPS/NDcPP: 13.1-37.279 or later

The configuration preconditions help assess exposure before the update. If the appliance is already running a fixed build for the relevant product variant, a matching virtual server or enabled feature does not, by itself, mean the appliance remains vulnerable to these CVEs. However, patching does not remove evidence of possible earlier exposure or prove that the appliance was not compromised before the update. The timeline and a security assessment still matter.

Additional investigation indicators

When investigating a suspected incident or the period before patching, correlate CVE-specific configuration prerequisites with system and log evidence, including:

• Unexpected reboots or cold starts; correlate their timestamps with HTTP access logs and other reboot events.
• Changes to /etc/httpd.conf, or the httpd.conf path used by that build, compared with a trusted baseline.
• Unexpected changes to /bin/sh permissions.
• Unknown .dot files under LogonPoint/custom.
• Suspicious b64decode strings in available HTTP or system logs.
• New or modified files in security-relevant directories, including /var/vpn/, /var/netscaler/logon/, /var/python/, and /netscaler/ns_gui/.
• Unknown PHP, Perl, Python, JavaScript, or ELF files and possible webshells.
• Suspicious HTTP requests, unusual POST requests, and requests for unexpected resources.
• Unusual shell, Bash, Gateway, or VPN log entries, as well as log gaps or unexpected log rotation.
• New or modified files with the SUID bit set and unusual processes, including processes running as nobody.
• Unexpected cron entries or changes to /flash/nsconfig/rc.netscaler and /etc/monitrc.
• HA synchronization issues or unexpected changes to nsfsyncd.
• Unusual NSPPE crashes, core dumps, processes, or sustained resource usage.
• Unusual outbound connections, internal scans, or other unexpected network activity from the appliance.

A match is an investigation lead, not proof of compromise. A search with no matches does not prove that the appliance is clean: logs may have rotated or been modified, and automated checks only cover the paths and patterns they scan.

For CVE-2026-88778, Citrix also specifies an Enhanced ISN Generation configuration change for affected systems. Check the current vendor instructions and the live appliance configuration.

Automated NetScaler security check

For an initial technical assessment, download the script below and run it on the relevant appliance. Version 9.9 compares the firmware build with the fixed-build thresholds in CTX697096, searches the saved configuration for CVE preconditions, and checks selected files, directories, and logs for potential indicators. A match is an investigation lead, not proof of compromise.

The script is read-only: it does not change the NetScaler configuration, restart services, or remove files. It writes a plain-text report to /var/tmp and prints the report path when it finishes.

Report status indicators

• [OK]: No matching indicator was found in the source and scope that were checked. This does not prove that the appliance is clean.
• [ACTION]: A potentially relevant finding requires investigation; it is not automatically proof of compromise.
• [CHECK]: Manual validation is required or the check could not cover its intended scope.

In an interactive terminal, the status labels are colour-coded. The saved report remains plain text.

Run the script on the appliance

Copy the script to the NetScaler, for example to /var/tmp, then switch to the BSD shell and run it:

On the appliance, the script attempts to detect the firmware build from the header of /nsconfig/ns.conf and then from nsconmsg. It reads Enhanced ISN Generation from /nsconfig/ns.conf. If the directive is absent, the script treats the setting as DISABLED, which is the Citrix default. It prompts for a value only when it cannot determine the required information.

If a prompt appears, use the NetScaler CLI to retrieve the requested value:

The complete output of the Enhanced ISN command, or just ENABLED or DISABLED, can be entered.

Optionally pass the values at startup

You can explicitly supply the firmware version and Enhanced ISN state as arguments. Explicit values take precedence over automatic detection:

Replace the example values with those for your appliance. The script checks the saved /nsconfig/ns.conf; it does not verify that the saved configuration matches the current running configuration. Compare relevant findings with the live CLI configuration.

Scope limitation: Version 9.9 does not run Citrix File Integrity Monitoring; run that separately according to the vendor’s guidance. A clean result does not rule out earlier compromise, especially if logs have rotated or the appliance was patched after a period of exposure.

Assess the CVE and Prepare the Update

When assessing a NetScaler appliance, do not look exclusively at the currently installed firmware version. You also need to determine whether the appliance was publicly accessible during a vulnerable period and whether the configuration prerequisites for the respective vulnerability were present.

CVE-2026-19490 currently requires particular attention. This critical authentication bypass vulnerability (CVSS 9.3) affects, depending on the installed build, NetScaler systems configured with Gateway or AAA virtual servers and, in some cases, additionally requires a configured SAML Action. Exploitation attempts in the wild have since been reported, and a public Proof of Concept is available.

Affected systems must be updated to at least 14.1-73.32, 13.1-63.21, 14.1-FIPS 73.32, or 13.1-FIPS/NDcPP 37.277, respectively. Citrix does not provide a workaround.

In addition to the firmware version, check the relevant prerequisites in ns.conf:

For publicly accessible Gateway or AAA virtual servers in particular, evaluate the firmware version, relevant configuration, and the period of public exposure together. A system that is patched today may already have been attacked during an earlier vulnerable period.

A current patch status tells you neither whether the system was previously exposed nor whether it may already have been compromised.

For CVE-2026-8452, additionally document whether and during which period the appliance was publicly accessible as a Gateway or AAA virtual server. Record the build that was installed at the time as well as the exact upgrade time. According to Citrix, affected versions include NetScaler ADC and NetScaler Gateway builds prior to 14.1-72.61 and 13.1-63.18.

There is an additional consideration for CVE-2026-13474: checking the firmware version alone is not sufficient. Citrix states that the HTTP/2 configuration must also be taken into account. If an HTTP Strict Profile is not used, http2SmallWndTimeout may still be set to 0. In this case, installing the firmware update alone does not fully address the vulnerability.

Therefore, also check which HTTP profiles are in use and which value is configured for http2SmallWndTimeout. The default value for an HTTP Strict Profile is 30.

This is particularly important for automated security checks: a fixed firmware version must not automatically result in a successful security assessment for CVE-2026-13474 without also evaluating the relevant configuration.

Before updating:

• Review the current security bulletin and identify the affected product versions.
• Document the current build, HA status, existing partitions, and enabled features.
• Verify the supported target version, known issues, and the required upgrade path.
• Back up the configuration and relevant system files and prepare a reliable rollback plan.
• Apply any workarounds published by Citrix until the update can be installed, and document all changes made.

Update the Firmware

Update all affected NetScaler systems to a firmware build released by Citrix that addresses the relevant vulnerabilities. For HA pairs, perform the update in a controlled manner while taking synchronization, failover, and the availability of published services into account. Outdated or unsupported versions should be migrated to a supported release branch.

Installing a firmware update alone does not prove that the system was unaffected before the update. For critical vulnerabilities, a subsequent security assessment should therefore be part of the process.

Assess the Systems for Compromise

Even systems that have already been updated should undergo a thorough security assessment. Particularly with critical or actively exploited vulnerabilities, the currently installed firmware version alone cannot determine whether an appliance was attacked or compromised before it was patched.

The following checks are based on vendor information, published security research, community findings, and my own experience from NetScaler environments I have investigated.

If there is a concrete suspicion of compromise, preserve evidence before rebooting, updating, or cleaning up the system. At a minimum, preserve a VPX snapshot or suitable forensic image, system time, time zone and NTP configuration, a Technical Support Bundle, and local and centralized logs. Depending on the incident, preserving existing NSPPE core dumps may also be useful. Citrix describes the general procedure in CTX694799.

A single match is not automatically proof of a successful attack. Conversely, an apparently clean result does not rule out compromise because logs rotate and attackers may modify or remove traces. Always evaluate suspicious findings within the temporal and technical context of the relevant security bulletin.

Determine the Time of the Last Firmware Update

Modified timestamps can provide an initial indication of manipulation. However, they must always be evaluated together with files, logs, processes, core dumps, and network activity.

As a temporal reference point, first determine when the last NetScaler firmware update was installed. The installation directories under /var/nsinstall/ provide a useful starting point.

Perform the following checks through an administrative SSH/CLI session on the NetScaler. Log on with an administrative account and switch to the BSD shell where required for the respective command.

In this example, the most recently installed NetScaler update package was extracted on July 19, 2023. This date serves as the temporal reference point for the following checks. For time-based searches, use the following day as the start date in YYYYMMDD format — in this example, 20230720.

Reboots and Cold Starts

Also review the reboot and shutdown history for unexpected reboots or cold starts. A suspicious reboot is not, by itself, proof of exploitation. Record its timestamp and correlate it with HTTP access logs, system messages, core dumps, and other available events. Missing reboot-history entries do not reliably prove that no reboot occurred; logs may be incomplete or rotated.

Modified Files

Next, check whether files in security-relevant directories have been created or modified since the last firmware update. A match does not by itself prove a compromise, but it can be a relevant investigation lead.

Take intentional modifications into account, such as customized logon pages or themes, and compare their legitimate modification dates with the timestamps you find.

A webshell observed in attacks was stored as a.php in /var/netscaler/logon/. An unknown file with this name should be treated as a critical investigation finding. However, also evaluate its content, owner, permissions, timestamps, and associated logs, as the filename alone does not prove compromise.

Be aware that timestamps of files under /netscaler/ns_gui/ can change not only during firmware updates but also during reboots. A newer timestamp in this directory is therefore not automatically suspicious.

Alternatively, you can perform the check using the following Python command:

If no unexpected modifications are found, this reduces the level of suspicion for this particular area of the investigation. However, it does not rule out a compromise.

New Files and Webshells

Additionally, check for unknown PHP, Perl, Python, JavaScript, or ELF files in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /tmp/, and /var/tmp/.

Inspect typical web and portal directories for unknown files as well. Newly created files may indicate a deployed webshell or other manipulation, but their presence alone is not proof of compromise.

When investigating CVE-2026-8452, pay particular attention to unknown PHP files in /var/vpn/theme/, /var/vpn/, and /netscaler/ns_gui/.

Webshells with filenames such as x.php and z.php have been observed during attacks. However, these specific filenames do not replace a comprehensive search for other newly created or modified files.

Also check LogonPoint/custom for unknown files with the .dot extension. On the appliance, the path may be /var/netscaler/logon/LogonPoint/custom. For each finding, review its contents, timestamp, owner, and permissions, and compare it with planned changes. Preserve and investigate unknown .dot files; the file extension alone does not confirm compromise.

HTTP Error Logs

Exploitation attempts or successful exploitation may leave traces in the HTTP error logs. Pay particular attention to unexpected requests for unknown resources, unusual POST requests, User-Agents that are atypical for the relevant period, and crashes or core dumps close to the suspected time of attack.

The following commands can additionally be used to search for references to shell, PHP, or Perl files:

In the example, the search for .sh returns a match. Open the relevant log entry, for example with vi, to inspect the full context.

The match shown in the screenshot was created by me for testing purposes and does not represent an actual attack.

For CVE-2026-8452, include suspicious requests involving SAML, VPN, theme, and PHP resources. Correlate the timestamps of suspicious HTTP requests with newly created files, process crashes, and the time of the firmware upgrade.

Search available HTTP access and error logs for the string b64decode. Review each match in its full context and correlate its timestamp with suspicious HTTP requests, reboots, or cold starts. A match is an investigation lead, not proof of successful exploitation. No match does not rule out compromise.

Shell and Bash Logs

Successful exploitation may also leave suspicious commands or other traces in shell and Bash logs.

The entries visible in the screenshot originate exclusively from my own tests and do not represent an attack.

Also search for executed discovery commands such as id or echo, as well as download, file manipulation, and shell commands. Such commands have been observed in publicly documented exploitation attempts against CVE-2026-8452.

Additional Log Files

Pay attention to gaps in logging, unusually early log rotations, and timestamps that do not match the system time, time zone, NTP configuration, or the overall event timeline.

The following search can be used to inspect log files for selected suspicious commands and artifacts:

Integrity of httpd.conf and /bin/sh

Check the httpd.conf file used by the relevant build, for example /etc/httpd.conf, for unexpected changes. File timestamps alone are insufficient: compare the file contents and metadata with a trusted baseline for the same NetScaler version and account for documented administrative changes.

Also check the owner and permissions of /bin/sh. Compare them with a known-good appliance running the same build. An unexpected difference requires investigation; expected values may vary by version.

Modified Files with the SUID Bit Set

Copied shells, newly created SUID files, and unusual ownership or permissions are particularly critical. Always compare such findings against the known-good state of the appliance.

For CVE-2026-8452, pay particular attention to /bin/sh, copied shells, or other unusual files unexpectedly carrying the SUID bit. Such a finding is highly critical and requires forensic analysis.

Processes Running as nobody

Unusual processes running in the context of the nobody user have also been observed during attacks. Because legitimate NetScaler components may use this account as well, a process running as nobody is not automatically suspicious. Compare unknown processes against the expected state of your appliance.

The following screenshot shows a compromised server for comparison. The first line shows the malicious process identified during the investigation.

Check the Cron Configuration for New Entries

In addition to the crontabs, inspect /flash/nsconfig/rc.netscaler and /etc/monitrc. Commands that recreate webshells after a reboot, set the SUID bit, or hide or terminate monitored processes should be considered suspicious.

Use the following command to review the current crontab. Compare the entries against the known-good state and the features enabled on the appliance.

Also check whether a crontab exists for the nobody user and whether its entries are plausible for your configuration:

Based on community feedback and comparisons across different environments, the following entries, among others, may be legitimate. Whether they are expected on your appliance depends on the features actually in use:

• /netscaler/adss-licexp.sh –> For trial licenses
• 0/5 * * * * root /netscaler/iprep –> When IP Reputation is in use
• */5 * * * * root /var/python/bin/python /netscaler/aslearn_health_monitor.py –> When app firewall is used
• */5 * * * * root /bin/pgrep -f /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py; [ $? != 0 ] && /var/python/bin/python /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py –> When app firewall is used

NetScaler HA Systems

Unexplained HA synchronization errors and stopped or modified monitoring and synchronization processes may also indicate manipulation.

During documented attacks, the nsfsyncd process responsible for HA file synchronization has, among other things, been manipulated or terminated. Therefore, verify that the process is running as expected on your HA nodes.

On a standalone appliance, nsfsyncd is not necessarily expected. The screenshot shows the expected state of a functioning HA system.

Always investigate both nodes of an HA pair independently. A clean finding on one node does not rule out compromise of its peer.

Gateway and VPN Access Logs

Additionally, inspect Gateway and AAA sessions for changes in source IP addresses, countries, or User-Agents within the same session, as well as sessions that continue to be used despite password changes or MFA-related remediation measures.

The following search can be used to identify successful web requests to potentially unknown resources for further investigation:

Additionally, search for requests using HeadlessChrome as the User-Agent:

A match is not automatically malicious and must be evaluated in the context of the respective session and environment.

NSPPE Core Dumps

Search core dumps and related artifacts for indications that ns.conf, .F1.key, .F2.key, certificates, or private keys were copied into web, theme, template, or temporary directories.

Memory errors or crashes of the NetScaler Packet Processing Engine (NSPPE) may generate core dumps. Unusual dumps created during the relevant investigation period should therefore be examined more closely. A core dump alone is not evidence of successful exploitation.

For CVE-2026-8452, investigate unusual crashes, core dumps, and restarts of the nsppe process. Correlate these events with suspicious SAML or HTTP requests and newly created files.

Perl and Python Scripts

Unknown or manipulated Perl and Python scripts can be used to execute malicious code or establish persistence.

Compare unknown processes and scripts against the documented baseline, enabled NetScaler features, and vendor documentation. Review the file path, owner, start time, command line, and file hash.

The scripts shown in the screenshot are legitimate in this Azure-hosted NetScaler environment.

If you use the StoreFront Monitor, a corresponding Perl process may also be permanently visible.

Unusual Processes and Crypto Miners

I have investigated compromised NetScaler appliances that were subsequently abused for cryptocurrency mining. However, persistently high CPU utilization can have many other causes and is not evidence of compromise on its own.

Therefore, inspect running processes and always identify which process is responsible for unusually high CPU utilization. In addition to cryptocurrency mining, compromised systems may be abused for proxying, tunneling, scanning, or other malicious activities.

In the example shown, the high utilization of the NSPPE processes is expected. The relevant findings are additional or unknown processes exhibiting unusually high or sustained resource utilization.

Review Network and Firewall Logs

Complement the local investigation of the appliance with an analysis of network and firewall logs. In particular, investigate unusual traffic originating from the NSIP, internal scanning activity, suspicious outbound connections, and deviations from the appliance’s normal communication profile.

Pay particular attention to:

• Scanning activity from the NetScaler into internal networks over HTTP, HTTPS, or SMB (80, 443, 445)
• unusually high LDAP/LDAPS, DNS, or Kerberos activity (389, 636, 53, 88, etc.)
• unexpected RDP or network logons
• unusually large outbound data transfers
• unusual DNS destinations or external connections
• suspicious Active Directory events such as 4624 and 4625

Correlate these findings with HTTP/Gateway, shell, authentication, and firewall logs as well as the suspected attack timeframe.

Remediation for Affected Systems

If compromise has been confirmed, or if it cannot be ruled out with sufficient confidence based on the available artifacts, consider the following measures depending on the findings:

• Isolate the affected NetScaler appliance from the network in a controlled manner.
• Change the passwords of all LDAP, Active Directory, service, and other network accounts used or stored on the NetScaler.
• Replace potentially compromised SSL certificates together with their associated private keys.
• Revoke compromised certificates where appropriate for the respective PKI or Certificate Authority.
• Invalidate or terminate existing sessions if session takeover cannot be ruled out.
• Investigate dependent systems and identities for potential follow-on activity.

For a VPX appliance, a snapshot from a state that can be demonstrated to predate the potential compromise period may assist with recovery. However, the age of a snapshot alone does not establish that it is trustworthy. Restoring a snapshot does not replace root-cause analysis or the rotation of potentially compromised credentials, certificates, and keys.

If a compromise has been confirmed, a controlled rebuild should, depending on the findings, be preferred over simply restoring a system whose integrity cannot be established with sufficient confidence.