Zuletzt aktualisiert: 9. September 2026

Kritische Schwachstellen in NetScaler ADC und NetScaler Gateway erfordern ein strukturiertes Vorgehen: Betroffenheit bewerten, eine sichere Zielversion auswählen, Systeme aktualisieren und anschließend prüfen, ob Hinweise auf eine Kompromittierung vorliegen.

Diese Checkliste bündelt die wichtigsten Schritte für neue NetScaler-CVEs. Maßgeblich bleiben immer das aktuelle Security Bulletin des Herstellers, die unterstützten Firmwarestände und die Besonderheiten deiner eigenen Umgebung. Betrachte dabei nicht nur den aktuellen Patch-Status, sondern auch CVE-spezifische Voraussetzungen, den Zeitraum der öffentlichen Erreichbarkeit und mögliche Hinweise auf eine bereits erfolgte Kompromittierung.

CVE bewerten und Update vorbereiten

Bei der Bewertung einer NetScaler-Appliance darf nicht ausschließlich der aktuell installierte Firmwarestand betrachtet werden. Entscheidend ist zusätzlich, ob die Appliance während eines verwundbaren Zeitraums öffentlich erreichbar war und ob die für die jeweilige Schwachstelle notwendigen Konfigurationsbedingungen erfüllt waren.

Aktuell erfordert insbesondere CVE-2026-19490 besondere Aufmerksamkeit. Die kritische Authentication-Bypass-Schwachstelle (CVSS 9.3) betrifft abhängig vom eingesetzten Build NetScaler-Systeme mit Gateway- beziehungsweise AAA-vServer-Konfiguration und teilweise zusätzlich einer konfigurierten SAML Action. Inzwischen wurden Exploit-Versuche in freier Wildbahn gemeldet und ein öffentlicher Proof of Concept ist verfügbar.

Betroffene Systeme müssen mindestens auf 14.1-73.32, 13.1-63.21, 14.1-FIPS 73.32 beziehungsweise 13.1-FIPS/NDcPP 37.277 aktualisiert werden. Citrix nennt keinen Workaround.

Neben dem Firmwarestand solltest du deshalb auch die relevanten Voraussetzungen in der ns.conf prüfen:

Besonders bei öffentlich erreichbaren Gateway- oder AAA-vServern solltest du Firmwarestand, relevante Konfiguration und den Zeitraum der öffentlichen Erreichbarkeit gemeinsam bewerten. Ein heute gepatchtes System kann bereits während eines früheren verwundbaren Zeitraums angegriffen worden sein.

Ein aktueller Patch-Status sagt weder etwas über eine frühere Exposition noch über eine mögliche Kompromittierung aus.

Dokumentiere bei CVE-2026-8452 zusätzlich, ob und in welchem Zeitraum die Appliance als Gateway oder AAA Virtual Server öffentlich erreichbar war. Halte den damals eingesetzten Build und den genauen Upgrade-Zeitpunkt fest. Laut Citrix sind unter anderem NetScaler ADC und NetScaler Gateway vor 14.1-72.61 beziehungsweise vor 13.1-63.18 betroffen.

Besonderheit bei CVE-2026-13474: Hier reicht die Prüfung des Firmwarestands allein nicht aus. Citrix weist darauf hin, dass zusätzlich die HTTP/2-Konfiguration berücksichtigt werden muss. Wird kein HTTP Strict Profile verwendet, kann http2SmallWndTimeout weiterhin auf 0 stehen. In diesem Fall ist die Schwachstelle durch das Firmwareupdate allein nicht vollständig adressiert.

Dies ist insbesondere für automatisierte Security-Checks relevant: Ein korrigierter Firmwarestand darf bei CVE-2026-13474 nicht automatisch zu einem positiven Prüfergebnis führen, ohne die relevante Konfiguration einzubeziehen.

Prüfe deshalb zusätzlich, welche HTTP-Profile verwendet werden und welcher Wert für http2SmallWndTimeout konfiguriert ist. Bei einem HTTP Strict Profile beträgt der Standardwert 30.

Das ist insbesondere für automatisierte Security-Checks relevant: Ein korrigierter Firmwarestand darf bei CVE-2026-13474 nicht automatisch als erfolgreich bestandene Sicherheitsprüfung bewertet werden, ohne die relevante Konfiguration einzubeziehen.

• Prüfe das aktuelle Security Bulletin und identifiziere die betroffenen Produktversionen.
• Dokumentiere den aktuellen Build, HA-Status, vorhandene Partitionen und die eingesetzten Funktionen.
• Prüfe die unterstützte Zielversion sowie bekannte Probleme und den vorgesehenen Upgrade-Pfad.
• Sichere Konfiguration und relevante Systemdateien und lege einen belastbaren Rollback-Plan fest.
• Setze von Citrix veröffentlichte Workarounds bis zum Update um und dokumentiere die vorgenommenen Änderungen.

Firmware aktualisieren

Aktualisiere alle betroffenen NetScaler-Systeme auf einen von Citrix freigegebenen Firmwarestand. Bei HA-Paaren solltest du das Update kontrolliert und unter Berücksichtigung von Synchronisation, Failover und Erreichbarkeit der veröffentlichten Dienste durchführen. Veraltete oder nicht mehr unterstützte Versionen solltest du auf einen unterstützten Release-Zweig migrieren.

Ein Firmwareupdate allein beweist nicht, dass das System vor der Aktualisierung unberührt war. Bei kritischen Schwachstellen gehört deshalb eine anschließende Sicherheitsprüfung zum Ablauf.

Überprüfung der Systeme

Auch bereits aktualisierte Systeme solltest du einer eingehenden Sicherheitsprüfung unterziehen. Insbesondere bei kritischen oder aktiv ausgenutzten Schwachstellen lässt sich allein anhand des aktuellen Firmwarestands nicht feststellen, ob eine Appliance zuvor angegriffen oder kompromittiert wurde.

Die folgenden Prüfungen basieren auf Herstellerinformationen, veröffentlichten Sicherheitsanalysen, Community-Hinweisen und eigenen Erfahrungen aus untersuchten NetScaler-Umgebungen.

Sichere bei einem konkreten Verdacht vor einem Neustart, Update oder einer Bereinigung mindestens einen VPX-Snapshot beziehungsweise ein geeignetes forensisches Abbild, Systemzeit, Zeitzone und NTP-Konfiguration, ein Technical Support Bundle sowie lokale und zentrale Protokolle. Je nach Vorfall kann zusätzlich die Sicherung vorhandener NSPPE-Core-Dumps sinnvoll sein. Citrix beschreibt das grundsätzliche Vorgehen in CTX694799.

Ein einzelner Treffer ist nicht automatisch ein Beweis für einen erfolgreichen Angriff. Umgekehrt schließt ein unauffälliger Befund eine Kompromittierung nicht aus, da Protokolle rotieren und Angreifer Spuren verändern können. Bewerte Auffälligkeiten deshalb immer im zeitlichen und technischen Kontext des jeweiligen Security Bulletins.

Zeitpunkt des letzten Firmwareupdates ermitteln

Veränderte Zeitstempel können einen ersten Hinweis auf eine Manipulation liefern. Es muss jedoch gemeinsam mit Dateien, Protokollen, Prozessen, Core Dumps und Netzwerkaktivitäten bewertet werden.

Als zeitliche Referenz solltest du zunächst den Zeitpunkt des letzten NetScaler-Firmwareupdates ermitteln. Einen geeigneten Anhaltspunkt liefern die unter /var/nsinstall/ vorhandenen Installationsverzeichnisse.

Die folgenden Prüfungen führst du über eine administrative SSH-/CLI-Sitzung auf dem NetScaler durch. Melde dich hierzu mit einem administrativen Konto an und wechsle, sofern für den jeweiligen Befehl erforderlich, in die BSD-Shell.

Im Beispiel wurde das zuletzt installierte NetScaler-Update-Paket am 19.07.2023 entpackt. Dieses Datum dient als zeitliche Referenz für die folgenden Prüfungen. Verwende für zeitbasierte Suchen als Startdatum den darauffolgenden Tag im Format YYYYMMDD – im Beispiel also 20230720.

Veränderte Dateien

Prüfe anschließend, ob seit dem letzten Firmwareupdate Dateien in sicherheitsrelevanten Verzeichnissen neu angelegt oder verändert wurden. Ein entsprechender Treffer stellt noch keinen Nachweis einer Kompromittierung dar, kann jedoch ein relevantes Untersuchungsindiz sein.

Berücksichtige dabei bewusst vorgenommene Änderungen, beispielsweise an Logon-Seiten oder Themes, und gleiche deren legitimen Änderungszeitpunkt mit den gefundenen Zeitstempeln ab.

Eine in Angriffen beobachtete Webshell wurde unter dem Namen a.php im Verzeichnis /var/netscaler/logon/ abgelegt. Eine unbekannte Datei mit diesem Namen ist ein kritischer Untersuchungsbefund. Bewerte jedoch zusätzlich Inhalt, Eigentümer, Berechtigungen, Zeitstempel und die dazugehörigen Protokolle, da der Dateiname allein noch keine Kompromittierung beweist.

Beachte, dass sich Zeitstempel von Dateien unter /netscaler/ns_gui/ nicht ausschließlich durch Firmwareupdates, sondern auch durch Neustarts verändern können. Ein neuerer Zeitstempel ist in diesem Verzeichnis deshalb nicht automatisch verdächtig.

Alternativ kannst du die Prüfung mit folgendem Python-Befehl durchführen:

Werden keine unerwarteten Änderungen gefunden, reduziert dies den konkreten Verdacht in diesem Prüfbereich. Eine Kompromittierung kann dadurch jedoch nicht ausgeschlossen werden.

Neue Dateien und Webshells

Prüfe zusätzlich auf unbekannte PHP-, Perl-, Python-, JavaScript- oder ELF-Dateien in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /tmp/ und /var/tmp/.

Untersuche zusätzlich typische Web- und Portalverzeichnisse auf unbekannte Dateien. Neue Dateien können auf eine abgelegte Webshell oder andere Manipulationen hinweisen, sind für sich allein jedoch noch kein Kompromittierungsnachweis.

Bei der Untersuchung im Zusammenhang mit CVE-2026-8452 solltest du insbesondere /var/vpn/theme/, /var/vpn/ und /netscaler/ns_gui/ auf unbekannte PHP-Dateien prüfen. Bei beobachteten Angriffen wurden unter anderem Webshells mit Namen wie x.php und z.php abgelegt. Diese konkreten Dateinamen ersetzen jedoch keine vollständige Suche nach anderen neu angelegten oder veränderten Dateien.

HTTP-Fehlerprotokolle

Angriffsversuche oder eine erfolgreiche Ausnutzung können Spuren in den HTTP-Fehlerprotokollen hinterlassen. Achte insbesondere auf unerwartete Aufrufe unbekannter Ressourcen, ungewöhnliche POST-Anfragen, für den Zeitraum untypische User-Agents sowie Abstürze oder Core Dumps nahe dem vermuteten Angriffszeitpunkt.

Mit den folgenden Befehlen kannst du zusätzlich nach Referenzen auf Shell-, PHP- oder Perl-Dateien suchen:

Im Beispiel liefert die Suche nach .sh einen Treffer. Öffne den betreffenden Logeintrag anschließend beispielsweise mit vi, um den vollständigen Kontext zu prüfen.

Der gezeigte Treffer wurde von mir zu Testzwecken erzeugt und stellt keinen tatsächlichen Angriff dar.

Beziehe bei CVE-2026-8452 insbesondere auffällige Aufrufe von SAML-, VPN-, Theme- und PHP-Ressourcen ein. Gleiche die Zeitstempel verdächtiger HTTP-Anfragen mit neu angelegten Dateien, Prozessabstürzen und dem Upgrade-Zeitpunkt ab.

Shell- und Bash-Protokolle

Bei einer erfolgreichen Ausnutzung können außerdem verdächtige Befehle oder andere Spuren in den Shell- und Bash-Protokollen vorhanden sein.

Die im Screenshot sichtbaren Einträge stammen ausschließlich aus meinen Tests und stellen keinen Angriff dar.

Suche außerdem nach ausgeführten Discovery-Kommandos wie id oder echo sowie nach Download-, Datei- und Shell-Befehlen. Solche Kommandos wurden bei öffentlich dokumentierten Exploit-Versuchen gegen CVE-2026-8452 beobachtet.

Weitere Protokolldateien

Achte außerdem auf Protokolllücken, ungewöhnlich frühe Logrotationen sowie Zeitstempel, die nicht zu Systemzeit, Zeitzone, NTP-Konfiguration oder dem übrigen Ereignisverlauf passen.

Mit der folgenden Suche kannst du die Protokolldateien auf ausgewählte verdächtige Befehle und Artefakte prüfen:

Veränderte Dateien mit gesetztem SUID-Bit

Kopierte Shells, neu angelegte SUID-Dateien sowie ungewöhnliche Eigentümer und Berechtigungen sind besonders kritisch. Gleiche entsprechende Funde immer mit dem bekannten Sollzustand der Appliance ab.

Bei CVE-2026-8452 solltest du besonders prüfen, ob /bin/sh, eine kopierte Shell oder eine andere ungewöhnliche Datei unerwartet mit gesetztem SUID-Bit vorhanden ist. Ein solcher Befund ist hochkritisch und muss forensisch eingeordnet werden.

Prozesse des Benutzers nobody

Bei Angriffen wurden auch ungewöhnliche Prozesse im Kontext des Benutzers nobody beobachtet. Da dieser Account ebenfalls von legitimen NetScaler-Komponenten verwendet wird, ist ein entsprechender Prozess nicht automatisch verdächtig. Gleiche unbekannte Prozesse deshalb mit dem Sollzustand deiner Appliance ab.

Der folgende Screenshot zeigt zum Vergleich einen kompromittierten Server. Die oberste Zeile zeigt den dabei identifizierten Schadprozess.

Cron-Konfiguration auf neue Einträge prüfen

Kontrolliere neben den Crontabs auch /flash/nsconfig/rc.netscaler und /etc/monitrc. Verdächtig sind insbesondere Befehle, die Webshells nach einem Neustart erneut anlegen, das SUID-Bit setzen oder überwachte Prozesse ausblenden beziehungsweise beenden.

Mit dem folgenden Befehl kannst du die aktuelle Crontab überprüfen. Vergleiche die Einträge mit dem bekannten Sollzustand und den auf der Appliance verwendeten Funktionen.

Prüfe zusätzlich, ob für den Benutzer nobody eine Crontab vorhanden ist und ob deren Einträge für deine Konfiguration plausibel sind:

Aus Community-Rückmeldungen und dem Vergleich verschiedener Umgebungen sind unter anderem folgende legitime Einträge bekannt. Ob sie auf deiner Appliance erwartet werden, hängt von den tatsächlich eingesetzten Funktionen ab:

• /netscaler/adss-licexp.sh –> Bei Testlizenzen
• 0/5 * * * * root /netscaler/iprep –> Wenn IP Reputation im Einsatz ist
• */5 * * * * root /var/python/bin/python /netscaler/aslearn_health_monitor.py –> Wenn App Firewall genutzt wird
• */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 –> Wenn App Firewall genutzt wird

NetScaler-HA-Systeme

Unerklärliche HA-Synchronisationsfehler sowie gestoppte oder veränderte Monitor- und Synchronisationsprozesse können ebenfalls auf Manipulationen hinweisen.

Bei dokumentierten Angriffen wurde unter anderem der für die HA-Dateisynchronisation zuständige Prozess nsfsyncd manipuliert beziehungsweise beendet. Prüfe deshalb, ob der Prozess auf deinen HA-Knoten erwartungsgemäß läuft.

Auf einer Standalone-Appliance ist nsfsyncd dagegen nicht zwingend zu erwarten. Der Screenshot zeigt den Sollzustand eines funktionierenden HA-Systems.

Untersuche bei einem HA-Paar immer beide Knoten separat. Ein unauffälliger Knoten schließt eine Kompromittierung des Partners nicht aus.

Gateway- und VPN-Zugriffsprotokolle

Prüfe Gateway- und AAA-Sitzungen zusätzlich auf wechselnde Quell-IP-Adressen, Länder oder User-Agents innerhalb derselben Sitzung sowie auf Sitzungen, die trotz Kennwortänderung oder MFA-Maßnahmen weiterverwendet werden.

Mit der folgenden Suche kannst du erfolgreiche Webzugriffe auf potenziell unbekannte Ressourcen näher untersuchen:

Suche zusätzlich nach Zugriffen mit HeadlessChrome als User-Agent:

NSPPE-Core-Dumps

Suche in Core Dumps und angrenzenden Artefakten nach Hinweisen, dass ns.conf, .F1.key, .F2.key, Zertifikate oder private Schlüssel in Web-, Theme-, Template- oder temporäre Verzeichnisse kopiert wurden.

Speicherfehler oder Abstürze der NetScaler Packet Processing Engine (NSPPE) können Core Dumps erzeugen. Ungewöhnliche Dumps im relevanten Untersuchungszeitraum solltest du deshalb genauer analysieren. Ein Core Dump allein ist jedoch kein Nachweis einer erfolgreichen Ausnutzung.

Untersuche bei CVE-2026-8452 ungewöhnliche Abstürze, Core Dumps und Neustarts des nsppe-Prozesses. Korreliere diese Ereignisse zeitlich mit verdächtigen SAML- oder HTTP-Anfragen und neu angelegten Dateien.

Perl- und Python-Skripte

Unbekannte oder manipulierte Perl- und Python-Skripte können zur Ausführung von Schadcode oder als Persistenzmechanismus verwendet werden.

Gleiche unbekannte Prozesse und Skripte mit dem dokumentierten Sollzustand, den installierten NetScaler-Funktionen und der Herstellerdokumentation ab. Prüfe Dateipfad, Eigentümer, Startzeitpunkt, Kommandozeile und Hashwert.

Die im Screenshot gezeigten Skripte sind in dieser Azure-basierten NetScaler-Umgebung legitim.

Wenn du den StoreFront-Monitor verwendest, kann außerdem dauerhaft ein entsprechender Perl-Prozess sichtbar sein.

Ungewöhnliche Prozesse und Krypto-Miner

Ich habe bereits kompromittierte NetScaler-Appliances untersucht, die anschließend für Crypto-Mining missbraucht wurden. Eine dauerhaft hohe CPU-Auslastung kann jedoch auch andere Ursachen haben und ist allein kein Kompromittierungsnachweis.

Prüfe deshalb die laufenden Prozesse und ordne eine ungewöhnlich hohe CPU-Auslastung immer dem verursachenden Prozess zu. Neben Crypto-Minern können kompromittierte Systeme beispielsweise auch für Proxying, Tunneling oder andere missbräuchliche Aktivitäten verwendet werden.

Im gezeigten Beispiel ist die hohe Auslastung der NSPPE-Prozesse erwartbar. Entscheidend sind zusätzliche oder unbekannte Prozesse mit ungewöhnlich hoher beziehungsweise dauerhafter Ressourcennutzung.

Netzwerk- und Firewall-Logs prüfen

Ergänze die lokale Untersuchung der Appliance durch eine Analyse der Netzwerk- und Firewall-Protokolle. Untersuche insbesondere ungewöhnlichen Verkehr von der NSIP, interne Scans, auffällige ausgehende Verbindungen und Abweichungen vom üblichen Kommunikationsprofil.

Achte insbesondere auf:

• Scans vom NetScaler in interne Subnetze über HTTP, HTTPS oder SMB (80, 443, 445)
• ungewöhnlich hohe LDAP-/LDAPS-, DNS- oder Kerberos-Aktivität (389, 636, 53, 88 usw.)
• unerwartete RDP- oder Netzwerk-Logons
• größere ausgehende Datenübertragungen
• ungewöhnliche DNS-Ziele oder externe Verbindungen
• auffällige AD-Ereignisse wie 4624 und 4625

Korreliere entsprechende Auffälligkeiten mit Webserver-, Shell-, Authentifizierungs- und Firewall-Protokollen sowie dem vermuteten Angriffszeitraum.

Gegenmaßnahmen bei betroffenen Systemen

Wenn eine Kompromittierung bestätigt wurde oder aufgrund der vorliegenden Artefakte nicht ausreichend ausgeschlossen werden kann, solltest du abhängig vom Befund unter anderem folgende Maßnahmen einleiten:

• Isoliere die betroffene NetScaler-Appliance kontrolliert vom Netzwerk.
• Ändere die Kennwörter aller auf dem NetScaler verwendeten LDAP-, AD- und sonstigen Service- beziehungsweise Netzwerkkonten.
• Ersetze potenziell kompromittierte SSL-Zertifikate einschließlich der zugehörigen privaten Schlüssel.
• Widerrufe kompromittierte Zertifikate, sofern dies für die jeweilige PKI beziehungsweise CA erforderlich ist.
• Invalidiere beziehungsweise beende bestehende Sitzungen, sofern eine Übernahme von Sessions nicht ausgeschlossen werden kann.
• Prüfe abhängige Systeme und Identitäten auf mögliche Folgeaktivitäten.

Bei einer VPX-Appliance kann ein Snapshot aus einem nachweislich vor dem möglichen Kompromittierungszeitraum liegenden Zustand bei der Wiederherstellung unterstützen. Das Alter eines Snapshots allein ist jedoch kein Sicherheitsnachweis. Ein Restore ersetzt weder die Ursachenanalyse noch die Rotation potenziell kompromittierter Zugangsdaten, Zertifikate und Schlüssel.

Bei einer bestätigten Kompromittierung sollte abhängig vom Befund ein kontrollierter Neuaufbau gegenüber der bloßen Wiederherstellung eines nicht zweifelsfrei vertrauenswürdigen Systems bevorzugt werden.