Heads-up! NetScaler and the PHP „php2shell“ vulnerabilities (CVE-2026-109618/109619): Exposure and Workaround / Betroffenheit und Workaround

Deutsche Version: weiter unten

NetScaler and the PHP „php2shell“ vulnerabilities

Today, 21 October 2026, the PHP project releases fixes for two critical remote code execution vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619, rated CVSS v4.0 9.2 each. The fixed releases (8.5.12, 8.4.27, 8.3.36 and 8.2.35) were published on 21 October 2026 at 14:00 UTC. NetScaler ADC and NetScaler Gateway 14.1 ship PHP 8.1.34, which is end of life: there is no 8.1 release, but the PHP security team published a minimal source backport branch (PHP-8.1-CVE-2026-109618-109619), so a fixed NetScaler build is a matter of Citrix building it in.

This morning several customers asked us the same question: How badly is my NetScaler affected? Is it only the management GUI, or also my Gateway? We took one of our lab appliances (NetScaler 14.1 Build 73.30) and tested it end to end. This post summarizes what we found and the workaround we validated.

Update, 21 October 2026, 22:00 CEST: the official PHP advisory was published at 16:00 CEST and this post has been revised against it. The technical description below now follows the advisory, and the workaround was re-validated against it, including two real reboots of the lab appliance. Citrix / Cloud Software Group has still not released a statement.

Problem Overview

According to the official advisory, CVE-2026-109618 is memory corruption when PHP runs out of memory while a request is still being set up; every confirmed trigger is a multipart/form-data request. CVE-2026-109619 is request state that survives in the worker and is reused by the next request; session.upload_progress is one of the confirmed paths. PHP parses the request body at request startup, before any script runs and before any authentication takes place, and names mod_php as the highest-risk configuration. Any URL handled by PHP is therefore an entry point. The application does not have to accept file uploads at all, and file_uploads = Off does not help.

On NetScaler, PHP runs as mod_php inside the internal Apache that serves the management GUI and the NITRO API. The Gateway portal is served by a second Apache virtual host on the same process, with PHP disabled.

Who is affected?

We probed the appliance with harmless requests (GET, URL-encoded POST and multipart POST, no exploit code) and checked on the appliance which requests reached Apache and PHP:

• NSIP (management GUI and NITRO, ports 80 and 443): affected. Multipart POSTs to the login page (/), to /login/ and to the whole NITRO API (/nitro/*) reach PHP without authentication.
• SNIP with management access enabled: affected, exactly like the NSIP.
• NetScaler Gateway virtual server: not affected. Authentication (/cgi/login, nFactor, /p/u/doAuthentication.do) is handled by the packet engine. The portal virtual host serves static files only, with php_flag engine off and .php denied. Management paths sent to the Gateway VIP are answered with a redirect to the logon page and never reach the GUI. In our tests not a single POST sent to the Gateway VIP reached Apache.
• AAA virtual server: not affected, same results as the Gateway.
• Load Balancing / Content Switching virtual servers: not affected.
• VIP with management access enabled: not affected. On a VIP only SNMP can be enabled, the GUI cannot.

Two more findings that matter for the mitigation:

• The built-in management GUI WAF (WafProtection DEFAULT on recent 14.1 builds) blocks multipart requests to /login/do_login, /menu/* and /rapi/*, but not to /, /login/ and /nitro/*. It narrows the attack surface, but does not close it.
• Responder, Rewrite or AppFW policies bound globally are not evaluated for management traffic to the NSIP. We bound a responder policy to REQ_OVERRIDE and REQ_DEFAULT: zero hits, all requests still reached PHP. So the usual „quick responder policy“ does not help here.

In short: the assumption „PHP is only used for the management GUI on the NSIP, not for the Gateway“ is correct. The exposure is the NSIP and every SNIP with management access, including the NITRO API that is often opened for automation and monitoring.

Workaround

Until Citrix ships a build with a patched PHP, we recommend three layers. Layer 1 is supported, persistent and mandatory: after a cold reboot, httpd starts with the stock configuration and the block from step 4 needs about a minute to re-apply steps 2 and 3 (67 seconds measured in our lab, longer on appliances with large configurations). In that minute only the ACLs and the built-in GUI WAF protect the PHP entry points. Layers 2 and 3 modify files on the appliance that are not part of the NetScaler configuration; they are unsupported customizations and must be re-applied after every reboot and firmware upgrade (step 4 does that for you).

Step 1: Restrict access to the management IPs with ACLs

Extended ACLs are evaluated by the packet engine for all traffic to the appliance, including the NSIP, unlike policies. Allow your admin networks (and NetScaler Console agents, monitoring and automation hosts) and deny the rest on ports 80 and 443. SSH is deliberately left out, so you can always roll back.

add ns acl acl_mgmt_https_admin ALLOW -srcIP <ADMIN-FIRST>-<ADMIN-LAST> -destIP <NSIP> -protocol TCP -destPort 443 -priority 100
add ns acl acl_mgmt_http_admin  ALLOW -srcIP <ADMIN-FIRST>-<ADMIN-LAST> -destIP <NSIP> -protocol TCP -destPort 80  -priority 110
add ns acl acl_mgmt_https_deny  DENY  -destIP <NSIP> -protocol TCP -destPort 443 -priority 1000
add ns acl acl_mgmt_http_deny   DENY  -destIP <NSIP> -protocol TCP -destPort 80  -priority 1010
apply ns acls
save ns config

Repeat this for every SNIP with management access, or better, remove management access from SNIPs that do not need it (set ns ip <SNIP> -mgmtAccess DISABLED). set ns ip <NSIP> -gui SECUREONLY closes port 80 entirely.

Step 2: Reject multipart requests in Apache before PHP runs

A mod_rewrite rule in the management virtual host is evaluated before the PHP handler. A request that is rejected there never reaches the PHP multipart parser. Save the following snippet as /nsconfig/php2shell-httpd.conf:

    # php2shell-mitigation BEGIN (CVE-2026-109618/109619): reject multipart bodies before PHP runs
    RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$
    RewriteCond %{HTTP:Content-Type} ^\s*multipart/ [NC]
    RewriteRule .* - [F,L]
    # php2shell-mitigation END

Then insert it into /etc/httpd.conf inside <VirtualHost *:80>, right before the RewriteRule ^(/login/.*)$ line, check the syntax and reload Apache gracefully (shell, as nsroot):

cp /etc/httpd.conf /var/tmp/httpd.conf.bak
awk -v f=/nsconfig/php2shell-httpd.conf '/RewriteRule \^\(\/login\/\.\*\)\$/ && !done { while ((getline l < f) > 0) print l; done=1 } { print }' /etc/httpd.conf > /var/tmp/httpd.conf.new
cp /var/tmp/httpd.conf.new /etc/httpd.conf
/bin/httpd -t -f /etc/httpd.conf          # must print "Syntax OK"
/bin/httpd -k graceful -f /etc/httpd.conf  # no session loss

Note: httpd -t without -f /etc/httpd.conf fails on NetScaler, because the compiled-in default path does not exist.

Results in our lab:

• Multipart POSTs to /, /login/ and /nitro/v1/config/login on ports 80 and 443 are answered with 403 by Apache in well under 2 ms, compared to around 10 ms for requests that run through PHP.
• GUI login, GUI navigation and NITRO clients (JSON and URL-encoded) work as before.
• Installing a certificate through the GUI still works: the 14.1 GUI uploads files as JSON through NITRO (/nitro/v1/config/systemfile), not as multipart.
• Checked against the request shapes named in the official advisory (chunked multipart without Content-Length, uppercase Content-Type, other multipart subtypes, PUT, duplicate Content-Type headers): everything Apache sees as multipart/* gets a 403 before PHP runs. The PHP advisory itself lists blocking multipart in front of PHP as a mitigation.

If you prefer to touch only the unauthenticated entry points, add RewriteCond %{REQUEST_URI} ^/(login/|nitro/|$) [NC] as a third condition. This variant leaves the legacy upload endpoints under /menu/* and /rapi/* reachable with multipart, so we recommend the strict variant above.

Step 3: Disable session.upload_progress

This closes the session.upload_progress code path for every PHP request. The NetScaler GUI does not use upload progress.

cp /usr/local/lib/php.ini /var/tmp/php.ini.bak
printf '\n; php2shell-mitigation\nsession.upload_progress.enabled = 0\n' >> /usr/local/lib/php.ini
/bin/httpd -k graceful -f /etc/httpd.conf
/bin/php -i | grep session.upload_progress.enabled   # => Off => Off

Step 4: Make steps 2 and 3 survive a reboot

/etc/httpd.conf and /usr/local/lib/php.ini live on the RAM file system and are rebuilt at boot and on upgrade, while /nsconfig persists. Append this idempotent block to /nsconfig/rc.netscaler:

# php2shell-mitigation BEGIN (CVE-2026-109618/109619, PHP 8.1 EOL). Remove after upgrading to a build with patched PHP.
if [ -f /nsconfig/php2shell-httpd.conf ] && ! grep -q 'php2shell-mitigation BEGIN' /etc/httpd.conf; then
  awk -v f=/nsconfig/php2shell-httpd.conf '/RewriteRule \^\(\/login\/\.\*\)\$/ && !done { while ((getline l < f) > 0) print l; done=1 } { print }' /etc/httpd.conf > /etc/httpd.conf.php2shell && cp /etc/httpd.conf.php2shell /etc/httpd.conf && rm -f /etc/httpd.conf.php2shell
  /bin/httpd -t -f /etc/httpd.conf && /bin/httpd -k graceful -f /etc/httpd.conf
fi
if ! grep -q '^session.upload_progress.enabled' /usr/local/lib/php.ini; then
  printf '\n; php2shell-mitigation\nsession.upload_progress.enabled = 0\n' >> /usr/local/lib/php.ini
  /bin/httpd -k graceful -f /etc/httpd.conf
fi
# php2shell-mitigation END

We verified the block three ways: running it again on a mitigated appliance changes nothing; after a reboot -warm (which restarts the NetScaler software only and rewrites httpd.conf) the block was still in place and there was no window; after a cold reboot the block re-inserted both the Apache rule and the php.ini line on its own, about a minute after the management IP came up (see step 1). After every reboot and firmware upgrade, grep -c php2shell-mitigation /etc/httpd.conf must return 2 and grep -c '^session.upload_progress.enabled' /usr/local/lib/php.ini must return 1. In HA pairs apply steps 2 to 4 on both nodes, /nsconfig/rc.netscaler is not synchronized.

What does not work

• Responder, Rewrite or AppFW policies bound globally: not evaluated for management traffic to the NSIP.
• file_uploads = Off: PHP still parses the multipart body.
• enable_post_data_reading = Off: breaks NITRO clients that send URL-encoded object= bodies.
• Exemptions based on a session cookie: PHP parses the body before any session is validated, so any cookie value would pass.
• Relying on the GUI WAF alone: it only covers the endpoints in its API specification.

Rollback

cp /var/tmp/httpd.conf.bak /etc/httpd.conf
cp /var/tmp/php.ini.bak /usr/local/lib/php.ini
/bin/httpd -t -f /etc/httpd.conf && /bin/httpd -k graceful -f /etc/httpd.conf
rm /nsconfig/php2shell-httpd.conf
# and remove the php2shell-mitigation block from /nsconfig/rc.netscaler

ACLs: rm ns acl <name> for each one, then apply ns acls and save ns config.

Update after the official advisory

• The official PHP advisory confirms that every trigger that fires before a script runs is a multipart request, so step 2 holds. Other paths of CVE-2026-109619 depend on application behaviour; step 3 closes the confirmed one.
• PHP also proposes memory_limit = -1 (set with php_admin_value) as its primary configuration mitigation for CVE-2026-109618. With step 2 in place it is second-order, and on NetScaler it lets a single request consume appliance memory, so we do not include it.
• When opening a case with Citrix Support, point to the official 8.1 backport branch: the fix exists, it only needs to be built in.
• Revision history: 21 October 2026, 15:22 CEST, first version based on pre-release analyses; 22:00 CEST, revised against the official PHP advisory, step 2 re-validated against the advisory’s request shapes, step 4 verified across a warm and a cold reboot, step 1 upgraded to mandatory.

In other words: Lock down the NSIP and every SNIP with management access to your admin networks today, and keep multipart requests away from PHP until Citrix ships a fixed build. Your Gateway, AAA and Load Balancing virtual servers are not the problem this time.

If you have questions or see further improvements, let us know in the comments!

Disclaimer

This workaround is provided for informational purposes only and is offered „as is“ without any express or implied warranties, including but not limited to the implied warranties of merchantability and fitness for a particular purpose.
The workaround modifies files on the NetScaler appliance that are not managed by the NetScaler configuration and is not supported by Citrix. Test it in a lab and align it with Citrix Support before applying it in production.
The user assumes all risk associated with the use of this workaround. The author and/or provider shall not be held liable for any damages resulting from its use, including but not limited to direct, indirect, incidental, or consequential damages.
The information reflects the state of 21 October 2026, 22:00 CEST, after the publication of the official PHP advisory, and may change.
This blog post was drafted with the help of Claude, an AI assistant by Anthropic, based on tests in our lab.

NetScaler und die PHP-Sicherheitslücken „php2shell“

Heute, am 21. Oktober 2026, veröffentlicht das PHP-Projekt Fixes für zwei kritische Remote-Code-Execution-Schwachstellen im PHP-Kern: CVE-2026-109618 und CVE-2026-109619, jeweils mit CVSS v4.0 9.2 bewertet. Die gefixten Releases (8.5.12, 8.4.27, 8.3.36 und 8.2.35) wurden am 21. Oktober 2026 um 14:00 UTC veröffentlicht. NetScaler ADC und NetScaler Gateway 14.1 bringen PHP 8.1.34 mit. Diese Version ist End of Life: Ein 8.1-Release gibt es nicht, das PHP-Security-Team hat aber einen minimalen Source-Backport-Branch (PHP-8.1-CVE-2026-109618-109619) veröffentlicht. Ein gefixter NetScaler-Build ist damit eine Frage des Einbauens durch Citrix.

Heute Morgen haben uns mehrere Kunden dieselbe Frage gestellt: Wie stark ist mein NetScaler betroffen? Nur die Management-GUI oder auch mein Gateway? Wir haben eine unserer Lab-Appliances (NetScaler 14.1 Build 73.30) von Anfang bis Ende getestet. In diesem Beitrag fassen wir die Ergebnisse und den validierten Workaround zusammen.

Update, 21. Oktober 2026, 22:00 Uhr MESZ: Das offizielle PHP-Advisory wurde um 16:00 Uhr MESZ veröffentlicht, und dieser Beitrag wurde daran überarbeitet. Die technische Beschreibung unten folgt jetzt dem Advisory, und der Workaround wurde dagegen erneut validiert, einschließlich zweier echter Neustarts der Lab-Appliance. Citrix / Cloud Software Group hat weiterhin keine Stellungnahme abgegeben.

Problemübersicht

Laut dem offiziellen Advisory ist CVE-2026-109618 eine Speicherkorruption, wenn PHP während des Aufbaus eines Requests der Speicher ausgeht; alle bestätigten Auslöser sind multipart/form-data-Requests. CVE-2026-109619 ist Request-Zustand, der im Worker überlebt und vom nächsten Request wiederverwendet wird; session.upload_progress ist einer der bestätigten Pfade. PHP verarbeitet den Request-Body beim Start des Requests, also bevor ein Skript läuft und bevor eine Authentifizierung stattfindet, und nennt mod_php als die Konfiguration mit dem höchsten Risiko. Damit ist jede URL, die von PHP verarbeitet wird, ein Einstiegspunkt. Die Anwendung muss dafür überhaupt keine Datei-Uploads anbieten, und file_uploads = Off hilft nicht.

Auf dem NetScaler läuft PHP als mod_php im internen Apache, der die Management-GUI und die NITRO-API ausliefert. Das Gateway-Portal wird von einem zweiten virtuellen Host im selben Apache-Prozess ausgeliefert, dort ist PHP deaktiviert.

Wer ist betroffen?

Wir haben die Appliance mit harmlosen Requests getestet (GET, URL-encoded POST und Multipart-POST, kein Exploit-Code) und auf der Appliance geprüft, welche Requests Apache und PHP erreicht haben:

• NSIP (Management-GUI und NITRO, Ports 80 und 443): betroffen. Multipart-POSTs auf die Login-Seite (/), auf /login/ und auf die gesamte NITRO-API (/nitro/*) erreichen PHP ohne Authentifizierung.
• SNIP mit aktiviertem Management Access: betroffen, genau wie die NSIP.
• NetScaler Gateway vServer: nicht betroffen. Die Authentifizierung (/cgi/login, nFactor, /p/u/doAuthentication.do) übernimmt die Packet Engine. Der virtuelle Host des Portals liefert nur statische Dateien aus, mit php_flag engine off und gesperrten .php-Dateien. Management-Pfade an die Gateway-VIP werden mit einer Weiterleitung auf die Logon-Seite beantwortet und erreichen die GUI nie. In unseren Tests hat kein einziger POST an die Gateway-VIP Apache erreicht.
• AAA vServer: nicht betroffen, mit denselben Ergebnissen wie das Gateway.
• Load Balancing / Content Switching vServer: nicht betroffen.
• VIP mit aktiviertem Management Access: nicht betroffen. Auf einer VIP lässt sich nur SNMP aktivieren, die GUI nicht.

Zwei weitere Erkenntnisse, die für die Mitigation wichtig sind:

• Die eingebaute WAF für die Management-GUI (WafProtection DEFAULT auf aktuellen 14.1-Builds) blockiert Multipart-Requests auf /login/do_login, /menu/* und /rapi/*, nicht aber auf /, /login/ und /nitro/*. Sie verkleinert die Angriffsfläche, schließt sie aber nicht.
• Global gebundene Responder-, Rewrite- oder AppFW-Policies werden für Management-Traffic an die NSIP nicht ausgewertet. Wir haben eine Responder-Policy an REQ_OVERRIDE und REQ_DEFAULT gebunden: null Hits, alle Requests haben PHP weiterhin erreicht. Die übliche „schnelle Responder-Policy“ hilft hier also nicht.

Kurz gesagt: Die Annahme „PHP wird nur für die Management-GUI auf der NSIP verwendet, nicht für das Gateway“ ist richtig. Betroffen sind die NSIP und jede SNIP mit Management Access, einschließlich der NITRO-API, die häufig für Automatisierung und Monitoring freigegeben ist.

Workaround

Bis Citrix einen Build mit gepatchtem PHP ausliefert, empfehlen wir drei Ebenen. Ebene 1 ist unterstützt, persistent und verpflichtend: Nach einem Kaltstart startet httpd mit der Standardkonfiguration, und der Block aus Schritt 4 braucht etwa eine Minute, um die Schritte 2 und 3 erneut anzuwenden (67 Sekunden in unserem Lab gemessen, länger bei Appliances mit großen Konfigurationen). In dieser Minute schützen nur die ACLs und die eingebaute GUI-WAF die PHP-Einstiegspunkte. Die Ebenen 2 und 3 verändern Dateien auf der Appliance, die nicht Teil der NetScaler-Konfiguration sind. Es handelt sich um nicht unterstützte Anpassungen, die nach jedem Neustart und jedem Firmware-Upgrade erneut angewendet werden müssen (das übernimmt Schritt 4).

Schritt 1: Zugriff auf die Management-IPs per ACL einschränken

Extended ACLs werden von der Packet Engine für den gesamten Traffic an die Appliance ausgewertet, auch für die NSIP, anders als Policies. Erlauben Sie Ihre Admin-Netze (sowie NetScaler-Console-Agenten, Monitoring- und Automatisierungs-Hosts) und sperren Sie den Rest auf den Ports 80 und 443. SSH bleibt bewusst außen vor, damit Sie jederzeit zurückrollen können.

add ns acl acl_mgmt_https_admin ALLOW -srcIP <ADMIN-FIRST>-<ADMIN-LAST> -destIP <NSIP> -protocol TCP -destPort 443 -priority 100
add ns acl acl_mgmt_http_admin  ALLOW -srcIP <ADMIN-FIRST>-<ADMIN-LAST> -destIP <NSIP> -protocol TCP -destPort 80  -priority 110
add ns acl acl_mgmt_https_deny  DENY  -destIP <NSIP> -protocol TCP -destPort 443 -priority 1000
add ns acl acl_mgmt_http_deny   DENY  -destIP <NSIP> -protocol TCP -destPort 80  -priority 1010
apply ns acls
save ns config

Wiederholen Sie das für jede SNIP mit Management Access, oder besser: Deaktivieren Sie den Management Access auf SNIPs, die ihn nicht benötigen (set ns ip <SNIP> -mgmtAccess DISABLED). set ns ip <NSIP> -gui SECUREONLY schließt Port 80 vollständig.

Schritt 2: Multipart-Requests in Apache abweisen, bevor PHP läuft

Eine mod_rewrite-Regel im virtuellen Host des Managements wird vor dem PHP-Handler ausgewertet. Ein dort abgewiesener Request erreicht den Multipart-Parser von PHP nie. Speichern Sie das folgende Snippet als /nsconfig/php2shell-httpd.conf:

    # php2shell-mitigation BEGIN (CVE-2026-109618/109619): reject multipart bodies before PHP runs
    RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$
    RewriteCond %{HTTP:Content-Type} ^\s*multipart/ [NC]
    RewriteRule .* - [F,L]
    # php2shell-mitigation END

Fügen Sie es anschließend in /etc/httpd.conf innerhalb von <VirtualHost *:80> direkt vor der Zeile RewriteRule ^(/login/.*)$ ein, prüfen Sie die Syntax und laden Sie Apache graceful neu (Shell, als nsroot):

cp /etc/httpd.conf /var/tmp/httpd.conf.bak
awk -v f=/nsconfig/php2shell-httpd.conf '/RewriteRule \^\(\/login\/\.\*\)\$/ && !done { while ((getline l < f) > 0) print l; done=1 } { print }' /etc/httpd.conf > /var/tmp/httpd.conf.new
cp /var/tmp/httpd.conf.new /etc/httpd.conf
/bin/httpd -t -f /etc/httpd.conf          # must print "Syntax OK"
/bin/httpd -k graceful -f /etc/httpd.conf  # no session loss

Hinweis: httpd -t ohne -f /etc/httpd.conf schlägt auf dem NetScaler fehl, weil der einkompilierte Standardpfad nicht existiert.

Ergebnisse in unserem Lab:

• Multipart-POSTs auf /, /login/ und /nitro/v1/config/login auf den Ports 80 und 443 werden von Apache mit 403 beantwortet, in deutlich unter 2 ms. Requests, die durch PHP laufen, brauchen etwa 10 ms.
• GUI-Login, Navigation in der GUI und NITRO-Clients (JSON und URL-encoded) funktionieren wie bisher.
• Das Installieren eines Zertifikats über die GUI funktioniert weiterhin: Die 14.1-GUI lädt Dateien als JSON über NITRO hoch (/nitro/v1/config/systemfile), nicht als Multipart.
• Gegen die im offiziellen Advisory genannten Request-Formen geprüft (chunked Multipart ohne Content-Length, Content-Type in Großbuchstaben, andere Multipart-Subtypen, PUT, doppelte Content-Type-Header): Alles, was Apache als multipart/* sieht, erhält ein 403, bevor PHP läuft. Das PHP-Advisory selbst nennt das Blockieren von Multipart vor PHP als Mitigation.

Wenn Sie nur die nicht authentifizierten Einstiegspunkte abdecken möchten, ergänzen Sie RewriteCond %{REQUEST_URI} ^/(login/|nitro/|$) [NC] als dritte Bedingung. Diese Variante lässt die älteren Upload-Endpunkte unter /menu/* und /rapi/* für Multipart erreichbar. Wir empfehlen daher die strikte Variante oben.

Schritt 3: session.upload_progress deaktivieren

Damit wird der Codepfad von session.upload_progress für jeden PHP-Request geschlossen. Die NetScaler-GUI verwendet Upload Progress nicht.

cp /usr/local/lib/php.ini /var/tmp/php.ini.bak
printf '\n; php2shell-mitigation\nsession.upload_progress.enabled = 0\n' >> /usr/local/lib/php.ini
/bin/httpd -k graceful -f /etc/httpd.conf
/bin/php -i | grep session.upload_progress.enabled   # => Off => Off

Schritt 4: Schritte 2 und 3 über einen Neustart retten

/etc/httpd.conf und /usr/local/lib/php.ini liegen im RAM-Dateisystem und werden beim Booten und beim Upgrade neu erstellt, /nsconfig dagegen bleibt erhalten. Hängen Sie diesen idempotenten Block an /nsconfig/rc.netscaler an:

# php2shell-mitigation BEGIN (CVE-2026-109618/109619, PHP 8.1 EOL). Remove after upgrading to a build with patched PHP.
if [ -f /nsconfig/php2shell-httpd.conf ] && ! grep -q 'php2shell-mitigation BEGIN' /etc/httpd.conf; then
  awk -v f=/nsconfig/php2shell-httpd.conf '/RewriteRule \^\(\/login\/\.\*\)\$/ && !done { while ((getline l < f) > 0) print l; done=1 } { print }' /etc/httpd.conf > /etc/httpd.conf.php2shell && cp /etc/httpd.conf.php2shell /etc/httpd.conf && rm -f /etc/httpd.conf.php2shell
  /bin/httpd -t -f /etc/httpd.conf && /bin/httpd -k graceful -f /etc/httpd.conf
fi
if ! grep -q '^session.upload_progress.enabled' /usr/local/lib/php.ini; then
  printf '\n; php2shell-mitigation\nsession.upload_progress.enabled = 0\n' >> /usr/local/lib/php.ini
  /bin/httpd -k graceful -f /etc/httpd.conf
fi
# php2shell-mitigation END

Wir haben den Block auf drei Arten geprüft: Ein erneutes Ausführen auf einer bereits geschützten Appliance verändert nichts; nach einem reboot -warm (der nur die NetScaler-Software neu startet und httpd.conf neu schreibt) war der Block weiterhin vorhanden, ohne Zeitfenster; nach einem Kaltstart mit reboot hat der Block die Apache-Regel und die php.ini-Zeile selbstständig wieder eingefügt, etwa eine Minute nachdem die Management-IP erreichbar war (siehe Schritt 1). Nach jedem Neustart und jedem Firmware-Upgrade muss grep -c php2shell-mitigation /etc/httpd.conf den Wert 2 und grep -c '^session.upload_progress.enabled' /usr/local/lib/php.ini den Wert 1 liefern. In HA-Paaren wenden Sie die Schritte 2 bis 4 auf beiden Knoten an, da /nsconfig/rc.netscaler nicht synchronisiert wird.

Was nicht funktioniert

• Global gebundene Responder-, Rewrite- oder AppFW-Policies: werden für Management-Traffic an die NSIP nicht ausgewertet.
• file_uploads = Off: PHP verarbeitet den Multipart-Body trotzdem.
• enable_post_data_reading = Off: bricht NITRO-Clients, die URL-encoded object=-Bodies senden.
• Ausnahmen auf Basis eines Session-Cookies: PHP verarbeitet den Body, bevor eine Session geprüft wird, jeder beliebige Cookie-Wert käme also durch.
• Sich allein auf die GUI-WAF zu verlassen: Sie deckt nur die Endpunkte in ihrer API-Spezifikation ab.

Rollback

cp /var/tmp/httpd.conf.bak /etc/httpd.conf
cp /var/tmp/php.ini.bak /usr/local/lib/php.ini
/bin/httpd -t -f /etc/httpd.conf && /bin/httpd -k graceful -f /etc/httpd.conf
rm /nsconfig/php2shell-httpd.conf
# and remove the php2shell-mitigation block from /nsconfig/rc.netscaler

ACLs: rm ns acl <name> für jede einzelne, danach apply ns acls und save ns config.

Update nach dem offiziellen Advisory

• Das offizielle PHP-Advisory bestätigt, dass jeder Auslöser, der vor dem Start eines Skripts greift, ein Multipart-Request ist. Schritt 2 bleibt damit gültig. Weitere Pfade von CVE-2026-109619 hängen vom Verhalten der Anwendung ab; Schritt 3 schließt den bestätigten.
• PHP schlägt außerdem memory_limit = -1 (gesetzt per php_admin_value) als primäre Konfigurations-Mitigation für CVE-2026-109618 vor. Mit Schritt 2 ist das zweitrangig, und auf dem NetScaler könnte ein einzelner Request damit den Speicher der Appliance belegen, daher nehmen wir es nicht auf.
• Verweisen Sie im Case beim Citrix Support auf den offiziellen 8.1-Backport-Branch: Der Fix existiert, er muss nur eingebaut werden.
• Änderungshistorie: 21. Oktober 2026, 15:22 Uhr MESZ, erste Version auf Basis von Vorab-Analysen; 22:00 Uhr MESZ, überarbeitet anhand des offiziellen PHP-Advisorys, Schritt 2 gegen die Request-Formen des Advisorys erneut validiert, Schritt 4 über einen Warm- und einen Kaltstart geprüft, Schritt 1 auf verpflichtend hochgestuft.

Mit anderen Worten: Beschränken Sie die NSIP und jede SNIP mit Management Access noch heute auf Ihre Admin-Netze, und halten Sie Multipart-Requests von PHP fern, bis Citrix einen gefixten Build ausliefert. Ihre Gateway-, AAA- und Load-Balancing-vServer sind dieses Mal nicht das Problem.

Wenn Sie Fragen haben oder weitere Verbesserungen sehen, schreiben Sie es uns gerne in die Kommentare!

Haftungsausschluss

Dieser Workaround dient ausschließlich Informationszwecken und wird „wie besehen“ ohne ausdrückliche oder stillschweigende Gewährleistung bereitgestellt, einschließlich, aber nicht beschränkt auf die stillschweigende Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zweck.
Der Workaround verändert Dateien auf der NetScaler-Appliance, die nicht von der NetScaler-Konfiguration verwaltet werden, und wird von Citrix nicht unterstützt. Testen Sie ihn in einem Lab und stimmen Sie ihn mit dem Citrix Support ab, bevor Sie ihn produktiv einsetzen.
Der Anwender trägt alle Risiken, die mit der Nutzung dieses Workarounds verbunden sind. Der Autor und/oder Anbieter haftet nicht für Schäden, die aus seiner Nutzung entstehen, einschließlich, aber nicht beschränkt auf direkte, indirekte, zufällige oder Folgeschäden.
Die Informationen geben den Stand vom 21. Oktober 2026, 22:00 Uhr MESZ, nach der Veröffentlichung des offiziellen PHP-Advisorys wieder und können sich ändern.
Dieser Beitrag wurde mit Unterstützung von Claude, einem KI-Assistenten von Anthropic, auf Basis von Tests in unserem Lab erstellt.