---
id: "CVE-2026-88772"
kind: "vulnerability"
aliases: ["CVE-2026-88772"]
title: "Vulnerability in Citrix NetScaler ADC and Citrix NetScaler Gateway"
severity: "critical"
cvss: 9.5
epss: null
exploited: true
status: "open"
category: "vendor"
products: [{"name": "Citrix NetScaler", "fixed": [], "affected": "", "ecosystem": "vendor"}, {"name": "Citrix NetScaler ADC", "fixed": ["14.1-73.37", "13.1-64.23", "14.1-73.37 FIPS", "13.1-37.279 FIPS/NDcPP"], "affected": "< 14.1-73.37; < 13.1-64.23; FIPS < 14.1-73.37; FIPS/NDcPP < 13.1-37.279", "ecosystem": "vendor"}, {"name": "Citrix NetScaler Gateway", "fixed": ["14.1-73.37", "13.1-64.23"], "affected": "< 14.1-73.37; < 13.1-64.23", "ecosystem": "vendor"}, {"name": "citrix netscaler application delivery controller", "fixed": ["13.1-64.23"], "affected": ">= 13.1, < 13.1-64.23", "ecosystem": "vendor"}, {"name": "citrix netscaler application delivery controller", "fixed": ["13.1.37.279"], "affected": ">= 13.1, < 13.1.37.279", "ecosystem": "vendor"}, {"name": "citrix netscaler application delivery controller", "fixed": ["14.1-73.37"], "affected": ">= 14.1, < 14.1-73.37", "ecosystem": "vendor"}, {"name": "citrix netscaler application delivery controller", "fixed": [], "affected": ">= 14.1-66.68, <= 14.1-73.37", "ecosystem": "vendor"}, {"name": "citrix netscaler gateway", "fixed": ["13.1-64.23"], "affected": ">= 13.1, < 13.1-64.23", "ecosystem": "vendor"}, {"name": "citrix netscaler gateway", "fixed": ["14.1-73.37"], "affected": ">= 14.1, < 14.1-73.37", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["citrix-netscaler", "cloudflare", "dtls", "exploited", "lab-disclosure", "netscaler", "netscaler-gateway", "poc-public", "rce", "self-hosted", "vendor"]
not_affected_if: ["dtls-disabled", "managed-hosting"]
published_at: "2026-09-27T00:00:00+00:00"
first_seen_at: "2026-10-23T19:11:50+00:00"
updated_at: "2026-10-24T17:31:07+00:00"
sources: [{"source": "kev", "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-88772", "first_seen_at": "2026-10-23T19:11:50+00:00"}, {"source": "github-poc", "url": "https://github.com/CompleteTech-LLC/netscaler-cve-2026-88772-check", "first_seen_at": "2026-10-23T20:22:16+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T20:27:17+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88772", "first_seen_at": "2026-10-23T23:44:52+00:00"}, {"source": "lab", "url": "https://blog.cloudflare.com/protect-your-netscaler-gateway/", "first_seen_at": "2026-10-24T17:18:15+00:00"}]
---

# Vulnerability in Citrix NetScaler ADC and Citrix NetScaler Gateway

Memory overflow in NetScaler ADC/Gateway DTLS handling leading to unauthenticated RCE or DoS. Only appliances with DTLS enabled are exposed, and DTLS is on by default for VPN vservers. Citrix and CISA confirm exploitation as a zero-day since at least 2026-09-27 (CISA KEV date). Patched in the 14.1-73.37 and 13.1-64.23 lines.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:Citrix NetScaler affected ? fixed ?
- vendor:Citrix NetScaler ADC affected < 14.1-73.37; < 13.1-64.23; FIPS < 14.1-73.37; FIPS/NDcPP < 13.1-37.279 fixed 14.1-73.37, 13.1-64.23, 14.1-73.37 FIPS, 13.1-37.279 FIPS/NDcPP
- vendor:Citrix NetScaler Gateway affected < 14.1-73.37; < 13.1-64.23 fixed 14.1-73.37, 13.1-64.23
- vendor:citrix netscaler application delivery controller affected >= 13.1, < 13.1-64.23 fixed 13.1-64.23
- vendor:citrix netscaler application delivery controller affected >= 13.1, < 13.1.37.279 fixed 13.1.37.279
- vendor:citrix netscaler application delivery controller affected >= 14.1, < 14.1-73.37 fixed 14.1-73.37
- vendor:citrix netscaler application delivery controller affected >= 14.1-66.68, <= 14.1-73.37 fixed ?
- vendor:citrix netscaler gateway affected >= 13.1, < 13.1-64.23 fixed 13.1-64.23
- vendor:citrix netscaler gateway affected >= 14.1, < 14.1-73.37 fixed 14.1-73.37

## How to check

Check the config (/nsconfig/ns.conf or 'show ns runningConfig') for DTLS. A Gateway VPN vserver is exposed unless it has '-dtls OFF', for example 'add vpn vserver vpn1 SSL ... -Listenpolicy NONE' with no -dtls OFF. Any 'add vpn vserver ... DTLS ...' or 'add lb vserver ... DTLS ...' is also exposed. Then check the build with 'show ns version': affected if before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, or before 13.1-37.279 FIPS/NDcPP. Check for indicators of compromise (Citrix provides them via NetScaler Console) before patching, because patching does not remove an existing implant.

## Fix

Upgrade to 14.1-73.37 or later, 13.1-64.23 or later of 13.1, 14.1-73.37 FIPS or later, or 13.1-37.279 or later (FIPS/NDcPP). Secure Private Access Hybrid deployments with NetScaler instances must upgrade those instances too. Setting '-dtls OFF' on VPN vservers would remove the precondition, but Citrix's bulletin does not list it as a mitigation, so treat it as a stopgap only. Also patch CVE-2026-88771, which is exploited too and affects all deployments.

## Timeline

- 2026-10-23T19:11:50+00:00 kev https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-88772
- 2026-10-23T20:22:16+00:00 github-poc https://github.com/CompleteTech-LLC/netscaler-cve-2026-88772-check
- 2026-10-23T20:27:17+00:00 analyst — Read Citrix bulletin CTX697096 (primary) and CISA alert: DTLS memory overflow, RCE/DoS, CVSS v4 9.5, zero-day exploited; severity raised high->critical on vendor's own 9.5 rating plus confirmed exploitation. The linked GitHub PoC is only an offline config/firmware checker with no exploit payload. CISA's Forensics Triage Requirements text was not read; the CISA alert only says to check for IoCs before patching, and Citrix offers IoCs via NetScaler Console.
- 2026-10-23T23:44:52+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-88772
- 2026-10-24T17:18:15+00:00 lab https://blog.cloudflare.com/protect-your-netscaler-gateway/ — Cloudflare: There's always a patient zero: Defending the NetScaler front door before the patch | Cloudflare Blog

## Documents

- [advisory] Citrix Security Bulletin CTX697096 https://support.citrix.com/external/article/CTX697096/citrix-netscaler-adc-and-citrix-netscale.html
- [advisory] Cloudflare: There's always a patient zero: Defending the NetScaler front door before the patch | Cloudflare Blog https://blog.cloudflare.com/protect-your-netscaler-gateway/
- [discussion] BleepingComputer: Citrix confirms two NetScaler RCE zero-days https://www.bleepingcomputer.com/news/security/citrix-admins-warned-to-shut-down-netscalers-over-2-exploited-zero-days/
- [mitigation] CISA alert: Citrix NetScaler zero-days https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
- [poc] CompleteTech-LLC/netscaler-cve-2026-88772-check https://github.com/CompleteTech-LLC/netscaler-cve-2026-88772-check

## From the sources

There's always a patient zero: Defending the NetScaler front door before the patch | Cloudflare Blog

October 19, 2026

# Beyond the patch: Protecting your NetScaler gateway against future vulnerabilities

Grant Bourzikas

 and 

Kenny Johnson

The recent disclosure of a major vulnerability in Citrix NetScaler pointed to a widespread weak point: a login page is an attack surface that can be used to compromise and access an application server. Indeed, the disclosures included an actively exploited flaw that allowed attackers to execute commands on affected gateways without signing in. As with any emergency patch, admins had to weigh cutting off or disrupting their users’ access with the risk of delaying a critical security update.

If you’re a NetScaler customer and you haven’t patched your instance, stop reading and go do that. This was a bad one. Once you’ve finished the patch, we’ll explore how to avoid a future fire drill by laying additional security controls.

This issue extends beyond NetScaler and can be applied to any internal application available on the Internet. Remote desktop portals, administrative consoles, and other publicly accessible authentication pages all deserve the same scrutiny: Does the intended audience require unrestricted Internet reachability? And can an attacker bypass this authentication check to reach the application's server?

Citrix released software updates to address the flaw, and Cloudflare followed with an emergency web application firewall (WAF) rule on October 1. But having a patch available does not guarantee safety: every instance has to be identified, updated, and tested. Applying updates across a production deployment is painful — it can result in downtime or cause disruptions to employees who still need their desktops throughout that process. Customers, patients, and others dependent on users of a remote desktop definitely don’t care about your security patch.

Using a web application firewall (WAF) can buy some additional time before a patch can be fully rolled out, but it’s reactive and does not account for the next exploit that’s discovered. Cloudflare and other security vendors do their best to cover variations and similar attacks. But AI is hastening how rapidly attackers can discover new and novel variants. That’s why it is crucial to build defense in depth, to ensure that no specific software failure or exploit will lead to a critical security issue.

Cloudflare combines access policies, web application security, and restricted origin connections to protect the authentication service before a new vulnerability is disclosed. Access controls limit who can reach the application server; WAF inspection evaluates web requests for attacks; origin restrictions prevent direct connections from bypassing those defenses. These reduce exposure without waiting for a new exploit signature or replacing the existing desktop platform.

## Copy link The NetScaler exploit

Citrix's September 27, 2026 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 configurations using Datagram Transport Layer Security, or DTLS. Further advisories on October 3 and October 8 addressed additional vulnerabilities in SAML configurations. These exploits allowed attackers to execute arbitrary scripts on target machines and also execute denial of service attacks.

CISA's alert and Mandiant's technical investigation cover the vulnerabilities, observed exploitation, and response guidance in more detail. For details of the available web application protection, see Cloudflare's emergency WAF release for CVE-2026-88771.

In a typical Citrix deployment, the user authenticates through NetScaler Gateway, which then uses a secure ticket authority to pass through to the StoreFront, which presents the applications and desktops available to that user. The native-installed Citrix app then uses that information to establish a separate connection using Citrix's Independent Computing Architecture (ICA) protocol. The gateway validates the ticket before proxying the desktop connection. Citrix documents these as distinct stages of the connection workflow. The entire exploit stems from the fact that the Gateway has to be publicly accessible on the Internet, otherwise users would not be able to initiate their desktop connection.

## Copy link Put the access decision in front of the authentication server

The best thing that you can do, after patching all your instances, is move any publicly accessible login pages or applications behind single sign-on before the request ever hits the target server. Cloudflare Access can enforce an independent access policy before the request reaches the existing gateway server. The Citrix environment continues to determine which desktop the user may launch and to validate the resulting session ticket. The additional boundary ensures that an attacker could never get to the Gateway server to try running specific exploits. They would only see the Cloudflare Access login page.

That decision no longer depends on recognizing an exploit signature and blocking that way, but rather on a set of Zero Trust policies that determine if someone should even be there to begin with. More attacks like this are coming, and adopting Zero Trust controls throughout your network is the single most important thing you should do next.

This follows the principle described in Cloudflare's own architecture as customer zero: reduce exposure and use independent defenses so that one flaw does not become a compromise. Here, the practical starting point is the service that users reach before they enter their applications.

Logical separation of web authentication and desktop transport. The gateway roles may run on the same appliance.

Protecting the web authentication path adds a boundary in front of the existing Citrix controls. It does not automatically extend that boundary to other gateway services, including DTLS-enabled listeners. Those interfaces still need their own exposure review and applicable security updates, even when the desktop sessions they support already require authentication.

## Copy link The origin connection must enforce the same boundary

Changing a DNS record and enforcing Access policies are not enough. If an attacker can connect to the original address or an alternate hostname, they can avoid the controls placed in front of it. Access enforces a specific hostname: if the authentication server can be reached via an IP address or alternative hostname, then the Access policy enforcement is worthless. It’s important to take steps to ensure that all traffic comes from a request that was validated by Access. There are a few different approaches to accomplish this, based on your internal architecture.

Cloudflare Tunnel is the most commonly used approach. It establishes an outbound only tunnel from your application server and allows you to close all inbound IP traffic. This means that you won’t have a public IP for the server that can be reached by anyone.

When a public origin IP Address must remain or connector software cannot be run, network restrictions and origin authentication need to constrain the connections it accepts. For example, Dedicated CDN Egress IPs give an account dedicated source addresses for traffic from Cloudflare to its origins. The application server’s firewall can allow those addresses and reject other sources. This makes the network restriction specific to the account's traffic, rather than broadly allowing traffic from Cloudflare's shared address ranges.

Authenticated Origin Pulls can add further depth with mutual TLS to verify the Cloudflare-to-origin connection.

An origin that supports it can also validate the Access JSON Web Token, including its signature, issuer, expiry, and intended application audience. This is the best way to guarantee that a re

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_