Se modifichi la sonda, non cambiare PROBE_PREFIXES e non eseguire scansioni su più lunghezze. 575 byte sono un elemento portante. Altre lunghezze di PrefixList possono destabilizzare un appliance, in almeno un caso su una build che include questa correzione, quindi una scansione di lunghezze non è un modo sicuro per esplorare questa vulnerabilità e più corto non significa più sicuro.

Come funziona

Le build patchate rifiutano un PrefixList di dimensioni eccessive in modo pulito, con un messaggio distintivo. Le build non patchate superano il parser e restituiscono un errore interno generico. Una richiesta identica, due risposte diverse:

Vengono provate due route, prima la IdP, fermandosi appena una fornisce una risposta. Una sola è sufficiente, e insieme coprono entrambi i ruoli SAML:

La route IdP viene per prima perché è la più robusta delle due. È insensibile al valore di Issuer, a AssertionConsumerServiceURL e alla deriva dell'orologio — un IssueInstant ben al di fuori della tolleranza di deriva dell'appliance discrimina comunque correttamente, perché la canonicalizzazione precede sia il controllo temporale sia il controllo della firma.

La AuthnRequest della route-1 deve essere firmata. Una non firmata restituisce 200 Malformed Assertion sent to Netscaler sia sulle build patchate che su quelle non patchate, un segnale byte-identico a quello delle build patchate, quindi una sonda che omette il blocco della firma segnala ogni appliance come patchato. La firma non deve essere valida, e quella di questo strumento non lo è; deve solo essere presente, perché è il suo SignedInfo a trasportare il PrefixList nel canonicalizzatore.

Comportamento al confine della correzione

Entrambi i rami supportati cambiano comportamento esattamente in corrispondenza della build di correzione, su entrambe le route:

13.1-63.16 e 63.18 sono release consecutive, quindi il cambiamento è attribuibile alla patch stessa piuttosto che a derive tra build intermedie.

Queste sono le build in cui è apparsa per la prima volta questa correzione, e la sonda rileva esattamente quella transizione. Non sono più le build a cui aggiornare: bollettini successivi le hanno superate, quindi sia 13.1-63.18 che 14.1-72.61 rispondono PATCHED qui pur rimanendo esposte a problemi più recenti. Vedi Remediation per le build corrette attuali.

Perché non identificare la build tramite impronta?

Perché non può funzionare su questa vulnerabilità, nemmeno in linea di principio. 13.1-63.16 e 13.1-63.18, le build immediatamente a cavallo della correzione, servono tmindex.html, base.css e resources.js byte-identici — la correzione non tocca alcuna risorsa web. Anche gli hash delle risorse statiche collidono tra i rami, quindi un approccio basato su hash può risolvere un appliance vulnerabile in una build patchata e segnalarlo come pulito, che è la modalità di errore peggiore per uno strumento di rilevamento. Il fingerprinting della build è quindi deliberatamente non implementato. Lo stato della patch deriva dalla sonda, o da show ns version dove si dispone delle credenziali.

Requisiti

• Python 3.8+, solo libreria standard — nessun pacchetto di terze parti.

Utilizzo```bash

single target

./cve_2026_8452_check.py https://gateway.example.com

a specific AAA / Gateway virtual server

./cve_2026_8452_check.py https://gateway.example.com:9443

scan a list, one target per line ('#' comments allowed), compact output

./cve_2026_8452_check.py -f targets.txt --brief

machine-readable output for pipelines

./cve_2026_8452_check.py -f targets.txt --json > results.json

La riga di controllo merita una lettura attenta: la richiesta da 35 byte supera il controllo della dimensione e viene poi respinta per il suo IssueInstant scaduto, mentre la sonda da 575 byte non è mai arrivata a quel punto. Questo è l'ordine su cui si basa l'intero metodo: la canonicalizzazione avviene prima del controllo temporale, proprio come avviene prima del controllo della firma.

Un'appliance patchata, la stessa richiesta contro la build corretta. Solo la riga della sonda differisce: la PrefixList sovradimensionata viene respinta per nome invece di ricadere nell'errore interno:```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)

https://vpn.example.com via IDP [size-check-present]

Il controllo lo ha rilevato. Qui l'endpoint ha risposto con il messaggio corretto a entrambe le lunghezze, quindi il controllo della dimensione non è mai stato esercitato e la risposta apparentemente decisiva viene ritirata. Questo è l'intervento della protezione contro i falsi positivi, e il motivo per cui è scattata è dichiarato anziché lasciato dedurre:```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

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.

Output leggibile dalla macchina (--json), che registra ogni route tentata. verdict, reason e detail sono i campi autorevoli; attempts è l'evidenza grezza, quindi un singolo tentativo può indicare patched su un target il cui verdetto è INCONCLUSIVE:```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)" ] } ]

Tre di esse sono limiti di lunghezza — un corpo POST troppo grande, un RelayState troppo grande, un nome utente estratto troppo lungo. Queste contano di più, perché significano che la richiesta è stata rifiutata da un controllo di lunghezza diverso prima di raggiungere quello che distingue lo stato della patch. Di solito significa che la sonda deve essere puntata su un server virtuale diverso, non che l'appliance sia a posto.

Uno dei 20 compare in ogni esecuzione del percorso IdP: il message timestamp outside the appliance's skew tolerance del controllo. La sonda trasporta un IssueInstant fisso, quindi un controllo che supera il controllo di dimensione viene poi rifiutato per la sua età — una proprietà della sonda, non dell'appliance. Una risposta al di fuori dell'insieme dei 20 viene stampata come prima riga autonoma invece di una condizione denominata.

Tutte producono comunque INCONCLUSIVE, etichettate come other-saml-error. Riconoscere una risposta non la promuove mai a PATCHED: solo una risposta esplicita di build patchata lo fa, e ogni risposta non riconosciuta ricade anch'essa in INCONCLUSIVE — come unrecognized-reply. Il riconoscimento serve a dire a un operatore perché un target non ha potuto essere classificato, non a classificarlo.

Exit codes

2 è il codice di uscita di argparse per un'invocazione errata, quindi i codici di verdetto lo saltano. Uno script wrapper può quindi distinguere "questa appliance non ha potuto essere classificata" (3) da "ho chiamato male lo strumento" (2), cosa che uno schema che sovraccarica 2 non potrebbe.

In un'analisi multi-target il codice viene scelto per priorità, non per lo stato peggiore: VULNERABLE > INCONCLUSIVE > ERROR > pulito. Un host irraggiungibile quindi non maschera mai un riscontro di vulnerabilità nel codice di uscita.

Limitations

• Questo controlla una singola CVE, non il livello di patch dell'appliance. PATCHED e codice di uscita 0 significano che il controllo della dimensione di CVE-2026-8452 è presente sul percorso raggiunto dalla sonda. Non dicono nulla su qualsiasi altra vulnerabilità NetScaler, incluse quelle divulgate dopo questo bug e corrette in build successive. Non interpretare l'uscita 0 di questo strumento come un attestato di piena salute per un'appliance.
• Un verdetto non vulnerabile è limitato all'endpoint che hai sondato. La precondizione è per server virtuale. UNAFFECTED significa "non raggiungibile qui", non "questa appliance è sicura".
• Il matching delle policy condiziona il parser. /saml/login riguarda l'intera appliance, ma su un server virtuale senza policy IdP associata risponde Matching policy not found e va in cortocircuito prima del canonicalizzatore. Un IdP la cui policy usa una regola di espressione che la richiesta della sonda non soddisfa finirà in INCONCLUSIVE piuttosto che dare una risposta.
• INCONCLUSIVE non è un attestato di piena salute. È deliberatamente distinto da PATCHED con un codice di uscita separato, così che il silenzio non venga mai scambiato per un risultato positivo.
• Le distribuzioni nFactor con SAML dietro un primo fattore riportano INCONCLUSIVE. Quando la policy SAML si trova in un'etichetta di policy raggiunta da nextFactor invece di essere associata direttamente al server virtuale, un'asserzione non richiesta non trova alcuna policy corrispondente e va in cortocircuito prima del canonicalizzatore. Verificato su una build vulnerabile, che ha riportato INCONCLUSIVE. Poiché SAML dietro un primo fattore device-posture o login-schema è uno schema comune, tratta INCONCLUSIVE su un gateway nFactor come "probabilmente raggiungibile, conferma con show ns version", non come una curiosità.
• Non è un controllo di sfruttamento. Un verdetto VULNERABLE conferma la mancanza del controllo di dimensione, che è lo stato della patch. Non misura quanto lontano un attaccante potrebbe spingere la corruzione sulla tua build.
• Solo raggiungibilità. Un risultato riflette ciò che l'appliance espone dalla posizione di rete da cui lo esegui. Un WAF davanti all'appliance può mascherare la risposta.

Remediation

Aggiorna a 13.1-63.21 o successiva, oppure 14.1-73.32 o successiva (FIPS e NDcPP: 14.1-73.32 FIPS, oppure 13.1-37.277 per 13.1-FIPS e 13.1-NDcPP).

Il fix per la stessa CVE-2026-8452 è stato distribuito per la prima volta in 13.1-63.18 / 14.1-72.61 secondo CTX696604, e questa è la transizione che questo strumento rileva. Quelle build sono state successivamente superate da CTX696939 (2026-08-19), che aggiunge CVE-2026-19489 e CVE-2026-19490, quest'ultima un bypass di autenticazione pre-autenticazione con CVSS 9.3. La sua precondizione sulle build dalla 14.1-43.56 / 13.1-61.28 in poi è un'azione SAML configurata — quindi un'appliance nell'ambito del bug che questo strumento controlla è probabilmente nell'ambito anche di quello, e un verdetto PATCHED qui non è un motivo per rimandare l'aggiornamento. Entrambi i bollettini sono risolti dalle build sopra indicate.

Le appliance su 12.1 o 13.0 non hanno fix e non lo riceveranno — quei rami sono a fine vita e le appliance devono essere trattate come permanentemente vulnerabili e migrate a un ramo supportato.

Due ulteriori note:

• Applica la patch a entrambi i nodi di una coppia HA. Un secondario non patchato è un'appliance completamente esposta nel momento in cui subentra.

• Delimita il tuo inventario in base alla configurazione SAML, non al tipo di server virtuale. La formulazione dell'avviso del vendor (Gateway o AAA virtual server) è più ampia della condizione di attivazione. Controlla la configurazione in esecuzione per add authentication samlAction e add authentication samlIdPProfile insieme a add authentication vserver e add vpn vserver.

  Questo è testato, non dedotto. Su un'appliance confermata vulnerabile abbiamo rimosso ogni oggetto SAML, associato al suo posto un fattore di autenticazione non SAML, e lasciato i server virtuali AAA attivi e funzionanti: gli endpoint SAML hanno quindi restituito 404 a ogni richiesta. Non sono semplicemente limitati da policy senza configurazione SAML — non esistono. Quindi un server virtuale senza SAML è realmente fuori ambito per questo bug, e UNAFFECTED su un tale target è una risposta reale, non un punto cieco. L'avvertenza che vale ancora è quella dell'ambito di cui sopra: è per server virtuale, quindi conferma ogni VIP piuttosto che trarre conclusioni sull'appliance.

CVE-2026-8452 è stata distribuita insieme a cinque vulnerabilità sorelle nello stesso bollettino. Quella che vale la pena monitorare accanto ad essa è CVE-2026-8451, un overread di memoria pre-autenticazione nel percorso SAML IdP che ha visto uno sfruttamento attivo in natura. Le due condividono una superficie di attacco, quindi la stessa verifica della configurazione copre entrambe.

License

Questo codice è distribuito sotto una licenza MIT.

Legal Disclaimer

L'utilizzo di questo strumento per attaccare target senza il preventivo consenso reciproco è illegale. È responsabilità dell'utente finale rispettare tutte le leggi locali, statali e federali applicabili. Gli sviluppatori non si assumono alcuna responsabilità e non sono responsabili di qualsiasi uso improprio o danno causato da questo programma.

See Also

• Citrix CTX696604 — Bollettino di sicurezza NetScaler
• Citrix CTX696939 — Bollettino NetScaler successivo che sostituisce quelle build corrette
• watchTowr Labs — Analisi tecnica di CVE-2026-8452
• NVD — CVE-2026-8452