Cloudflare is telling NetScaler customers that patching the latest Citrix flaws is the floor, not the plan, and it has a product list ready for the rest. The advice is the company's own, so read it as a vendor pitch with a sound premise underneath.
The flaws are real. Citrix's September 27 bulletin reported observed exploitation of CVE-2026-88771 and CVE-2026-88772. The first allows unauthenticated command execution on affected appliances, including in their default configuration. The second affects setups using Datagram Transport Layer Security (DTLS), an encryption protocol. Further advisories on October 3 and October 8 covered more vulnerabilities in SAML configurations. Cloudflare shipped an emergency web application firewall rule on October 1.
Cloudflare's argument is that a firewall rule is reactive, and that AI is speeding up how fast attackers find new variants (its claim, not something it demonstrates). Its fix is to put Cloudflare Access, which enforces an access policy before a request reaches the gateway, in front of the login page. An attacker would see only the Access login, not the NetScaler server.
The catch is that Access enforces by hostname. If the server answers on its raw IP address or an alternate hostname, the policy is bypassed. Cloudflare calls Tunnel, an outbound-only connection from the server that lets you close all inbound traffic, "the most commonly used approach" to prevent that. Where a public IP must stay, the company suggests allowing only dedicated Cloudflare egress addresses at the firewall. It also suggests Authenticated Origin Pulls, which use mutual TLS, a setup where both ends of a connection present certificates instead of only the server. The origin can also check the Access token itself.
My read: the gateway has to be public for users to start desktop sessions, so this approach moves the exposed login rather than removing it, and it adds a second vendor's code to trust. The gain is independence, since one flaw alone no longer opens the door. The post also concedes a limit: protecting the web login does not cover DTLS listeners, which need their own review and updates.
The same question applies to remote desktop portals and admin consoles, which the post names: does the intended audience really need unrestricted Internet reachability?