Si vous modifiez la sonde, ne changez pas PROBE_PREFIXES et ne balayez pas les longueurs. 575 octets est déterminant. D'autres longueurs de PrefixList peuvent 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.

Comment ça marche

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 :

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 :

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'AuthnRequest de la route 1 doit être signé. Une requête non signée renvoie 200 Malformed Assertion sent to Netscaler sur 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 son SignedInfo est ce qui transporte le PrefixList dans le canonicaliseur.

Comportement à la limite du correctif

Les deux branches supportées changent de comportement exactement au build de correctif, sur les deux routes :

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.

Pourquoi ne pas identifier le build par empreinte ?

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.

Prérequis

• Python 3.8+, bibliothèque standard uniquement — aucun paquet tiers.

Utilisation```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 ligne de contrôle mérite d'être lue de près : la requête de 35 octets passe le contrôle de taille et est ensuite rejetée pour son IssueInstant obsolète, tandis que la sonde de 575 octets n'est jamais arrivée jusque-là. C'est sur cet ordre que repose toute la méthode — la canonicalisation s'exécute avant le contrôle temporel, tout comme elle s'exécute avant le contrôle de signature.

Un équipement corrigé, la même requête contre la version corrigée. Seule la ligne de sonde diffère — le PrefixList surdimensionné est rejeté par son nom au lieu de retomber sur l'erreur interne :```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]

Le contrôle l'a détecté. Ici, l'endpoint a répondu avec le message corrigé aux deux longueurs, de sorte que la vérification de taille n'a jamais été exercée et que la réponse qui semblait décisive est retirée. C'est le garde-fou contre les faux positifs qui se déclenche, et la raison de son déclenchement est explicitée plutôt que laissée à l'inférence :```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.

Sortie lisible par machine (--json), qui enregistre chaque route tentée. verdict, reason et detail sont les champs faisant autorité ; attempts est la preuve brute, de sorte qu'une tentative individuelle peut indiquer patched sur une cible dont le verdict est 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)" ] } ]

Trois d'entre elles sont des limites de longueur — un corps de requête POST surdimensionné, un RelayState surdimensionné, un nom d'utilisateur extrait trop long. Ce sont les plus importantes, car elles signifient que la requête a été rejetée par une vérification de longueur différente avant d'atteindre celle qui distingue l'état du correctif. Cela signifie généralement que la sonde doit être pointée vers un autre serveur virtuel, et non que l'appliance est saine.

Une de ces 20 apparaît à chaque exécution sur la route IdP : le message timestamp outside the appliance's skew tolerance du contrôle. La sonde transporte un IssueInstant fixe, si bien qu'un contrôle qui passe la vérification de taille est ensuite rejeté en raison de son âge — une propriété de la sonde, et non de l'appliance. Une réponse hors de l'ensemble des 20 est imprimée sur sa propre première ligne au lieu d'une condition nommée.

Toutes produisent encore INCONCLUSIVE, avec la balise other-saml-error. Reconnaître une réponse ne la fait jamais passer à PATCHED : seule une réponse explicite indiquant un build corrigé fait cela, et toute réponse non reconnue retombe également dans INCONCLUSIVE — sous la forme unrecognized-reply. La reconnaissance existe pour indiquer à un opérateur pourquoi une cible n'a pas pu être classifiée, et non pour la classifier.

Codes de sortie

2 est le code de sortie propre à argparse pour un appel invalide, c'est pourquoi les codes de verdict l'évitent. Un script d'encapsulation peut donc distinguer « cette appliance n'a pas pu être classifiée » (3) de « j'ai mal appelé l'outil » (2), ce qu'un schéma qui surchargeait 2 ne permettrait pas.

Lors d'un balayage multi-cibles, le code est choisi par priorité, et non par le pire statut : VULNERABLE > INCONCLUSIVE > ERROR > sain. Un hôte injoignable ne masque donc jamais un résultat vulnérable dans le code de sortie.

Limitations

• Cet outil vérifie une seule CVE, pas le niveau de correctif de l'appliance. PATCHED et le code de sortie 0 signifient que la vérification de taille de la CVE-2026-8452 est présente sur le chemin atteint par la sonde. Ils ne disent rien sur toute autre vulnérabilité NetScaler, y compris celles divulguées après ce bug et corrigées dans des builds ultérieurs. Ne considérez pas le code de sortie 0 de cet outil comme un satisfecit pour une appliance.
• Un verdict non vulnérable est circonscrit au point de terminaison que vous avez sondé. La condition préalable s'applique par serveur virtuel. UNAFFECTED signifie « non joignable ici », et non « cette appliance est sûre ».
• La correspondance des politiques conditionne l'accès à l'analyseur. /saml/login est global à l'appliance, mais sur un serveur virtuel sans politique IdP liée, il répond Matching policy not found et court-circuite avant le canonicalizer. Un IdP dont la politique utilise une règle d'expression que la requête de la sonde ne satisfait pas se retrouvera dans INCONCLUSIVE plutôt que de donner une réponse.
• INCONCLUSIVE n'est pas un satisfecit. Il est délibérément distingué de PATCHED par un code de sortie séparé, afin qu'un silence ne soit jamais pris pour un résultat positif.
• Les déploiements nFactor avec SAML derrière un premier facteur rapportent INCONCLUSIVE. Lorsque la politique SAML se trouve dans une étiquette de politique atteinte par nextFactor plutôt que liée directement au serveur virtuel, une assertion non sollicitée ne trouve aucune politique correspondante et court-circuite avant le canonicalizer. Vérifié sur un build vulnérable, qui a rapporté INCONCLUSIVE. Comme la SAML derrière un premier facteur de posture d'appareil ou de schéma de connexion est une configuration courante, traitez INCONCLUSIVE sur une passerelle nFactor comme « probablement joignable, confirmez avec show ns version », et non comme une curiosité.
• Pas un test d'exploitation. Un verdict VULNERABLE confirme l'absence de la vérification de taille, ce qui correspond à l'état du correctif. Il ne mesure pas jusqu'où un attaquant pourrait mener la corruption sur votre build.
• Uniquement la joignabilité. Un résultat reflète ce que l'appliance expose à la position réseau depuis laquelle vous l'exécutez. Un WAF placé devant l'appliance peut masquer la réponse.

Remédiation

Mettez à niveau vers 13.1-63.21 ou une version ultérieure, ou 14.1-73.32 ou une version ultérieure (FIPS et NDcPP : 14.1-73.32 FIPS, ou 13.1-37.277 pour 13.1-FIPS et 13.1-NDcPP).

Le correctif de la CVE-2026-8452 elle-même a d'abord été livré dans 13.1-63.18 / 14.1-72.61 selon CTX696604, et c'est cette transition que cet outil détecte. Ces builds ont depuis été supplantés par CTX696939 (2026-08-19), qui ajoute CVE-2026-19489 et CVE-2026-19490, cette dernière étant un contournement d'authentification en phase de pré-authentification (CVSS 9.3). Sa condition préalable sur les builds à partir de 14.1-43.56 / 13.1-61.28 est une action SAML configurée — si bien qu'une appliance dans le périmètre du bug que cet outil vérifie est probablement aussi dans le périmètre de cette dernière, et un verdict PATCHED ici n'est pas une raison de différer la mise à niveau. Les deux bulletins sont résolus par les builds ci-dessus.

Les appliances sous 12.1 ou 13.0 n'ont pas de correctif et n'en recevront pas — ces branches sont en fin de vie et doivent être considérées comme définitivement vulnérables et migrées vers une branche prise en charge.

Deux remarques supplémentaires :

• Corrigez les deux nœuds d'une paire HA. Un nœud secondaire non corrigé est une appliance entièrement exposée dès qu'il prend le relais.
• Délimitez votre inventaire par configuration SAML, et non par type de serveur virtuel. La formulation de l'avis du fournisseur (serveur virtuel Gateway ou AAA) est plus large que la condition de déclenchement. Vérifiez la présence de add authentication samlAction et add authentication samlIdPProfile, ainsi que de add authentication vserver et add vpn vserver.

Ce point est testé, pas déduit. Sur une appliance confirmée vulnérable, nous avons retiré chaque objet SAML, lié un facteur d'authentification non SAML à la place, et laissé les serveurs virtuels AAA actifs et en service : les points de terminaison SAML ont alors renvoyé 404 à chaque requête. Ils ne sont pas simplement conditionnés par une politique en l'absence de configuration SAML — ils n'existent pas. Un serveur virtuel sans SAML est donc réellement hors du périmètre de ce bug, et UNAFFECTED sur une telle cible est une vraie réponse, et non un angle mort. La réserve qui s'applique toujours est celle du périmètre ci-dessus : elle vaut par serveur virtuel, confirmez donc chaque VIP plutôt que de conclure quoi que ce soit sur l'appliance.

La CVE-2026-8452 a été publiée aux côtés de cinq vulnérabilités sœurs dans le même bulletin. Celle qu'il vaut la peine de suivre en parallèle est CVE-2026-8451, une sur-lecture mémoire en pré-authentification dans le chemin SAML IdP qui a fait l'objet d'une exploitation active dans la nature. Les deux partagent une surface d'attaque, si bien que le même audit de configuration couvre les deux.

Licence

Ce code est distribué sous licence MIT.

Avertissement légal

L'utilisation de cet outil pour attaquer des cibles sans consentement mutuel préalable est illégale. Il incombe à l'utilisateur final de respecter toutes les lois locales, des États et fédérales applicables. Les développeurs déclinent toute responsabilité et ne sont pas responsables des mauvais usages ou des dommages causés par ce programme.

Voir aussi

• Citrix CTX696604 — bulletin de sécurité NetScaler
• Citrix CTX696939 — bulletin NetScaler ultérieur remplaçant ces builds corrigés
• watchTowr Labs — analyse technique de la CVE-2026-8452
• NVD — CVE-2026-8452