We Are Here

1217 Park Ave,
San Jose CA 95126

We use cookies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from Learn more.

On 26 September 2026, the security research firm watchTowr warned that two unpatched remote code execution (RCE) vulnerabilities in Citrix NetScaler were being exploited in the wild. At that point there was no CVE, no advisory, no list of affected builds and no indicators of compromise. Defenders knew only that something serious was happening to one of the most widely deployed remote-access gateways in the enterprise. 

A day later, Citrix confirmed it. The flaws were assigned CVE-2026-88771 and CVE-2026-88772, fixed builds were released, and CISA added both to its Known Exploited Vulnerabilities (KEV) catalog. For many security teams the clock had been running for days before they had anything to act on. 

It follows an actively exploited NetScaler authentication bypass (CVE-2026-19490) disclosed only weeks earlier. It is a useful case study in how modern vulnerability response really works, and in what it takes to keep up.

What we know
CVE Type CVSS v4.0 Status
CVE-2026-88771 Improper input validation, unauthenticated command execution 9.5 Exploited in the wild; CISA KEV (27 Sep 2026)
CVE-2026-88772 Memory overflow leading to RCE or denial of service (DTLS-enabled deployments, default for VPN servers) 9.5 Exploited in the wild; CISA KEV (27 Sep 2026)
CVE-2026-19490 Authentication bypass in Gateway / AAA virtual servers (disclosed August) 9.3 Exploited; CISA KEV (9 Sep 2026)

The same Citrix bulletin (CTX697096) also fixes six further CVEs, CVE-2026-88773 through CVE-2026-88778, including HTTP request smuggling and memory overflow issues. Citrix states that no workaround is available; patching is the only fix.

Fixed builds for customer-managed appliances: NetScaler ADC and Gateway 14.1-73.37 or later; 13.1-64.23 or later; 14.1-73.37 FIPS or later; and 13.1-37.279 (13.1-FIPS/NDcPP) or later.

Why this matters beyond Citrix

It is tempting to file this away as an appliance problem for the network team. That would miss the bigger pattern, which applies to every piece of software an organisation runs, including the software it builds itself.

  • The exposure window starts before the CVE exists. Attackers were exploiting these flaws before defenders had an identifier to search for. When the CVE does land, the first question every CISO asks is “are we affected, and where?” Teams that need days to answer that question are already behind.
  • Exploited beats scored. Thousands of new CVEs are published each year, and most organisations carry a long backlog. The ones that matter most are those under active exploitation, which is exactly what CISA KEV tracks. Prioritising by real-world exploitation, not CVSS alone, is how teams cut a backlog down to what has to be fixed this week.
  • Vulnerable components travel. An exploited flaw in an open-source library or base image does not stay in one place. It is copied into every repository, build and container image that pulls it in, often several layers deep.
  • Patching is a change, not an event. Even with a fix available, someone must find every affected asset, identify the owner, ship the update and confirm it took. Without that loop, “patched” is an assumption.

The same problem lives in your code and containers

Cloud-native teams face the NetScaler scenario every week, just less visibly. A critical CVE is published in a popular logging library, web framework or OS package. Within hours, proof-of-concept code appears. The questions are identical:

  1. Which of our repositories depend on the vulnerable package, directly or transitively?
  2. Which container images include it, and which of those are running in production?
  3. Is it actually exploitable and exposed, or is it buried in a test dependency?
  4. Who owns the fix, and what version resolves it?

Answering these by hand, across hundreds of repositories, registries and clusters, is where response time is lost.

How Banyan Cloud helps

Banyan Cloud’s CNAPP platform includes repository and container security designed to answer those questions continuously, not after the headlines.

  • Repository scanning. Banyan Cloud scans source repositories and their dependency manifests for known CVEs, so vulnerable open-source components are caught before they are built into an image or shipped to production.
  • Container image scanning. Container images are scanned for vulnerable OS packages and application libraries, giving teams a clear view of which images carry which CVEs.
  • Risk-based prioritisation. Findings are ranked so teams can focus first on what is critical, known to be exploited and exposed, rather than working through a flat list sorted by severity score.
  • Cloud context in one place. Because repo and container findings sit alongside Banyan Cloud’s wider cloud posture view, security teams can see how a vulnerable component connects to running workloads and internet-facing assets, consistent with Banyan Cloud’s data-first approach to unifying governance, security and operations.
  • Guided remediation. Each finding comes with the affected component and the fixed version, so developers know exactly what to upgrade. Our team also works with customers to triage, prioritise and close out the vulnerabilities that matter most.

The result is a short, defensible path from “a new CVE was just published” to “here is where we are exposed, here is who is fixing it, and here is the proof it is done.”

If you run NetScaler: what to do now

  1. Preserve evidence first. Capture forensic data from appliances before patching, as watchTowr advises; patching can overwrite traces of compromise.
  2. Hunt for compromise. Run the published IOC checks and review appliance logs for unexpected sessions or files.
  3. Patch immediately to the fixed builds listed above. There is no workaround.
  4. Rotate secrets. Change service account passwords and revoke and reissue certificates and private keys associated with the appliance.
  5. Reduce exposure. Keep management interfaces off the public internet and isolate any appliance you suspect is compromised.

The bottom line

Zero-days will keep coming, and the gap between disclosure and exploitation keeps shrinking. Organisations cannot control when the next one drops, but they can control how quickly they can answer “where are we exposed?” That answer depends on continuous visibility into every repository, every container image and every workload.

Banyan Cloud can show you your real CVE exposure across your code and containers. Contact our team to request a demo or a vulnerability assessment of your cloud environment.

Sources

>Cyber Security News: Citrix NetScaler 0-Day RCE Vulnerabilities

>watchTowr: Citrix NetScaler Zero-Day RCE FAQ (CVE-2026-88771, CVE-2026-88772)

>The Hacker News: Two Unpatched Citrix NetScaler RCE Zero-Days Under Active Exploitation