bishopfox/cve-2026-8452-checkDétecteur comportemental de l'état du correctif pour Citrix NetScaler CVE-2026-8452. Envoie des requêtes SAML spécialement conçues pour déterminer si la vérification de la taille de PrefixList est présente, sans exploiter ni corrompre la mémoire.
Une vérification sûre et non destructive de l'état du correctif pour CVE-2026-8452, le débordement de tas pré-authentification
dans le canonicaliseur de signature SAML de Citrix NetScaler ADC / NetScaler Gateway
(CTX696604,
CVSS 8.8). Un PrefixList de canonicalisation exclusive surdimensionné déborde un tampon de taille fixe lors de la
canonicalisation, que NetScaler effectue avant de valider la signature qui le transporte — donc le
chemin complet est accessible sans identifiants, sans session et sans signature valide. Signalé par Michael
Tucker de l'équipe XOR de JPMorgan Chase ; l'analyse de la cause racine et de l'exploitation est due à
watchTowr Labs.
Ce script n'exploite pas la faille et ne corrompt pas la mémoire. Il répond à une seule question par cible : le correctif est-il présent sur cette appliance ? — déterminé par le comportement, en observant le correctif plutôt qu'en devinant le build.
Oui. Il est conçu pour une utilisation en production et en évaluation :
PrefixList de 512 octets et rejettent 513 ou plus. Cette limite a été localisée à l'octet,
est identique sur les deux branches supportées, et ne bouge pas avec la configuration de l'appliance ni
avec la forme du message SAML environnant — confirmé en sondant les deux routes, qui enveloppent la
valeur dans des quantités de XML sensiblement différentes, et en constatant qu'elles changent de comportement au même
octet. 575 dépasse la limite de 63 octets, donc le verdict ne dépend pas de la configuration d'une cible
donnée.PrefixList. Gonfler d'autres champs au-delà — URL du service de consommateur d'assertion,
noms d'émetteur, identifiants d'algorithme, valeurs de digest et de signature — ne change rien sur un build corrigé, donc
l'application du correctif ne devrait pas faire échouer une configuration SAML fonctionnelle.Si vous modifiez la sonde, ne changez pas
PROBE_PREFIXESet ne balayez pas les longueurs. 575 octets est déterminant. D'autres longueurs dePrefixListpeuvent déstabiliser une appliance, dans au moins un cas sur un build qui porte ce correctif, donc un balayage de longueurs n'est pas un moyen sûr d'explorer cette faille et une longueur plus courte n'est pas plus sûre.
Les builds corrigés rejettent proprement un PrefixList surdimensionné, avec un message distinctif. Les builds non corrigés
passent à travers le parseur et renvoient une erreur interne générique. Une seule requête identique, deux réponses
différentes :
PrefixList de 575 octets | Réponse |
|---|---|
| Non corrigé | 500 Internal Server Error 43549 |
| Corrigé | 200 Malformed Assertion sent to Netscaler |
Deux routes sont essayées, IdP en premier, en s'arrêtant dès que l'une donne une réponse. Chacune est suffisante seule, et ensemble elles couvrent les deux rôles SAML :
| Route | Requête | Prérequis |
|---|---|---|
| 1 (première) | POST /saml/login — AuthnRequest signé, PrefixList dans ds:SignedInfo | une politique IdP SAML liée au vserver ciblé |
| 2 (repli) | POST /cgi/samlauth — SAMLResponse, PrefixList dans la signature d'assertion | un service consommateur d'assertion SP SAML sur le vserver ciblé |
La route IdP passe en premier car elle est la plus robuste des deux. Elle est insensible à la valeur Issuer,
à l'AssertionConsumerServiceURL, et à la dérive d'horloge — un IssueInstant bien en dehors de la
tolérance de dérive de l'appliance discrimine toujours correctement, car la canonicalisation précède la vérification
de temps ainsi que la vérification de signature.
L'
AuthnRequestde la route 1 doit être signé. Une requête non signée renvoie200 Malformed Assertion sent to Netscalersur les builds corrigés et non corrigés, ce qui est identique octet pour octet au signal des builds corrigés, donc une sonde qui omet le bloc de signature rapporte chaque appliance comme corrigée. La signature n'a pas besoin d'être valide, et celle de cet outil ne l'est pas ; elle doit seulement être présente, car sonSignedInfoest ce qui transporte lePrefixListdans le canonicaliseur.
Les deux branches supportées changent de comportement exactement au build de correctif, sur les deux routes :
| Build | Verdict | |
|---|---|---|
13.1-63.16 | dernier 13.1 vulnérable | VULNERABLE |
13.1-63.18 | premier 13.1 corrigé | PATCHED |
14.1-66.59 | 14.1 vulnérable | VULNERABLE |
14.1-72.61 | premier 14.1 corrigé | PATCHED |
13.1-63.16 et 63.18 sont des versions consécutives, donc le changement est attribuable au correctif lui-même
plutôt qu'à une dérive entre les builds intermédiaires.
Ce sont les builds où ce correctif est apparu en premier, et la sonde détecte exactement cette transition.
Ils ne sont plus les builds vers lesquels effectuer la mise à niveau : des bulletins ultérieurs les ont remplacés, donc 13.1-63.18 et
14.1-72.61 répondent tous deux PATCHED ici tout en restant exposés à des problèmes plus récents. Voir
Remédiation pour les builds corrigés actuels.
Parce que cela ne peut pas fonctionner sur cette faille, même en principe. 13.1-63.16 et 13.1-63.18, les builds
immédiatement de part et d'autre du correctif, servent tmindex.html, base.css et
resources.js identiques octet pour octet — le correctif ne touche aucun actif web. Les hash d'actifs statiques entrent également en collision entre les branches, donc une
approche basée sur les hash peut faire correspondre une appliance vulnérable à un build corrigé et la rapporter comme propre,
ce qui est le pire mode de défaillance pour un outil de détection. L'empreinte du build est donc délibérément
non implémentée. L'état du correctif provient de la sonde, ou de show ns version si vous disposez des
identifiants.
./cve_2026_8452_check.py https://gateway.example.com
./cve_2026_8452_check.py https://gateway.example.com:9443