What Citrix disclosed
Citrix's September 27, 2026 bulletin reported exploitation in the wild of CVE-2026-88771 and CVE-2026-88772. The first permits unauthenticated command execution on affected appliances, including appliances running a default configuration. The second affects configurations that use Datagram Transport Layer Security (DTLS). Further advisories on October 3 and October 8 addressed additional flaws in SAML configurations, which let attackers run arbitrary scripts on target machines and carry out denial of service attacks.
CISA's alert and Mandiant's technical investigation cover the vulnerabilities, the observed exploitation and response guidance in more detail. Cloudflare's emergency WAF release for CVE-2026-88771 documents the available web application protection. If you are a NetScaler customer who has not patched yet, do that before reading further — this was a bad one.
Because existing deployments are already known to be public, the WAF only buys time and reacts to exploits already seen. New variants are being turned up faster with AI, which is why a layered approach matters more than any single emergency rule.
Why the gateway has to be exposed at all
In a standard Citrix deployment, the user authenticates through NetScaler Gateway, which passes the request through a secure ticket authority to StoreFront. StoreFront presents the applications and desktops available to that user, and the native Citrix client then opens a separate connection over Citrix's Independent Computing Architecture (ICA) protocol. The gateway validates the ticket before it proxies the desktop connection; Citrix documents these as distinct stages of the connection workflow. The defect class exists because the gateway must remain reachable from the Internet for users to start a session in the first place.
Move the access decision ahead of the login page
Cloudflare Access evaluates an independent access policy before a request ever reaches the existing gateway, while the Citrix environment still decides which desktop a user can launch and still validates the session ticket. An attacker probing the gateway sees only the Access login page and never reaches the server to attempt a specific exploit. The decision rests on Zero Trust policy — whether a given person should be there at all — rather than on matching an exploit signature.
This boundary only covers the web authentication path. Other gateway services, including DTLS-enabled listeners, are not extended automatically and still need their own exposure review and the applicable security updates, even where the desktop sessions they support already require authentication.
Close the origin bypass
Re-pointing DNS and writing Access policies is not sufficient. Access enforcement is tied to a hostname, so if the authentication server is also reachable by IP address or through another hostname, the policy can be sidestepped entirely. Every request that reaches the origin must be traceable back to Access validation. Which mechanism fits depends on the internal architecture:
- Cloudflare Tunnel — the usual choice. It creates an outbound-only tunnel from the application server so all inbound IP traffic can be closed and no publicly reachable IP remains.
- Dedicated CDN Egress IPs — for cases where a public origin IP must stay or no connector can be installed. The account gets its own source addresses, and the server firewall admits those and drops everything else, narrowing the allowance to that account's traffic rather than Cloudflare's shared ranges.
- Authenticated Origin Pulls — adds mutual TLS to verify the Cloudflare-to-origin connection.
- Access JWT validation — an origin that supports it should verify the token's signature, issuer, expiry and intended application audience. This is the strongest guarantee that Access actually authenticated the request.
If you are unsure where to start, a Cloudflare expert can review your architecture and identify which controls fit your environment.
Layer web inspection on the protected service
Access governs who may reach the web application; the WAF inspects the HTTP requests aimed at that same protected service. It runs ahead of Access authentication, which makes it possible to block known malicious IPs, specific countries, ASNs or other attributes outright. Inspection runs continuously on every request and will also catch authenticated users trying to run exploits with known CVE signatures.
WAF Attack Score supplements managed signatures with machine learning, flagging requests that look malicious without matching a known rule. Administrators can use the score in rules that block or challenge. It draws on observations from Cloudflare's global network traffic, and Cloudforce One investigations feed Cloudflare's shared threat-intelligence platform. Subscribers to Cloudforce One threat intelligence can additionally build live threat indicators into WAF policies, adding context about known malicious sources to the inspection of the request itself.
A WAF does nothing against an attacker who already holds a foothold. Patch first, then follow Citrix's suspected-compromise guidance, which covers preserving evidence, revoking credentials and certificates, investigating connected systems and rebuilding or restoring from a known-good state.
Beyond the login page
Protecting web authentication is a starting point, not the final architecture. Cloudflare's Zero Trust architecture for virtual desktops can also govern access to the desktop infrastructure itself: with the Cloudflare One Client and private-network connectivity, teams restrict which users and devices may reach the endpoints carrying desktop traffic, including an existing ICA path. That requires its own routing and policy design and is not something the browser-based authentication proxy provides on its own.
Some workflows can drop the ICA dependency instead. For supported Windows workloads, browser-based remote desktop access reaches a Windows host through Cloudflare Tunnel with no local remote desktop client. Where users only need a desktop to open web applications, Access plus Browser Isolation can serve that use case without a full virtual desktop. The order of operations: protect the authentication service and existing desktop connections first, then retire virtual desktops used only for web access, then move supported Windows workflows to browser-based remote desktops. Reducing exposure does not have to wait for a migration to finish.
The same reasoning applies well outside NetScaler. Remote desktop portals, administrative consoles and any other Internet-facing authentication page deserve the same two questions: does the intended audience really need unrestricted Internet reachability, and can an attacker skip the authentication check and still reach the application server?
Beyond virtual desktops
The same reasoning that applies to virtual desktop services extends to other employee-facing systems. An employee portal or a management console may be reachable by approved users from anywhere without accepting application requests from the whole internet.
Some authentication pages cannot require an employee identity up front. Consumer login pages and the identity-provider endpoints used to establish an initial session may need to stay publicly reachable. Protect them deliberately and avoid circular authentication dependencies, so reachability is a design decision rather than an inherited default.
Validating the boundary on one restricted service
Begin with a single service. Map its web and non-web paths into the protected configuration, then place the access decision ahead of its authentication surface. Confirm the boundary in your own environment before expanding the rollout:
- Request the protected hostname without signing in. Confirm the request stops at Cloudflare rather than reaching the origin.
- Sign in with a test account outside the permitted group. Confirm it still cannot reach the protected application.
- Test direct-origin addresses and alternate hostnames. Confirm none bypasses the access policy.
- Sign in as an approved user. Confirm authentication, desktop launch, and session reconnection still work.
Verify the results against the relevant policy, firewall, and origin logs rather than the browser alone. Re-run these checks whenever routing, identity, or failover settings change, so a later configuration update does not silently reopen the closed path.
Combined architecture
The complete design places access decisions, web inspection, and availability controls ahead of NetScaler, and restricts the connection to the origin. The public origin and Tunnel paths are alternatives to one another. The native desktop connection remains separate, with an optional Zero Trust network access layer around that traffic.
Andrei Migia, Nathan Sackett, and Doug Shepherd contributed to the original post.
