JA EN
shiichan

Before the Patch Lands: Guard Your NetScaler Gateway with Cloudflare Access

Cloudflare Blog ★★★★ View Markdown
#cloudflare#security#infrastructure

Hi everyone, it's Shii-chan! Today I found an article about how to protect a NetScaler Gateway when you can't patch right away.

Cloudflare Blog blog.cloudflare.com

What was announced?

The Cloudflare Blog published "There's always a patient zero: Defending the NetScaler front door before the patch".

It starts from Citrix's September 27, 2026 bulletin, which reported active exploitation of two vulnerabilities:

  • CVE-2026-88771: unauthenticated command execution, including on default configurations
  • CVE-2026-88772: affects configurations that use DTLS (Datagram Transport Layer Security)

Citrix's October 3 and October 8 advisories also covered flaws in SAML configurations that allowed arbitrary script execution and denial of service. Cloudflare released an emergency WAF rule for CVE-2026-88771 on October 1.

Why it matters

A NetScaler Gateway has to be reachable from the internet so users can start desktop sessions. That makes the login surface an exposed attack path.

Since this flaw is hit before sign-in, and patching takes time, the article's idea is to move the sign-in decision in front of the vulnerable code.

What changes

Patching every instance comes first. On top of that, the article describes layering Cloudflare in front of the gateway:

  • Cloudflare Access enforces an independent access policy first. Unauthorized visitors only see the Access login page, not the gateway
  • The WAF runs before Access authentication checks, blocking known malicious IPs, countries, or ASNs and inspecting for known CVE signatures, including for authenticated users
  • WAF Attack Score uses machine learning to flag suspicious requests that match no known rule. Cloudforce One subscribers can also use live threat indicators in WAF policies

The Citrix flow stays the same: StoreFront still decides which desktops a user can launch, and the gateway still validates session tickets.

Dive Deep

Lock down the origin

Access only protects a hostname, so someone reaching the origin by IP or another hostname could bypass it. The article suggests:

  • Cloudflare Tunnel (most common): an outbound-only connection, so no inbound public IP is needed
  • Dedicated CDN Egress IPs: the origin firewall allows only your account's dedicated source addresses
  • Authenticated Origin Pulls: mutual TLS to verify Cloudflare-to-origin connections
  • Access JWT validation at the origin: check signature, issuer, expiry, and audience. It's the best way to confirm a request passed Access, but it supplements upstream restrictions rather than replacing them

Extending Zero Trust

  • The Cloudflare One Client and private-network connectivity can restrict which users and devices reach the desktop endpoints, including the ICA path. This needs separate routing and policy design
  • For supported Windows workloads, browser-based remote desktop through Tunnel avoids a local RDP client
  • If users only need a desktop to reach web apps, Access and Browser Isolation can replace that use case without a full virtual desktop

Validation steps

  • Request the protected hostname without signing in, and confirm it stops at Cloudflare
  • Sign in with a test account outside the permitted group, and confirm it can't reach the application
  • Test direct-origin IPs and alternate hostnames, and confirm none bypass Access
  • Sign in as an approved user, and confirm authentication, desktop launch, and reconnection still work

Review policy, firewall, and origin logs, and repeat these checks whenever routing, identity, or failover settings change.

Limitations

  • Protecting the web authentication path doesn't cover other gateway services, such as DTLS-enabled listeners. Those need their own exposure review and updates
  • WAF signatures are reactive. Attack Score helps with variants, but it isn't a guarantee
  • Access reduces exposure but doesn't remove an attacker who already has a foothold. See Citrix's suspected-compromise guidance for evidence preservation, credential and certificate revocation, and rebuilding from a known-good state
  • Some identity-provider endpoints must stay publicly reachable to start sessions, and putting them behind a prior identity check can create circular authentication dependencies
  • Some controls require specific configuration or entitlements
  • The architecture diagram is a logical reference, not a customer deployment or strict processing sequence

Wrap-up

  • CVE-2026-88771 is unauthenticated command execution and is being exploited, so patching comes first
  • Cloudflare Access plus the WAF moves the sign-in decision in front of the vulnerable code
  • Without closing the origin (for example with Tunnel), Access can be bypassed
  • Services beyond the web authentication path, such as DTLS, need separate handling, and a compromised system needs a rebuild

This is for security and infrastructure folks running NetScaler Gateway who need a safer way to buy time until patching is done.

Related posts