blogwatchTowr Labs·29 Sept 2026·@SinSinology

Here We Go Again (Citrix NetScaler DTLS Preauth Memory Overflow CVE-2026-88772)

watchTowr details a pre-auth memory overflow in Citrix NetScaler DTLS handling, CVE-2026-88772.

Depth 5/5Score 5.21

Extract

Part 1 of this week's saga can be found here. This research is a glimpse into the capabilities that power our Preemptive Exposure Management solution, enabling organizations to rapidly react to emerging threats: the watchTowr Platform. What Is A Citrix NetScaler? NetScaler, from Citrix (now under Cloud Software Group), is an application delivery controller - some believe it qualifies to be described as a security appliance. It sits in front of an organization's applications and handles load balancing, traffic management, and SSL/TLS termination. NetScaler Gateway adds VPN and secure remote access. What Is the Purpose of a Security Appliance? A security appliance exists to keep an organization secure by standing between its systems and threats that attempt to reach them. It concentrates a defensive function, controlling remote access, filtering hostile traffic, or enforcing who is allowed in, at a single chokepoint that every connection has to pass through. What Does "Hardened" Mean In "Hardened Security Appliance"? "Hardened" means the vendor has stripped the device down and locked it up: minimal running services, restricted shell access, a controlled update path, and defaults tuned for security. The premise is that it is tougher to break into than a general-purpose server. What is CVE-2026-88772, and When Will This End? As we discussed in yesterday's blog post , the advisory released by Citrix on Sunday did not just contain one in-the-wild exploited vulnerability - but two. Today, we're going to be analyzing CVE-2026-88772. CVE-2026-88772 is the DTLS memory overflow we walk through here. It is one of eight vulnerabilities Citrix fixed in a single bulletin, CTX697096 . It requires DTLS to be enabled which is the default on VPN virtual servers unless an administrator explicitly set -dtls OFF and was exploited in the wild as a zero-day. As a call back and for consistency with yesterday’s blog post, here is everything the advisory covers: CVE Description CVSS 4.0 Exploited in the Wild CVE-2026-88771 Improper input validation that lets an unauthenticated attacker run arbitrary commands. Affects the default configuration. 9.5 Critical Yes CVE-2026-88772 Memory overflow that can lead to remote code execution or denial of service when DTLS is enabled (the default for VPN virtual servers). 9.5 Critical Yes CVE-2026-88773 HTTP request smuggling (inconsistent interpretation of HTTP requests). Depends on specific configurations. 9.3 …

Explained

What happened

CVE-2026-88772 is a memory overflow in Citrix NetScaler reached over DTLS, which is on by default for VPN virtual servers. It was exploited as a zero-day and is one of eight bugs in bulletin CTX697096. The mechanism:

DTLS reassembles a handshake message from many fragments. Each fragment header carries a total length, a fragment_offset, and a fragment_length.
NetScaler stores incoming bytes in linked buffers (NSBs), then stitches the completed message into one fixed scratch buffer of only 35,840 bytes in the binary data section.
An attacker sends 120 crafted records. Each claims the message is 120 bytes long (length=120) but that this record only supplies one byte (fragment_length=1), while the record actually carries about 1.4 KB of real data hidden behind a second handshake header.
The parser uses length=120 to walk to the next header but trusts the small fragment_length for accounting, so after 120 records the message counts as complete while the buffer chain holds about 174 KB.
The vulnerable copy loop then memcpys the whole chain into the 35,840-byte scratch buffer with no size check, overflowing it. The fix simply tracks remaining space and rejects the message when the next piece will not fit.

Reaching the parser needs only the standard DTLS cookie exchange, which proves the sender can receive at its IP but authenticates no user.

Why it works

The reassembly code trusted two attacker-controlled size fields that did not have to agree with each other or with reality. It used one field to navigate the packet and a different field to decide how much data each fragment contributed, so the declared total and the real total diverged. The destination buffer was a fixed, statically sized region, and the copy assumed the reassembled message could never exceed it. No bound was enforced at the one place that mattered, the copy.

The bigger pattern

This is a textbook length-field confusion feeding a fixed-buffer overflow, the same family as countless protocol-parser bugs. Two things make it dangerous: the parser believed self-reported sizes instead of measuring the bytes it actually held, and the final copy had no backstop. The cookie step is not authentication, so a pre-auth, unauthenticated path reaches deep parsing code. Security appliances concentrate this risk because they terminate hostile traffic at a single chokepoint that every connection crosses.

What it means in practice

Never trust a length or offset field from the wire. Validate that declared sizes are internally consistent and that the running total of reassembled bytes matches the claimed message length before using either.
Bound every copy at the copy site against the destination capacity. A check earlier in the pipeline is not a substitute.
Prefer growable or length-checked buffers over fixed scratch regions for attacker-influenced reassembly, and fail closed when input exceeds limits.
Fuzz protocol reassembly with fragments whose declared and actual lengths disagree, overlap, or arrive out of order. These paths are where parser bugs hide.
Operationally: a cookie or handshake that only proves reachability is not auth. Disable protocol features you do not use (here, DTLS), keep internet-facing appliances patched fast, and treat them as prime targets, since one overflow at the edge is a full compromise.