On June 17, 2025, Citrix published a security advisory for CVE-2025-5777, followed by CVE-2025-6543 on June 25, 2025. Both are classified as critical and are actively being exploited in the wild.

Threat Overview

• CVE-2025-5777: Critical vulnerability due to improper input validation → leads to memory overread
• CVE-2025-6543: Enables memory overflow, potentially resulting in DoS or arbitrary code execution → Exploits available !

⚠️ Important: Simply applying the firmware update is not enough. You must manually terminate all active ICA and PCoIP sessions after patching to ensure the vulnerability is fully mitigated.

Supported Builds & Upgrade Paths

Legacy versions like 12.1, 13.0, and older are end-of-life (EOL) and will not receive any security patches. You must upgrade to 13.1 or 14.1.

NetScaler (Citrix ADC) und NetScaler (Citrix) Gateway
Version	Refresh Build	Expected Release Date
13.1	13.1.-59.19	Patch is here
14.1	14.1.-43.56	Patch is here

Instructions for updating the appliances:

Citrix ADC 101 – Fundamentals

Post-Update: Terminate Active Sessions (CVE-2025-5777)

These commands terminate all sessions that may have been established prior to the patch — they remain vulnerable unless actively closed.

Forensic Analysis: Has Your System Been Compromised?

Even if no attack has been detected, we highly recommend conducting a full system audit. Below is a checklist of 19 key areas with explanations and commands.

1. Determine Last Update Timestamp

Identify the date of the last extracted firmware files. Use (last update date + 1 day) as a reference for all further checks.

2. Check for Modified Files Since Last Update

Suspicious modifications (e.g., new PHP files) may indicate tampering or malware.

3. Look for Known Webshells

The presence of a.php is a strong indicator of a known webshell and confirmed compromise.

4. Check GUI Files (Caution!)

These files may change timestamps during system reboots — use this only as an indicator, not proof.

5. Automated Python Scan for File Changes

Quickly identifies files modified after the last update — a useful early indicator.

6. Search for Suspicious PHP Files

PHP files in these directories are not standard and typically indicate backdoors or webshells.

7. Check HTTP Error Logs for Exploit Patterns

Searches for entries that indicate script calls, in particular.php, .sh or .pl. These can document attacks.

The picture shows that the search for .sh was successful. You can check this directly by looking into the file with an editor of your choice (e.g. vi).

8. Inspect Shell & Bash Logs

These logs store direct shell commands executed by attackers. Access to key files or the use of  opensslare particularly dangerous.

9. Identify Suspicious “nobody” Processes

Only the internal webserver should run under “nobody”. Any other process is suspicious.

Here is an example of the allowed processes.

And an attacked server. The top line is malware.

10. Crontab Analysis

No crontab entries should exist for “nobody”.
Legitimate cron jobs (like iprep, aslearn_health_monitor.py, etc.) are documented.

There should be no crontab for nobody.

I have received several community comments that the following entries are also normal:

• /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

11. Analyze HTTP Access Logs

Look for successful (200) requests to unknown URLs or automated access from headless browsers.

12. Check for Core Dumps

Core dumps may indicate crashes caused by memory overflows or exploit activity.

This is what it looks like for an attacked system.

13. Detect Python/Perl-Based Backdoors

Run this command twice. Legitimate scheduled tasks may briefly run Python/Perl, but persistent processes are a red flag.

If more than the grep queries shown are seen, the further scripts, should be checked by a Google search.

If something appears, run the command again after a few seconds. Some scheduled tasks on the NetScaler also use python or perl. Only if it still runs on the second call, this should be checked.

These are normal scripts for an NetScaler instance hosted in Azure.

When the StoreFront monitor is used, you will permanently see the following Perl script.

14. CPU Usage — Check for Cryptominers

Only NSPPE-xx processes should utilize CPU long-term. Other entries (e.g., xmrig) could indicate mining malware.

15. Network and Firewall Log Review

• Unusual scanning activity on ports 80/443/445
• Spikes in LDAP/DNS/AD connections (ports 389, 53, 88, etc.)

These patterns suggest lateral movement or reconnaissance post-exploit.

16. IOC Detection in Log Files

Quickly detects known attack indicators across all log files.

This query filters out local IPs and concentrates on suspicious commands in log files.

17. Setuid Files Modified Since Patch

setuid files in non-standard locations (especially under /var) are highly suspicious.

18. Check nsfsyncd Process (HA Mode)

On HA systems, nsfsyncd must be running.
If missing: it may have been intentionally disabled during an attack.

On standalone systems, it should not be present.

19. Verify HA Node Health

Confirms the current node roles, sync status, and HA health.
Any mismatch or “unsynchronized” status warrants deeper investigation.

If Your System Is Compromised – Immediate Actions

1. Disconnect the NetScaler from the network
2. Reset all stored passwords (LDAP, local admin, etc.)
3. Reissue SSL certificates and keys
4. If using VPX: consider reverting to a clean snapshot
5. Preferred: Build a new VPX and import config from backup
6. Retain the same MAC address, or relicense the appliance
7. Start the new system without network connectivity
8. Verify system integrity via console
9. Change nsroot password
10. Reconnect internal network → then external
11. Replace all SSL certificates
12. Continuously monitor logs and responder activity

Final Thoughts

The Citrix NetScaler threat landscape remains highly volatile.
Patching is not enough — you must validate, review, and respond.

Verify your appliances. Document changes. Take action.