NetScaler Architecture
With the recent NetScaler security bulletins, zero-days, and patches, I’ve been thinking about NetScaler architecture quite a bit.
A lot of environments have NetScalers that either exist in the private network with a public-facing NAT, or NetScalers that are dual legged (one in a DMZ, one in the private), also with publicly exposed NATs or virtual servers. Even the more secure DMZ-only or dual-DMZ deployments often have a management interface in a private management network.
Considering the severity of the recent vulnerabilities and attacks, I’m recommending that any external-facing NetScaler exist only in a DMZ. This includes the management interface.
The Risk:
If any interface of the NetScaler exists in a private or management network adjacent to internal resources, once compromised, the attackers can move laterally to any system with direct access. In the modern world, the risk is just too great to allow this architecture to continue.
The Solution:
Architecture:
I recommend re-architecting all existing public-facing NetScalers to exist only in a DMZ. I also recommend considering creating a separate DMZ just for NetScaler. That way, if it is compromised, the attackers can’t get any other sensitive systems.
Configuration:
Once compromised, attackers gain access to stored SSL certificates, credentials used to access the management interface, and credentials that flow through the NetScaler. Therefore, I recommend the following key points:
1 Admin Credentials: Remove any internal LDAP authentication for management and create local admin accounts on the NetScaler(s). This way, the attacker couldn’t gain access to the username/password of internal AD admin accounts
o Naming & Password: Name the accounts differently from any internal Admin account names, and use a separate password
2. User Authentication: For years, I’ve been recommending SAML authentication only as the credentials do not flow through the NetScaler and therefore cannot be hijacked (like when using RADIUS or LDAP(S)). However, some of the recent attacks
have been specific to SAML, so even that feels risky. Doing an analysis, it seems 20% of the vulnerabilities of the past year have been SAML-related. With this information, I feel the risk is still lower to use SAML authentication versus to not:
| Initial publication | CVEs | SAMLrelated | Other | Principal attack surfaces |
| Nov. 11, 2025 | CVE-2025- 12101 | 0 | 1 | Cross-site scripting on Gateway/AAA. |
| Mar. 23, 2026 | CVE-2026- 3055, CVE2026-4368 | 1 | 1 | SAML IdP memory overread; Gateway/AAA session race. |
| Jun. 30, 2026 | CVE-2026- 8451, -8452, - 8655, -10816, -10817, - | 1 | 5 | SAML IdP; Gateway/AAA; Oracle LB/DNS; management interface; TCP timestamps; HTTP/2. |
| Aug. 19, 2026 | CVE-2026- 19489, -19490 | 1* | 1 | SIP ALG/LSN; conditional SAML/Gateway authentication bypass. |
| Sep. 27, 2026 | CVE-2026- 88771 through -88778 | 0 | 8 | Default configuration, DTLS, HTTP, policy expressions, Gateway/AAA, Oracle LB, non-HTTP L7, and TCP ISN generation. |
| Oct. 4, 2026 | CVE-2026- 88779 | 1 | 0 | SAML SP or SAML IdP memory-overflow denial of service. |
| Total | 20 | 4 | 16 |
3· Wildcard Certificates: Remove any wildcard certificates from the NetScaler, and purchase individually generated SSL certificates. If a NetScaler is compromised, the attacker could potentially obtain the private key to a wildcard certificate and then decrypt any other traffic that uses the wildcard.
4· Secure Deployment Guide: Follow the recommendations from Citrix in their NetScaler Secure Deployment Guide.
Migration Strategies
Thinking about the deployments I’ve worked on recently, it seems there are three migration strategies that an organization can take:
| Strategy | Risk / Downtime | Effort | Benefits |
| In-place move | Mid-high | Mid-low | 1. Minimal config changes 2. Faster time to deploy |
| Migrate all config | Low | Mid | 1. Low downtime 2. Migrate in-place with full testing |
| Migrate & Clean-up | Low | High | 1. Only migrate active services 2. Perform a clean-up of unused services |
Migration Details
With all the above strategies, the key change will be to identify which ports and protocols need to be opened between the NetScaler and the back-end services as the traffic flows from the DMZ to the private network. Here is a typical list of back-end services and firewall rules that need to be in place. We can also help you determine the full list for your environment. See the following article for common ports & protocols used by Citrix: https://community.citrix.com/tech-zone/build/tech-papers/citrix-communication-ports/
| Source IP | Protocol: Port | Destination IP | Description |
| NetScaler SNIP | TCP:443 | StoreFront Delivery Controllers | StoreFront Web traffic STA Ticketing |
| NetScaler SNIP | TCP/UDP: 1494, 2598 | All VDAs | Citrix HDX traffic |
| NetScaler SNIP | TCP:636 | LDAPs Servers | Only when LDAP is used for user authentication (not recommended) SNIP source when a LB VIP exists for LDAP, otherwise NSIP |
| NetScaler SNIP | UDP:1812 | RADIUS Servers | Only when RADIUS is used for user authentication (not recommended) SNIP source when a LB VIP exists for RADIUS, otherwise NSIP |
| NetScaler SNIP | UDP:512, 162 | Syslog Servers SNMP Servers | System Logging & monitoring when present |
Summary
NetScaler has been the front end for Citrix environments for decades now. It has served as a key component to allow remote access for external users into a Citrix environment, as well as provide L7 load balancing for applications. With the key role it plays, and the level of access historically granted to NetScalers, it’s critical to take these vulnerabilities seriously, apply patches right away, and I think to re-architect the NetScaler as outlined to minimize the attack surface and risk.