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:
PrefixListPrefixList-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
./cve_2026_8452_check.py -f targets.txt --json > results.json
Richten Sie das Tool auf den **Gateway- oder AAA-virtuellen Server**, nicht auf die Verwaltungsschnittstelle. Die
Vorbedingung gilt pro virtuellem Server, daher muss bei einem Gerät mit mehreren VIPs jeder einzeln getestet werden.
### Optionen
| Flag | Beschreibung |
| --- | --- |
| `URL` | Ein oder mehrere `https://HOST[:PORT]`-Ziele |
| `-f, --targets-file DATEI` | Ziele aus einer Datei lesen (eines pro Zeile; `#`-Kommentare) |
| `-b, --brief` | Eine einzelne ausgerichtete Zeile pro Ziel – Urteil, Ziel, Grund-Tag – zum Scannen vieler Hosts |
| `--json` | Strukturierte JSON-Ergebnisse ausgeben |
| `--no-color` | Farbige Ausgabe deaktivieren (berücksichtigt auch `NO_COLOR` und Nicht-TTY) |
| `--timeout SEK` | Timeout pro Anfrage (Standard: 15) |
### Beispiele
**Ein nicht gepatchtes Gerät,** das auf der IdP-Route antwortet und gegen die Kontrolle bestätigt wurde:```console
$ ./cve_2026_8452_check.py https://gateway.example.com:9443
====================================================================
CVE-2026-8452 - NetScaler SAML PrefixList patch-state check
https://gateway.example.com:9443
====================================================================
>> Identifying the appliance
[ OK ] NetScaler indicators: 5 (CSP contains citrixng://)
>> Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control)
idp /saml/login HTTP 500 / 43549: no size check present
idp /saml/login 35-byte control: HTTP 200 "message timestamp outside the appliance's skew tolerance": a different SAML condition, not the size check
[FAIL] Size check absent (via the IDP route)
====================================================================
RESULT: VULNERABLE
====================================================================
https://gateway.example.com:9443 via IDP [size-check-absent]
The size check is absent. This appliance is unpatched for
CVE-2026-8452. Upgrade to 13.1-63.21+ / 14.1-73.32+ (12.1 and
13.0 are EOL and never fixed).
====================================================================
Die Kontrollzeile ist eine genaue Lektüre wert: Die 35-Byte-Anfrage passiert die Größeprüfung
und wird dann wegen ihrer veralteten IssueInstant abgelehnt, während die 575-Byte-Probe nie so weit
kam. Auf dieser Reihenfolge beruht die gesamte Methode — die Kanonisierung läuft vor
der Zeitprüfung, genau wie sie vor der Signaturprüfung läuft.
Ein gepatchtes Gerät, dieselbe Anfrage gegen den Fix-Build. Nur die Probezeile unterscheidet sich — die
überdimensionierte PrefixList wird namentlich abgelehnt, anstatt auf den internen Fehler durchzufallen:```console
Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control) idp /saml/login HTTP 200 "Malformed Assertion": size check rejected the probe idp /saml/login 35-byte control: HTTP 200 "message timestamp outside the appliance's skew tolerance": a different SAML condition, not the size check [ OK ] Size check present (via the IDP route)
RESULT: PATCHED
https://vpn.example.com via IDP [size-check-present]
**Rückgriff auf die SP-Route.** Hier ist der IdP-Endpunkt erreichbar, aber keine IdP-Richtlinie ist an
diesen virtuellen Server gebunden, daher enthält sich Route 1 und Route 2 antwortet. Wenn *keine* Route mit einer Richtlinie übereinstimmt,
lautet das Urteil `INCONCLUSIVE` mit dem Tag `no-policy-match` — niemals `PATCHED`, was der ganze Grund dafür ist,
dass dieses Urteil existiert:```console
>> Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control)
idp /saml/login HTTP 200 "Matching policy not found": parser not reached
sp /cgi/samlauth HTTP 500 / 43549: no size check present
sp /cgi/samlauth 35-byte control: HTTP 200 "assertion rejected before the size check": a different SAML condition, not the size check
[FAIL] Size check absent (via the SP route)
RESULT: VULNERABLE
Die Kontrolle hat es erkannt. Hier hat der Endpunkt bei beiden Längen mit der gepatchten Nachricht geantwortet, sodass die Größenprüfung nie durchgeführt wurde und die entscheidend wirkende Antwort zurückgezogen wird. Dies ist das Auslösen des False-Positive-Schutzes, und der Grund dafür wird angegeben, statt ihn ableiten zu müssen:```console
Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control) idp /saml/login HTTP 200 "Malformed Assertion": size check rejected the probe idp /saml/login 35-byte control: HTTP 200 "Malformed Assertion": size check rejected the probe [WARN] Probe and control answered alike, so the size check was never exercised
RESULT: INCONCLUSIVE
https://sp-strict.example.com via IDP [flat-response]
The 575-byte probe and the 35-byte control got the same answer, so this endpoint replies the same way whatever it is sent and the size check was never exercised. Unknown, not patched.
**Scanning eines Verbunds** (`--brief`), eine ausgerichtete Zeile pro Ziel, die mit dem Reason-Tag endet. Der Exit-Status ist `1`, wenn ein Ziel `VULNERABLE` ist:```console
$ ./cve_2026_8452_check.py -f targets.txt --brief; echo "exit: $?"
VULNERABLE https://gateway.example.com:9443 size-check-absent
VULNERABLE https://gateway.example.com:9444 size-check-absent
PATCHED https://vpn.example.com size-check-present
INCONCLUSIVE https://sp-strict.example.com flat-response
INCONCLUSIVE https://gw-nopolicy.example.com no-policy-match
UNAFFECTED https://mgmt.example.com no-saml-endpoint
ERROR https://offline.example.com not-identified
exit: 1
Maschinenlesbare Ausgabe (--json), die jede versuchte Route aufzeichnet. verdict, reason und
detail sind die maßgeblichen Felder; attempts ist das rohe Beweismaterial, sodass ein einzelner Versuch
patched anzeigen kann, während das Urteil INCONCLUSIVE lautet:```console
$ ./cve_2026_8452_check.py https://vpn.example.com --json
[
{
"target": "https://vpn.example.com",
"verdict": "PATCHED",
"reason": "size-check-present",
"route": "idp",
"detail": "HTTP 200 "Malformed Assertion": size check rejected the probe",
"attempts": [
{
"route": "idp",
"path": "/saml/login",
"state": "patched",
"detail": "HTTP 200 "Malformed Assertion": size check rejected the probe"
},
{
"route": "idp",
"path": "/saml/login",
"state": "control:known-error",
"detail": "35-byte control: HTTP 200 "message timestamp outside the appliance's skew tolerance": a different SAML condition, not the size check"
}
],
"netscaler_indicators": [
"CSP contains citrixng://",
"CSP contains com.citrix.nsgclient://",
"CSP contains nsgcepa://",
"CSP report-uri /nscsp_violation/report_uri",
"/vpn/js/rdx/ present (HTTP 404)"
]
}
]
## Befunde
Jeder Befund trägt ein kurzes `reason`-Tag, das die zugrunde liegende Bedingung benennt. `--brief` gibt das Tag als dritte Spalte aus, und `--json` führt es als `reason`.
| Befund | Reason-Tag | Bedeutung |
| --- | --- | --- |
| `VULNERABLE` | `size-check-absent` | Die Größenprüfung fehlt. Dieses Gerät ist nicht gepatcht — patchen Sie es. |
| `PATCHED` | `size-check-present` | Die Größenprüfung wurde auf dem Codepfad ausgelöst, den die Probe erreicht hat. **Auf diese CVE beschränkt:** es bedeutet nicht, dass die Appliance auf einem aktuellen Build läuft. |
| `UNAFFECTED` | `no-saml-endpoint` | Auf diesem virtuellen Server hat kein SAML-Endpunkt geantwortet, daher ist der angreifbare Pfad hier nicht erreichbar. **Pro-vserver, nicht pro-Appliance:** SAML kann auf einem anderen vserver oder einer VIP auf demselben Gerät konfiguriert sein. |
| `INCONCLUSIVE` | `flat-response` | Der Endpunkt antwortete auf die 575-Byte-Probe und die 35-Byte-Kontrolle identisch, sodass die Größenprüfung nie ausgeführt wurde. Die entscheidend wirkende Antwort wird verworfen — hier greift der Fehlalarmschutz. |
| `INCONCLUSIVE` | `no-policy-match` | Ein SAML-Endpunkt hat geantwortet, aber keine gebundene Richtlinie passte auf die Probe, sodass keiner der Pfade den Kanonisierer erreichte. |
| `INCONCLUSIVE` | `other-saml-error` | Eine erkannte, aber nicht diagnostische SAML-Bedingung lehnte die Probe vor der Größenprüfung ab — etwa ein anderes Längenlimit, eine Signaturrichtlinie oder ein Zeitstempel. |
| `INCONCLUSIVE` | `unrecognized-reply` | Eine SAML-Oberfläche antwortete mit etwas außerhalb der erkannten Menge. |
| `ERROR` | `not-identified` | Nicht als NetScaler identifiziert oder nicht erreichbar. |
Alle vier `INCONCLUSIVE`-Gründe bedeuten für die Entscheidungsfindung dasselbe — **unbekannt, nicht gepatcht.** Bestätigen Sie mit `show ns version`. Das Tag dient dazu, dem Operator mitzuteilen, *welche* Bedingung vor einem erneuten Lauf zu beheben ist: Richten Sie die Probe auf einen anderen virtuellen Server oder binden Sie eine passende Richtlinie.
`INCONCLUSIVE` existiert als eigener Befund mit eigenem Exit-Code, weil eine anfällige Appliance die Beantwortung der Probe verweigern kann. Wenn die an einen virtuellen Server gebundene SAML-Richtlinie nicht mit der Anfrage der Probe übereinstimmt, bricht die Appliance vor dem Kanonisierer ab und gibt nichts Diagnostisches zurück. Ein Scanner, der lediglich nicht abgleichen kann, verstummt auf einem solchen Host, und Stille gilt als "patched". Dieses Tool meldet dies stattdessen als unbekannt.
### Jeder Befund wird gegen eine Kontrolle bestätigt
`PATCHED` und `VULNERABLE` stützen sich beide auf eine *einzige* unterscheidende Antwort, daher prüft das Tool, ob die Antwort tatsächlich von dem abhängt, was gesendet wurde. Nach einer eindeutigen Antwort wiederholt es die Anfrage mit einer kurzen 35-Byte-`PrefixList` — unterhalb jeder Größenprüfung — und der Befund gilt nur, wenn sich die beiden Antworten unterscheiden. Wenn sie übereinstimmen, antwortet der Endpunkt unabhängig vom Empfangenen immer gleich, die Größenprüfung wurde nie ausgeführt, und das Ergebnis ist `INCONCLUSIVE`.
Das ist nicht hypothetisch. Ein Dienstanbieter, der mit `samlRejectUnsignedAssertion STRICT` konfiguriert ist, lehnt die Probe wegen einer fehlenden Signatur *vor* der Kanonisierung ab und antwortet bei jeder Länge mit der gepatchten Meldung. Ohne die Kontrolle meldet eine solche Appliance `PATCHED` mit Exit 0 — beobachtet bei einem tatsächlich anfälligen Build. Sie meldet nun `INCONCLUSIVE` mit dem Reason-Tag `flat-response`, und der Lauf stellt ausdrücklich fest, dass die Größenprüfung nie ausgeführt wurde. Dieselbe Kontrolle erfasst auch den spiegelbildlichen Fall, in dem ein Endpunkt auf Anfragen, die er nie geparst hat, den generischen internen Fehler zurückgibt.
### Erkannte nicht-diagnostische Antworten
Ein NetScaler-SAML-Endpunkt verfügt über eine große Menge möglicher Antworten, und nur zwei davon belegen den Patch-Zustand. Das Tool erkennt 20 der übrigen und benennt die Bedingung in der Zeile pro Route, anstatt einen Antworttext auszugeben, zum Beispiel:```text
idp /saml/login HTTP 200 "post body over the appliance's maximum": a different length limit rejected the probe first
sp /cgi/samlauth HTTP 200 "assertion rejected before the size check": a different SAML condition, not the size check
Drei davon sind Längenbegrenzungen – ein übermäßig großer POST-Body, ein übermäßig großes RelayState, ein übermäßig langer extrahierter Benutzername. Diese sind am wichtigsten, denn sie bedeuten, dass die Anfrage von einer anderen Längenprüfung abgewiesen wurde, bevor sie diejenige erreicht, die den Patch-Zustand unterscheidet. Das bedeutet in der Regel, dass die Sonde auf einen anderen virtuellen Server gerichtet werden muss, nicht dass das Gerät in Ordnung ist.
Einer der 20 tritt bei jedem IdP-Routenlauf auf: die Kontrollmeldung message timestamp outside the appliance's skew tolerance. Die Sonde trägt eine feste IssueInstant, sodass eine Kontrollanfrage, die die Größenprüfung besteht, anschließend wegen ihres Alters abgewiesen wird – eine Eigenschaft der Sonde, nicht des Geräts. Eine Antwort außerhalb der Menge der 20 wird als eigene erste Zeile ausgegeben statt als benannte Bedingung.
Alle diese Antworten ergeben weiterhin INCONCLUSIVE, markiert als other-saml-error. Das Erkennen einer Antwort stuft sie niemals zu PATCHED hoch: Nur eine explizite Antwort eines gepatchten Builds tut das, und jede nicht erkannte Antwort fällt ebenfalls auf INCONCLUSIVE zurück – als unrecognized-reply. Die Erkennung dient dazu, einem Operator zu sagen, warum ein Ziel nicht klassifiziert werden konnte, nicht um es zu klassifizieren.
| Code | Bedeutung |
|---|---|
0 | Gepatcht oder auf dem angesprochenen virtuellen Server nicht betroffen |
1 | Mindestens ein Ziel ist VULNERABLE |
2 | Nutzungsfehler (ungültige Argumente / nicht lesbare Zieldatei) |
3 | Mindestens ein Ziel ist INCONCLUSIVE, keines verwundbar |
4 | Mindestens ein Ziel mit Fehler, keines verwundbar oder unentschieden |
2 ist der Exit-Code, den argparse selbst bei einem ungültigen Aufruf liefert, daher überspringen die Bewertungscodes ihn. Ein Wrapper-Skript kann also „Dieses Gerät konnte nicht klassifiziert werden“ (3) von „Ich habe das Tool falsch aufgerufen“ (2) unterscheiden, was ein Schema, das 2 überladen würde, nicht könnte.
Bei einem Multi-Target-Sweep wird der Code nach Priorität gewählt, nicht nach dem schlechtesten Status:
VULNERABLE > INCONCLUSIVE > ERROR > sauber. Ein nicht erreichbarer Host verdeckt daher niemals einen verwundbaren Befund im Exit-Code.
PATCHED und Exit-Code 0 bedeuten, dass die Größenprüfung für CVE-2026-8452 auf dem Pfad vorhanden ist, den die Sonde erreicht hat. Sie sagen nichts über andere NetScaler-Schwachstellen aus, einschließlich solcher, die nach diesem Fehler offengelegt und in späteren Builds behoben wurden. Betrachten Sie Exit 0 dieses Tools nicht als sauberes Gesundheitszeugnis für ein Gerät.UNAFFECTED bedeutet „hier nicht erreichbar“, nicht „dieses Gerät ist sicher“./saml/login ist geräteweit, aber auf einem virtuellen Server ohne gebundene IdP-Policy antwortet es mit Matching policy not found und bricht vor dem Kanonisierer ab. Ein IdP, dessen Policy eine Ausdrucksregel verwendet, die die Anfrage der Sonde nicht erfüllt, landet in INCONCLUSIVE, statt eine Antwort zu geben.INCONCLUSIVE ist kein sauberes Gesundheitszeugnis. Es wird bewusst von PATCHED durch einen separaten Exit-Code unterschieden, damit Stille niemals für ein bestandenes Ergebnis gehalten wird.INCONCLUSIVE. Wenn die SAML-Policy in einem Policy-Label sitzt, das über nextFactor erreicht wird, statt direkt an den virtuellen Server gebunden zu sein, findet eine unaufgeforderte Assertion keine passende Policy und bricht vor dem Kanonisierer ab. Verifiziert auf einem verwundbaren Build, der INCONCLUSIVE meldete. Da SAML hinter einem Device-Posture- oder Login-Schema-Erstfaktor ein häufiges Muster ist, behandeln Sie INCONCLUSIVE auf einem nFactor-Gateway als „wahrscheinlich erreichbar, mit show ns version bestätigen“, nicht als Kuriosität.VULNERABLE-Urteil bestätigt die fehlende Größenprüfung, also den Patch-Zustand. Es misst nicht, wie weit ein Angreifer die Korruption auf Ihrem Build ausnutzen könnte.Führen Sie ein Upgrade auf 13.1-63.21 oder später bzw. 14.1-73.32 oder später durch (FIPS und NDcPP: 14.1-73.32 FIPS bzw. 13.1-37.277 für 13.1-FIPS und 13.1-NDcPP).
Der Fix für CVE-2026-8452 selbst wurde erstmals in 13.1-63.18 / 14.1-72.61 ausgeliefert, laut CTX696604, und genau diesen Übergang erkennt dieses Tool. Diese Builds wurden inzwischen durch CTX696939 (2026-08-19) abgelöst, das CVE-2026-19489 und CVE-2026-19490 hinzufügt; letzteres ist ein Pre-Authentication-Authentifizierungs-Bypass mit CVSS 9.3. Die Vorbedingung für diese Schwachstelle auf Builds ab 14.1-43.56 / 13.1-61.28 ist eine konfigurierte SAML-Aktion – ein Gerät, das für den Fehler, den dieses Tool prüft, im Scope liegt, ist also wahrscheinlich auch für jene im Scope, und ein PATCHED-Urteil hier ist kein Grund, das Upgrade aufzuschieben. Beide Bulletins werden durch die oben genannten Builds behoben.
Geräte auf 12.1 oder 13.0 haben keinen Fix und werden keinen erhalten – diese Zweige sind End-of-Life und sollten als dauerhaft verwundbar behandelt und auf einen unterstützten Zweig migriert werden.
Zwei weitere Hinweise:
Patchen Sie beide Knoten eines HA-Paars. Ein ungepatchter Secondary ist ein vollständig exponiertes Gerät, sobald er die Rolle übernimmt.
Grenzen Sie Ihr Inventar anhand der SAML-Konfiguration ab, nicht anhand des virtuellen Servertyps. Die Formulierung des Hersteller-Advisories (Gateway- oder AAA-virtueller Server) ist breiter als die Auslösebedingung. Prüfen Sie die laufende Konfiguration auf add authentication samlAction und add authentication samlIdPProfile zusammen mit add authentication vserver und add vpn vserver.
Dies ist getestet, nicht abgeleitet. Auf einem bestätigt verwundbaren Gerät entfernten wir jedes SAML-Objekt, banden an ihrer Stelle einen Nicht-SAML-Authentifizierungsfaktor ein und ließen die AAA-virtuellen Server aktiv und betriebsbereit: Die SAML-Endpunkte antworteten daraufhin auf jede Anfrage mit 404. Sie sind ohne SAML-Konfiguration nicht nur policy-gesteuert – sie existieren nicht. Ein virtueller Server ohne SAML ist daher wirklich außerhalb des Scopes für diesen Fehler, und UNAFFECTED auf einem solchen Ziel ist eine echte Antwort statt eines blinden Flecks. Die Einschränkung, die weiterhin gilt, ist die oben genannte Scoping-Einschränkung: Sie gilt pro virtuellem Server, bestätigen Sie also jede VIP, anstatt etwas über das Gerät zu schließen.
CVE-2026-8452 wurde zusammen mit fünf Geschwistern im selben Bulletin ausgeliefert. Die Schwachstelle, die man zusätzlich im Auge behalten sollte, ist CVE-2026-8451, ein Pre-Authentication-Memory-Overread im SAML-IdP-Pfad, der bereits aktiv in freier Wildbahn ausgenutzt wird. Die beiden teilen sich eine Angriffsfläche, daher deckt dieselbe Konfigurationsprüfung beide ab.
Dieser Code wird unter einer MIT-Lizenz vertrieben.
Die Verwendung dieses Tools zum Angriff auf Ziele ohne vorherige gegenseitige Zustimmung ist illegal. Es liegt in der Verantwortung des Endbenutzers, alle geltenden lokalen, einzelstaatlichen und föderalen Gesetze zu befolgen. Die Entwickler übernehmen keine Haftung und sind nicht verantwortlich für Missbrauch oder Schäden, die durch dieses Programm verursacht werden.