NetScaler und PHP CVE-2026-109618: Management-Zugriff jetzt absichern

Citrix hat am 21. Oktober 2026 in den Citrix Techzone Blogs bestätigt, dass NetScaler von zwei kritischen Lücken in PHP betroffen ist: CVE-2026-109618 und CVE-2026-109619. Die Management-Oberfläche des NetScaler läuft auf PHP. Alle unterstützten Versionen sind betroffen, einen behobenen Build gibt es noch nicht. Bis dahin hilft nur eins: den Management-Zugriff auf vertrauenswürdige Netze beschränken. Die Befehle dafür habe ich an meiner Testinstanz geprüft.

Steckbrief

CVE	CVE-2026-109618 und CVE-2026-109619 (PHP)
CVSS 4.0	je 9.2 (kritisch)
Art	CVE-2026-109618: Speicherfehler, wenn PHP beim Verarbeiten einer Anfrage der Speicher ausgeht. CVE-2026-109619: Zustand einer alten Anfrage bleibt nach dem Freigeben des Speichers erhalten und wird von einer späteren Anfrage weiterverwendet
Wirkung	Codeausführung im PHP-Prozess, ohne Anmeldung
Betroffen	Management-GUI und NITRO-API auf NSIP, SNIPs mit Management-Zugriff und Cluster-IP, alle unterstützten Versionen
Nicht betroffen	NetScaler Console (Service und On-Premises), NetScaler SVM
Behobener Build	noch keiner (Stand 22.10.2026)
Ausnutzung	Citrix nennt keine. CISA KEV: nicht gelistet (Katalog 2026.10.21). Das NCSC Neuseeland meldet für PHP allgemein Berichte über aktive Ausnutzung

Zur Einordnung von CVSS und KEV: CVE, CVSS, KEV und EPSS erklärt.

Welche Adressen betroffen sind

Die Lücke steckt in PHP, also überall dort, wo der NetScaler seine Management-Oberfläche (GUI) und die NITRO-API (die REST-Schnittstelle für Skripte und die Console) anbietet. Laut Citrix sind das:

• die NSIP, die NetScaler-IP, über die der NetScaler selbst verwaltet wird
• jede SNIP (Subnet-IP, Adresse für den Verkehr zu den Backends), auf der Management-Zugriff eingeschaltet ist
• die Cluster-IP, wenn die NetScaler als Cluster laufen

Prüfen auf der CLI

Über die NSIP wird der NetScaler verwaltet. Welche weiteren Adressen Management-Zugriff haben, zeigt dieser Befehl:

show ns runningConfig | grep -i "mgmtAccess ENABLED"

An der Testinstanz liefert er unter anderem eine testweise angelegte SNIP mit Management-Zugriff:

add ns ip 198.51.100.10 255.255.255.0 -vServer DISABLED -mgmtAccess ENABLED

Die NSIP selbst erscheint in dieser Liste nicht zuverlässig. An der Testinstanz stand sie dort erst, nachdem ich eine Eigenschaft an ihr geändert hatte. Zeilen mit add ns ip6 betreffen IPv6, dazu weiter unten ein eigener Abschnitt.

Für eine einzelne Adresse zeigt show ns ip, ob Management-Zugriff besteht und ob die GUI auch über HTTP erreichbar ist:

show ns ip <IP-Adresse>

In der Ausgabe stehen management access: Enabled und darunter gui: Enabled. Enabled heißt HTTP und HTTPS, SecureOnly heißt nur HTTPS.

Was zu tun ist

Citrix empfiehlt, GUI und API auf NSIP, SNIPs mit Management-Zugriff und Cluster-IP nur noch von vertrauenswürdigen Admin-Rechnern oder eng gefassten Management-Netzen aus zu erlauben. Am besten liegt das Management ohnehin in einem eigenen Netz, das aus dem Internet nicht erreichbar ist. Die folgenden Schritte setzen das um.

1. Management-Zugriff auf SNIPs abschalten, wo er nicht gebraucht wird

set ns ip <SNIP> -mgmtAccess DISABLED

An der Testinstanz war eine SNIP mit Management-Zugriff genauso erreichbar wie die NSIP: Die NITRO-API antwortete dort ohne Anmeldung mit HTTP 401, also mit einer Antwort des Management-Webservers. Nach -mgmtAccess DISABLED lehnte die SNIP Verbindungen auf Port 443 und Port 22 (SSH) sofort ab, und der grep von oben lieferte für sie nichts mehr. Das ist der einfachste Schritt, weil keine ACL-Reihenfolge zu beachten ist. Vorher klären, ob Monitoring oder Automatisierung über diese SNIP auf den NetScaler zugreifen.

2. HTTP auf der NSIP abschalten

set ns ip <NSIP> -gui SECUREONLY

An der Testinstanz wurde HTTP auf Port 80 damit sofort abgelehnt („Verbindung verweigert“), HTTPS lief weiter. Das Beispiel im Citrix-Blog erlaubt Port 80 noch für den Admin-Rechner. Mit SECUREONLY ist Port 80 für alle zu, und die ACLs brauchen nur noch Port 443.

3. Vor dem Sperren klären, wer auf das Management zugreift

Eine Sperre trifft jeden, der nicht erlaubt ist. Diese Quellen gehören deshalb in die ALLOW-Regeln:

• NetScaler Console (früher ADM), sonst fallen Lizenzierung und zentrale Verwaltung aus
• Monitoring und Automatisierung, die per NITRO oder GUI zugreifen
• in einer HA-Paarung die NSIP des Partners, im GSLB die anderen Standorte (CTX228148 nennt dafür die Ports 3008 bis 3010)

Dazu gehört ein Rückweg, falls eine Regel doch zu viel sperrt: die Konsole der VPX im Hypervisor oder der serielle bzw. LOM-Zugang bei MPX.

4. ACLs: Admin-Netz erlauben, Rest sperren

Die Extended ACLs des NetScaler arbeiten nach Priorität, die kleinste Zahl gilt zuerst. Zuerst kommt die Erlaubnis für das Admin-Netz, danach die Sperre für alle anderen. Ein Bereich wird als Start-IP-End-IP angegeben. 10.10.20.10-10.10.20.40 ist hier ein Beispiel für das Admin-Netz:

add ns acl allow_mgmt_443 ALLOW -srcIP = 10.10.20.10-10.10.20.40 -destIP = <NSIP> -destPort = 443 -protocol TCP -priority 10
add ns acl deny_mgmt_443 DENY -destIP = <NSIP> -destPort = 443 -protocol TCP -priority 20
apply ns acls

Weitere Management-Adressen bekommen dasselbe Paar aus Erlaubnis und Sperre, jeweils mit eigener -destIP: SNIPs mit Management-Zugriff und im Cluster die Cluster-IP. Bei einer SNIP nur Port 443 und nur deren Adresse sperren, denn über SNIPs läuft auch Verkehr zu den Backends.

Die ACLs wirken erst nach apply ns acls. Vorher zeigt show ns acl bei jeder Regel Applied Status: NOTAPPLIED. Dasselbe gilt für jede spätere Änderung, der NetScaler meldet dann „ACL modified, apply ACLs to activate change“. Auch ein rm ns acl ist erst nach apply ns acls vollzogen: Ein sofortiges add mit demselben Namen scheitert mit „Resource already exists“. Eine Regel ändern heißt deshalb rm, apply ns acls, add, apply ns acls.

Ein Paket, auf das keine ACL passt, lässt der NetScaler laut Citrix-Dokumentation durch. Gesperrt wird also nur, was eine DENY-Regel ausdrücklich trifft. Soll auch SSH nur aus dem Admin-Netz gehen, bekommt Port 22 dasselbe Paar aus Erlaubnis und Sperre. Der Parameter implicitACLAllow (show l3param, ab Werk ENABLED) nimmt den internen Verkehr des NetScaler von den ACLs aus. Er bleibt, wie er ist.

Zum Beispiel im Citrix-Blog: Der Befehl add ns acl <Name> ALLOW -srcIP <Start_IP>-<End_IP> -priority <Nummer> enthält kein Ziel, keinen Port und kein Protokoll. Angelegt zeigt show ns acl bei dieser Regel ein leeres destIP und ein leeres Protocol. Die Regel erlaubt dem Bereich damit jeden Verkehr zu jeder Adresse des NetScaler. Mit kleinerer Prioritätszahl als die Sperren hob sie an der Testinstanz beide DENY-Regeln auf: NSIP und SNIP waren von diesem Bereich aus wieder über Port 443 erreichbar. Für das Management reicht die Form mit -destIP und -destPort von oben.

5. Testen und speichern

An der Testinstanz lief HTTPS vom erlaubten Admin-Rechner während des Tests ohne Unterbrechung weiter. Ohne passende ALLOW-Regel lief derselbe Rechner auf Port 443 in den Timeout: Der NetScaler verwirft gesperrte Pakete, statt sie abzulehnen. Ein Browser außerhalb des Admin-Netzes wartet deshalb, bis er aufgibt. SSH auf Port 22 blieb in allen Phasen erreichbar, weil keine Regel diesen Port betraf. Ob eine Regel greift, zeigt der Zähler Hits:

show ns acl allow_mgmt_443

Erst wenn alle Zugriffe wie erwartet laufen, wird gespeichert:

save ns config

Solange nicht gespeichert ist, stehen die ACLs nur in der laufenden Konfiguration. An der Testinstanz stand eine aktive ACL nach apply ns acls in show ns runningConfig, aber weder in show ns savedConfig noch in der Datei /nsconfig/ns.conf. Aus dieser Datei lädt der NetScaler seine Konfiguration beim Start. Nach einem Kaltstart der Testinstanz war die nicht gespeicherte ACL nicht mehr vorhanden, ebenso eine zum Vergleich angelegte, nicht gespeicherte PBR (Policy Based Route).

Und IPv6?

ACLs für IPv4 gelten nicht für IPv6. Deshalb lohnt ein Blick, ob der NetScaler IPv6-Adressen mit Management-Zugriff hat. Dieser Befehl listet alle IPv6-Adressen mit Typ, Bereich und Zustand:

show ns ip6

Auf meiner Testinstanz steht dort eine link-local-Adresse (fe80::…) vom Typ NSIP. Sie ist in der laufenden und in der gespeicherten Konfiguration mit -mgmtAccess ENABLED eingetragen:

   IPv6 Address      Traffic Domain  Vlan  Type  Scope       State
1) fe80::…/64        0               1     NSIP  link-local  TENTATIVE

In Betrieb ist sie dort nicht, der Zustand ist TENTATIVE. Nach RFC 4862 ist das eine Adresse, deren Eindeutigkeit im Netz noch geprüft wird. Sie ist der Schnittstelle noch nicht zugewiesen, andere Pakete an sie werden verworfen. Link-local-Adressen werden außerdem nicht geroutet, sie sind nur aus demselben Netzsegment erreichbar.

show ns ip6 <Adresse> zeigt Management access und Gui wie bei IPv4. Eine IPv6-Adresse mit Management-Zugriff, die nicht im Zustand TENTATIVE steht, braucht eigene IPv6-ACLs. Die Befehle heißen acl6, der Rest ist gleich:

add ns acl6 allow_mgmt6_443 ALLOW -srcIPv6 = <Admin-IPv6> -destIPv6 = <NSIP-IPv6> -destPort = 443 -protocol TCP -priority 10
add ns acl6 deny_mgmt6_443 DENY -destIPv6 = <NSIP-IPv6> -destPort = 443 -protocol TCP -priority 20
apply ns acls6

An der Testinstanz liefen die Befehle fehlerfrei durch. Die Wirkung habe ich nicht gemessen, weil die IPv6-NSIP dort nicht in Betrieb ist.

Kommt ein weiteres Firmware-Update?

Ja. Citrix schreibt, dass es das PHP-Paket des NetScaler auf eine korrigierte Version anhebt und den Blog aktualisiert, sobald der Fix verfügbar ist. Ein Datum nennt Citrix nicht. Die ACLs verkleinern nur den Kreis derer, die die Oberfläche erreichen. Behoben ist die Lücke erst mit diesem Build.

Stand 22.10.2026 vormittags sind die neuesten Builds im Download-Bereich von Citrix weiterhin die vom 8. Oktober: 14.1-73.46, 13.1-64.29 und 13.1-37.283 FIPS. Sie enthalten die Korrektur nicht, Citrix nennt alle unterstützten Versionen als betroffen.

PHP selbst hat am 21. Oktober die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Auf meiner Testinstanz (14.1-72.61) zeigt shell php -v jedoch:

PHP 8.1.33 (cli) (built: Jun 23 2026 20:48:44) (NTS)

Für den Zweig 8.1 gibt es von PHP keine regulären Updates mehr. Für diesen Fall hat das PHP-Projekt laut Rapid7 eingeschränkte Korrekturen im Quellcode für 7.4, 8.0 und 8.1 bereitgestellt. Citrix muss die Korrektur also in sein PHP 8.1 übernehmen oder den NetScaler auf einen neueren PHP-Zweig heben. Ob 14.1-73.46 dieselbe PHP-Version mitbringt, habe ich nicht verifiziert.

Die Management-Oberfläche läuft auf der Testinstanz als Apache-Modul (mod_php, eingebunden in /etc/httpd.conf). Auch dieses Modul, /libexec/libphp.so, trägt die Kennung PHP/8.1.33. Diese Betriebsart hält das PHP-Projekt laut Rapid7 für die mit dem höchsten Risiko, weil ein Angriff dort greifen kann, bevor Anwendungscode läuft.

Für die Planung heißt das:

• Wartungsfenster für die nächsten Tage vormerken. Es wäre das vierte NetScaler-Update seit dem 27. September, nach CTX697096, CTX697174 und CTX697191.
• Appliances unter 14.1-73.46 bzw. 13.1-64.29 nicht auf den PHP-Build warten lassen. Der aktuelle Build schließt die drei Bulletins seit September. Der PHP-Fix kommt dann als weiterer Schritt dazu.
• Die ACLs nach dem Update stehen lassen. Ein Management-Zugang, der nur aus dem Admin-Netz erreichbar ist, hilft auch bei der nächsten Lücke in der Oberfläche.

Änderungen an der PHP-Konfiguration der Appliance nennt Citrix nicht als Maßnahme. Den Fix-Build trage ich hier und in der Übersicht NetScaler-Builds und Sicherheitsstand nach, sobald Citrix ihn veröffentlicht.

Was du dir merkst

CVE-2026-109618 und CVE-2026-109619 erreichen den NetScaler über die PHP-Management-Oberfläche auf NSIP, Management-SNIPs und Cluster-IP. Einen behobenen Build gibt es noch nicht.

Bis dahin: Management-Zugriff auf SNIPs abschalten, -gui SECUREONLY setzen, Port 443 per ACL auf das Admin-Netz beschränken, apply ns acls nicht vergessen und mit show ns ip6 die IPv6-Adressen prüfen. Ein weiteres Firmware-Update ist angekündigt, ein Wartungsfenster dafür gehört jetzt in die Planung.

Quellen

• Protecting NetScaler Management Access from PHP CVE-2026-109618 & CVE-2026-109619, Citrix, 21.10.2026
• CTX228148: How to Restrict NetScaler Management Interfaces with ACLs, Citrix
• Access Control Lists (ACLs) und Blocking traffic on internal ports, NetScaler-Dokumentation
• System basic operations, NetScaler-Dokumentation (Speichern der Konfiguration in /nsconfig/ns.conf)
• RFC 4862: IPv6 Stateless Address Autoconfiguration, Abschnitte 2 und 5.4
• CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP, Rapid7, 21.10.2026
• CVE-2026-109618 and CVE-2026-109619 affecting PHP, NCSC Neuseeland, 22.10.2026
• Known Exploited Vulnerabilities Catalog, CISA

---

Stand dieses Beitrags: 22.10.2026. Neue Builds oder Hinweise von Citrix trage ich datiert am Kopf des betroffenen Abschnitts nach, statt den Text still zu korrigieren.