bishopfox/cve-2026-8452-checkVerhaltensbasierter Patch-Zustands-Detektor für Citrix NetScaler CVE-2026-8452. Sendet gezielt erstellte SAML-Anfragen, um festzustellen, ob die PrefixList-Größenprüfung vorhanden ist, ohne Speicher auszunutzen oder zu korrumpieren.
Eine sichere, nicht-destruktive Prüfung des Patch-Zustands für CVE-2026-8452, den Heap-Overflow vor der Authentifizierung im SAML-Signatur-Kanonisierer von Citrix NetScaler ADC / NetScaler Gateway (CTX696604, CVSS 8.8). Eine übermäßig große PrefixList der exklusiven Kanonisierung lässt während der Kanonisierung einen Puffer fester Größe überlaufen, was NetScaler vor der Validierung der Signatur durchführt, die sie trägt – der gesamte Pfad ist also ohne Anmeldedaten, ohne Sitzung und ohne gültige Signatur erreichbar. Gemeldet von Michael Tucker vom XOR-Team von JPMorgan Chase; Root-Cause- und Exploit-Analyse mit freundlicher Genehmigung von watchTowr Labs.
Dieses Skript nutzt den Fehler nicht aus und korrumpiert keinen Speicher. Es beantwortet eine Frage pro Ziel: Ist der Fix auf diesem Gerät vorhanden? – ermittelt verhaltensbasiert, indem der Patch beobachtet wird, statt die Build-Version zu erraten.
Ja. Es ist für den Einsatz in Produktion und für Bewertungen konzipiert:
PrefixList von 512 Bytes und lehnen 513 oder mehr ab. Diese Grenze wurde bytegenau lokalisiert, ist auf beiden unterstützten Zweigen identisch und verschiebt sich weder mit der Konfiguration der Appliance noch mit der Form der umgebenden SAML-Nachricht – bestätigt durch Tests beider Routen, die den Wert in deutlich unterschiedlichen Mengen an XML einbetten, und die Feststellung, dass das Verhalten beim gleichen Byte umschlägt. 575 liegt 63 Bytes unter der Grenze, daher hängt das Urteil nicht davon ab, wie ein Ziel zufällig konfiguriert ist.PrefixList-Attribut. Das Aufblähen anderer Felder darüber hinaus – Assertion-Consumer-Service-URLs, Issuer-Namen, Algorithmus-Kennungen, Digest- und Signaturwerte – ändert auf einem behobenen Build nichts, daher sollte die Anwendung des Fixes eine funktionierende SAML-Konfiguration nicht zum Scheitern bringen.Wenn Sie die Sonde verändern, ändern Sie nicht
PROBE_PREFIXESund führen Sie keinen Längen-Sweep durch. 575 Bytes sind tragend. AnderePrefixList-Längen können eine Appliance destabilisieren – in mindestens einem Fall auf einem Build, der diesen Fix trägt – daher ist ein Längen-Sweep kein sicherer Weg, diesen Fehler zu untersuchen, und kürzer ist nicht sicherer.
Gepatchte Builds lehnen eine übermäßig große PrefixList sauber ab, mit einer markanten Meldung. Ungepatchte Builds fallen durch den Parser und geben einen generischen internen Fehler zurück. Eine identische Anfrage, zwei verschiedene Antworten:
575-Byte-PrefixList | Antwort |
|---|---|
| Ungepatcht | 500 Internal Server Error 43549 |
| Gepatcht | 200 Malformed Assertion sent to Netscaler |
Zwei Routen werden versucht, zuerst IdP, und gestoppt, sobald eine eine Antwort liefert. Jede für sich ist ausreichend, und zusammen decken sie beide SAML-Rollen ab:
| Route | Anfrage | Voraussetzung |
|---|---|---|
| 1 (erste) | POST /saml/login — signierte AuthnRequest, PrefixList in ds:SignedInfo | eine an den Ziel-vserver gebundene SAML-IdP-Richtlinie |
| 2 (Fallback) | POST /cgi/samlauth — SAMLResponse, PrefixList in der Assertion-Signatur | ein SAML-SP-Assertion-Consumer-Service auf dem Ziel-vserver |
Die IdP-Route kommt zuerst, weil sie die robustere der beiden ist. Sie ist unempfindlich gegenüber dem Issuer-Wert, der AssertionConsumerServiceURL und gegenüber Clock-Skew – eine IssueInstant weit außerhalb der Toleranz der Appliance für Clock-Skew unterscheidet weiterhin korrekt, da die Kanonisierung sowohl vor der Zeitprüfung als auch vor der Signaturprüfung erfolgt.
Die
AuthnRequestfür Route 1 muss signiert sein. Eine unsignierte liefert auf gepatchten und ungepatchten Builds200 Malformed Assertion sent to Netscaler, was byteidentisch mit dem gepatchten Signal ist. Eine Sonde, die den Signaturblock weglässt, meldet daher jede Appliance als gepatcht. Die Signatur muss nicht gültig sein, und die dieses Tools ist es nicht; sie muss nur vorhanden sein, denn ihrSignedInfoist das, was diePrefixListin den Kanonisierer bringt.
Beide unterstützten Zweige ändern ihr Verhalten genau beim Fix-Build, auf beiden Routen:
| Build | Urteil | |
|---|---|---|
13.1-63.16 | letzte verwundbare 13.1 | VULNERABLE |
13.1-63.18 | erste behobene 13.1 | PATCHED |
14.1-66.59 | verwundbare 14.1 | VULNERABLE |
14.1-72.61 | erste behobene 14.1 | PATCHED |
13.1-63.16 und 63.18 sind aufeinanderfolgende Releases, daher ist die Änderung dem Patch selbst zuzuschreiben und nicht dem Drift über dazwischenliegende Builds.
Das sind die Builds, in denen dieser Fix zum ersten Mal auftrat, und die Sonde erkennt genau diesen Übergang. Es sind nicht mehr die Builds, auf die man upgraden sollte: Spätere Bulletins haben sie überholt, daher antworten 13.1-63.18 und 14.1-72.61 hier beide mit PATCHED, bleiben aber neueren Problemen ausgesetzt. Siehe Remediation für die aktuellen behobenen Builds.
Weil es bei diesem Fehler selbst prinzipiell nicht funktionieren kann. 13.1-63.16 und 13.1-63.18, die Builds direkt auf beiden Seiten des Fixes, liefern byteidentische tmindex.html, base.css und resources.js aus – der Fix berührt kein Web-Asset. Statische Asset-Hashes kollidieren auch über Zweige hinweg, sodass ein hash-basierter Ansatz eine verwundbare Appliance einem gepatchten Build zuordnen und sie als sauber melden kann – das ist der schlimmste Fehlermodus, den ein Erkennungstool haben kann. Build-Fingerprinting ist daher bewusst nicht implementiert. Der Patch-Zustand stammt von der Sonde oder von show ns version, wenn Sie Anmeldedaten haben.
./cve_2026_8452_check.py https://gateway.example.com
./cve_2026_8452_check.py https://gateway.example.com:9443
./cve_2026_8452_check.py -f targets.txt --brief