I’d expect a new NetScaler build from Citrix, as N...
# citrix-netscalers
Stu Carroll
10/21/2026, 9:19 AMI’d expect a new NetScaler build from Citrix, as NetScaler runs its own build of PHP. From what I can see on a fresh 14.1 appliance I just spun up, PHP is only used by the admin UI on the NSIP, which we should all be restricting anyway. The packet engine can forward certain paths to an internal Apache vhost, as we saw in CVE-2019-19781, but it looks like that vhost has PHP switched off, which reduces the risk of exposure via VIPs. All speculative until we hear from Citrix, but I would hope the impact to NetScaler customers is that they continue not to expose NSIP or SNIPs with management enabled, and patch quickly.
👍 2
👍🏻 1
f
Frank Vandebergh
10/21/2026, 10:13 AMOn some netscaler builds there are php files in netscaler portal / logonpoint related directories. On some linux instances there are php files related to websockets functionality, ..
It would be great if Citrix could confirm whether AAA / gateway portal could be impacted. Communication… 🤷♂️
💯 3
s
Stu Carroll
10/21/2026, 10:58 AMTotally, communication is key! I’ve only been looking at a fresh 14.1 VPX this morning, so would need to look at other builds, but on this one I can’t find any PHP under the portal or logon directories. I checked by content as well as filename (grep for <?php) in case anything was hiding under a different extension. I can only see PHP in the admin UI under admin_ui, and /netscaler/websocketd.
The websocketd files are a separate PHP service that’s only accessible locally (listens on loopback 9999) and is only called by the Admin UI backend for the web SSH console. It’s likely still vulnerable as it’s the same PHP build, and it runs as root, but as it’s only reachable locally and post-auth on the management interface, so still serious but it should be a reduced risk on most deployment.
If you’ve seen PHP under portal/logon paths on other builds I’d be interested in which builds# so I can have a nose around.
(edit: my test build is NS14.1: Build 73.46.nc)
Stu Carroll
10/21/2026, 2:12 PMAfter looking at the update from PHP, it looks like the vulnerability should still be restricted to the admin interface, but it’s pre auth on the admin UI so easier to exploit but again, management interfaces access should be restricted as best practise.
The bugs are in PHP’s request parsing, which runs before the login page, so an attacked only needs access to a management interface (NSIP or SNIP with MGMT enabled).
php.ini settings on my fresh build 14.1 appliance (memory_limit 1084M, post_max_size 1500M, upload_progress enabled) are not aligned with the mitigations PHP suggest.
Until Citrix publish something, the only practical mitigation would be restricting management access and checking for SNIPs with mgmtAccess enabled.
Stu Carroll
10/21/2026, 3:50 PMCVE-2026-109619 (stale session state): the confirmed trigger is PHP’s session upload-progress feature. I grepped the whole admin UI for upload_progress and PHP_SESSION_UPLOAD_PROGRESS and nothing references it, so setting session.upload_progress.enabled = 0 in /usr/local/lib/php.ini and restarting httpd disables the vulnerable feature with no impact on the GUI. Obviously this is Unsupported and needs re-applying from rc.netscaler to survive a reboot, but low risk pending patch release.
CVE-2026-109618 (OOM corruption): I'd hesitate to try mitigation on NetScaler. PHP’s advice is memory_limit = -1 or a small post_max_size, and both have side effects on the box (potential RAM exhaustion or broken firmware upload). Attack works by driving PHP into its memory limit, which should be logged in /var/log/httperror.log as “Allowed memory size exhausted”. Something to keep an eye out for.
Restricting NSIP access is still the way forward ahead of a patch release, but we were all doing this anyway 🙂
3 Views