Im Kern steht laut watchTowr eine Inkonsistenz beim Zerlegen von DTLS-Handshake-Nachrichten: NetScaler vertraut der im Header angegebenen Fragmentgröße im Feld fragment_length blind, während dasselbe Paket im Feld length behauptet, die vollständige Nachricht sei 120 Byte lang.
Daraus lässt sich ein bösartiger Datensatz bauen, der nach außen winzig wirkt, tatsächlich aber deutlich mehr Daten in den Puffer kopiert. Sicherheitsforscher Sina Kheirkhah erläutert das Prinzip: „Eine 120 Byte große Handshake-Nachricht kann beispielsweise in 120 Fragmenten eintreffen. Jedes Fragment gibt length=120 an, aber jedes einzelne kann fragment_length=1 haben.“ Die Offsets lägen dann bei 0, 1, 2 und so weiter bis 119; sobald jede Position eingetroffen sei, betrachte der Server die 120-Byte-Nachricht als vollständig. Das Zusammenfügen dieser Teile heiße Reassemblierung.
Entscheidend ist, was dabei tatsächlich im Speicher landet. Jedes empfangene Paket von 1.459 Byte wird in NetScaler Buffers (NSBs) abgelegt und anschließend in einen einzigen Scratch-Puffer von lediglich 35.840 Byte zusammengeführt. Die verwundbare Version prüft nicht, ob das nächste Paket überhaupt noch in diesen Puffer passt – die Daten werden über dessen Ende hinaus geschrieben.
„Die bösartigen Datensätze teilen dem Reassemblierungs-Code mit, dass jeder Datensatz nur ein einziges Byte einer 120 Byte großen Handshake-Nachricht liefert“, so Kheirkhah. „NSPPE behält jedoch nahezu den gesamten Datensatz in einem NSB. Nach 120 Datensätzen gilt die Handshake-Nachricht als vollständig, ihre NSB-Kette enthält aber rund 174 KB an Daten.“
Die Analyse geht über den reinen Absturz hinaus: watchTowr zufolge lässt sich der Überlauf nutzen, um den Kontrollfluss auf beliebigen Shellcode umzulenken – mit Root-Rechten. Dazu greifen die Forscher auf den Systemaufruf mprotect() zurück, um den NX-Schutz (no-execute) auszuhebeln, der die Ausführung von Code in Datenbereichen eigentlich unterbinden soll.
Dass die Lücke nicht nur theoretisch gefährlich ist, zeigt die Einordnung durch CISA sowie die bestätigte aktive Ausnutzung. CVE-2026-88772 wurde dabei in realen Angriffen zusammen mit CVE-2026-88771 eingesetzt; für letztere hatte watchTowr bereits einen Proof-of-Concept veröffentlicht.