Last updated: 9 September 2026

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.

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.

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.

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.

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:

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.