You open a security advisory, check the affected builds, and realise your evening now includes a NetScaler upgrade. Again. Then come the questions: are we exposed? Has anyone exploited this already? Will patching be enough?

At some point, “what could we use instead?” stops being a passing thought and becomes a perfectly reasonable infrastructure question.

There are ways out. But before installing HAProxy and calling it a day, you need to answer one question: are you replacing a load balancer, or the gateway your Citrix users connect through? The first is usually manageable. The second takes a little more thought.

It is the emergency work that wears teams down

I wouldn't choose a replacement by comparing CVE counts. That tells you very little about your own exposure. An actively exploited flaw in a feature you publish to the internet matters more than a long list of vulnerabilities in features you don't use.

You do not have to go back to 2023 to see the problem. Citrix published CTX697096 on 27 September 2026, covering eight vulnerabilities, CVE-2026-88771 through CVE-2026-88778. CERT-FR relayed it on 28 September. That is the batch teams were dealing with last week.

CVE-2026-88771 allows unauthenticated remote command execution through improper input validation. CVE-2026-88772 is a memory-overflow issue that can lead to remote code execution or denial of service. Both carry a CVSS v4 score of 9.5. CERT-FR reports that Citrix identified active exploitation of both, and the CVE records include their CISA exploited-vulnerability listings. These were not theoretical problems waiting for a convenient maintenance window.

The other six cover HTTP request smuggling, a feature-policy bypass, memory-overflow issues and predictable TCP initial sequence numbers. Those are different failure modes; the exploitation reports for the first two are not evidence that all eight were being exploited.

Then, on 4 October, CTX697174 followed for CVE-2026-88779: another memory-overflow vulnerability, this time causing denial of service, rated 8.7 under CVSS v4. CISA added it to its Known Exploited Vulnerabilities catalogue that day. CERT-FR published its notice on 5 October. This is a denial-of-service issue, not another confirmed RCE.

The build numbers explain the frustration. For the standard 14.1 and 13.1 branches, the September fixes were 14.1-73.37 and 13.1-64.23. The October issue affects builds before 14.1-73.41 and 13.1-64.28. So an appliance upgraded for the September bulletin could still need another upgrade a week later. FIPS and NDcPP branches have separate build references; use the current vendor bulletin for your exact edition.

CERT-FR also relays Citrix's warning that unpatched appliances are vulnerable in their default configuration for the September bulletin. Do not assume an appliance is safe simply because it is not acting as a VPN gateway. Check the actual build and the advisory's conditions.

The response depends on the advisory and your configuration. It may include invalidating sessions and looking for evidence of compromise, as well as upgrading. Not every deployment is affected by every vulnerability.

That work takes time, often at very short notice. If you're considering a replacement, that's the burden worth reducing. Trading one emergency patch routine for another isn't much of an improvement.

Illustration of a network appliance behind a cracked shield, warning signs and successive patches.
Repeated security advisories turn appliance maintenance into emergency work. AI-generated editorial illustration.

What is your NetScaler actually doing?

A NetScaler may balance web applications, terminate TLS, run authentication policies and carry remote Citrix sessions. WAF, GSLB, full VPN and RDP proxy features can add further roles.

These functions do not all need the same replacement. Application delivery has plenty of alternatives; Citrix remote access has more specific requirements.

NetScaler alternatives: private access can reach StoreFront and VDAs directly, or retain an internal Gateway behind VPN or ZTNA for centralised TCP 443 client access.
Choose by role: private access can remove the Gateway, or keep it internal to centralise HDX traffic. TCP 443 applies to client access; backend flows and optional UDP still matter.

For load balancing, the exit is fairly straightforward

If you mainly use virtual servers, health checks and HTTP routing, HAProxy or NGINX are sensible candidates. Another commercial ADC may fit better if you need integrated features and a vendor support contract.

The differences lie in persistence, rewrites, client certificates, TLS settings, health monitors and logging. GSLB and WAF capabilities vary by product, edition and integration.

For a straightforward web application, this can be a much lighter stack than a full ADC appliance. Environments built around extensive NetScaler policies are a different proposition.

HAProxy and NGINX are particularly appealing for focused application delivery rather than an all-in-one access platform. They still need maintenance, but their role can be narrower and easier to understand.

Illustration of a silver rack-mounted application delivery appliance connected to server racks.
Application delivery and Citrix remote access are different jobs. AI-generated editorial illustration.

Citrix Gateway is where “just use a reverse proxy” falls apart

From the user's side, it all looks like one service: log in, click an application, get a desktop. Underneath, reaching StoreFront and establishing an HDX session are different connections.

Putting StoreFront behind HAProxy may make the website accessible. It doesn't provide the authenticated ICA/HDX gateway path to the selected VDA.

A working login page is not a working Citrix remote-access solution. You still need to handle authentication, authorization, ticketing and the session connection correctly. A generic TCP proxy doesn't recreate those Gateway functions, and opening VDA ports to the internet isn't an acceptable shortcut.

Once Gateway is part of the picture, these are the routes I'd consider.

Let Citrix run the HDX gateway

For an eligible Citrix DaaS deployment, Citrix Gateway service offers a documented alternative to running your own NetScaler HDX proxy. Your applications and desktops can stay in your data centre. Moving the gateway doesn't automatically mean moving the workloads.

Citrix documents the migration, and supported Rendezvous configurations can let VDAs connect without sending HDX traffic through Cloud Connectors. Check which Rendezvous version applies to your design. It isn't a switch that makes every connector unnecessary.

The appeal is obvious: that public HDX gateway is no longer your appliance to upgrade. In return, you depend on the service, its network paths and its availability. You also need the right entitlements and a supported identity configuration.

User experience also depends on the network path to the service, the available transports and support for multimedia and peripherals. A managed gateway changes who operates the access layer, not those underlying requirements.

The StoreFront variant needs a closer look

This is an easy detail to miss in the documentation. Gateway service for StoreFront does not necessarily remove NetScaler.

In Citrix's documented on-premises CVAD design, NetScaler still provides remote access to StoreFront and handles authentication, while Gateway service takes the HDX traffic. That can be useful for routing and scale, and may remove the need for a gateway at a satellite location. But your main public login endpoint can still be a NetScaler.

If the aim is to stop maintaining an internet-facing NetScaler, offloading HDX alone hasn't achieved it. Ask where users authenticate as well as where their sessions travel.

The documentation reviewed on 6 October 2026 has specific version and connector requirements. Use the guide for your actual topology and confirm the licensing. The DaaS migration example and the on-premises StoreFront integration are not interchangeable recipes.

Keep Citrix private and change how users reach it

If you control the endpoints, a suitable VPN or ZTNA service can provide private access to StoreFront and the VDAs instead. Citrix is then something users reach through an authorised private connection, rather than through a public NetScaler Gateway.

That can be a good fit if you already run a reliable private-access platform. There are two ways to arrange the Citrix side: let clients reach StoreFront and the VDAs directly, or keep a NetScaler Gateway on the private network as the single Citrix entry point.

With direct access, the private connection needs to carry both the StoreFront web traffic and the HDX sessions to the VDAs. Endpoint identity, MFA, the required TCP and UDP transports, and Workspace and SSO behaviour still matter.

Keeping an internal Gateway is a useful middle ground. Users connect through the VPN or ZTNA service, then reach the private Gateway over TCP 443. The Gateway centralises the ICA/HDX connections, so you do not have to give every client network direct access to the VDA subnets. StoreFront still provides the application catalogue; the Gateway proxies the session traffic.

For TCP-based HDX, the client-facing Citrix access can stay on TCP 443. That does not mean every internal connection uses 443: the Gateway still needs the appropriate connections to StoreFront, the STAs and the VDAs. EDT/DTLS also requires UDP connectivity when enabled. The benefit is fewer client-side firewall openings and a central access point, not the disappearance of all backend rules.

This option keeps NetScaler, but removes the need to expose its Gateway directly to the Internet. It reduces public exposure while retaining the traffic consolidation. The appliance still needs patching and maintenance.

A web-only ZTNA service won't automatically carry native HDX. Nor does a successful federated login guarantee the intended Windows session sign-in behaviour. Check both.

Managed laptops make this approach easier. Contractors, BYOD and devices where you can't install an agent make it more complicated. Browser access needs its own supported design rather than an assumption that it will work the same way.

There is also a fairly obvious catch: if the replacement is another public VPN appliance, somebody still has to maintain it. You may prefer that product, but the emergency-patching problem hasn't magically disappeared.

Illustration of a laptop reaching protected infrastructure through a single locked private access point.
Private access can retain an internal Gateway as a central entry point. AI-generated editorial illustration.

What about a third-party gateway?

I'd be careful here. “Secure gateway” on a product page doesn't tell you whether it can replace Citrix Gateway in your environment. Neither does support for load balancing StoreFront.

The important distinction is explicit support for Citrix: CVAD versions, Workspace clients, authentication, ticketing, HTML5 access and EDT. General-purpose proxying is not equivalent to that integration.

A third-party option belongs in this category only when its Citrix compatibility and support are documented. Without that evidence, calling it a drop-in Gateway replacement would be misleading.

Or decide that Citrix itself is part of the discussion

If you're already reviewing the whole platform, Parallels RAS, Microsoft RDS, Azure Virtual Desktop and Omnissa Horizon are worth considering according to your requirements.

But that's a bigger project. Their gateways don't replace NetScaler in an otherwise unchanged Citrix deployment. You're reviewing application delivery, images, profiles, identity, peripherals, licensing and the way the environment is operated.

This route makes sense when the broader application-delivery platform is under review, rather than when the goal is simply to remove one appliance.

Keeping NetScaler, with a smaller role

There is also a middle ground: move ordinary application delivery elsewhere and retain NetScaler only for the Citrix-specific functions that still justify it. This does not eliminate NetScaler maintenance, but it separates workloads that do not need to share the same appliance.

A smaller deployment is not automatically immune to vulnerabilities. The exposed features, software version and scope of each advisory still matter. A WAF or reverse proxy in front of it is not a universal shield.

Which option fits which need?

  • Load balancing and reverse proxying: HAProxy, NGINX or another ADC are the most direct alternatives.
  • Managed HDX access: Citrix Gateway service fits eligible architectures, with a distinction between replacing the public gateway and merely offloading HDX.
  • Private access from controlled endpoints: a suitable VPN or ZTNA service can provide connectivity to StoreFront and the VDAs without a public NetScaler Gateway.
  • A third-party Citrix gateway: only an explicitly supported ICA/HDX solution belongs here, not any product labelled a secure gateway.
  • A broader platform change: Parallels RAS, RDS, AVD and Omnissa Horizon address the application-delivery platform itself.

There is no single NetScaler replacement

For web traffic, the choice is wide. For Citrix Gateway, the choice is between a managed HDX service, private connectivity, a documented compatible gateway or a different delivery platform.

Two organisations can ask the same question and reach very different answers. One needs a simpler load balancer. The other needs a new way to give people access to their desktops. The useful comparison starts there.

Sources

Documentation checked on 6 October 2026. The September bulletin was published on 27 September and relayed by CERT-FR on 28 September; the next bulletin followed on 4 October. Exploitation status and build references reflect this review. Use current vendor guidance for your exact version and configuration.