Utilisation

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

Pointez l'outil vers le serveur virtuel Gateway ou AAA, pas vers l'interface de gestion. L'exposition est propre à chaque serveur virtuel, donc une appliance comportant plusieurs VIP doit être testée pour chacune. La sonde porte une enveloppe de sécurité stricte — une seule longueur de RelayState validée, jamais balayée — que Est-il sûr de l'exécuter ? expose.

Options

Exemples

Une appliance vulnérable (la sortie par défaut sur deux lignes). Le marqueur [!] et VULNERABLE s'affichent en rouge sur un TTY :

Une appliance corrigée :

Le garde-fou anti-faux-positif qui se déclenche. La sonde et le contrôle de même longueur ont tous deux renvoyé le signal non corrigé, donc la réponse ne dépend pas de ce qui a été envoyé et la réponse d'apparence décisive est retirée :

Balayage d'un parc (--brief). Les deux lignes gateway.example.com sont les serveurs virtuels SP et IdP-only sur la même appliance — les deux répondent, ce qu'une vérification de précondition de configuration ne parviendrait pas à faire :

Sortie lisible par machine (--json). Chaque requête est incluse, de sorte qu'une conclusion peut être redérivée à partir des preuves plutôt que d'être crue sur parole. Le contrôle est enregistré par sa relation à la sonde plutôt que comme un verdict qui lui est propre, car un contrôle qui se lit comme une version corrigée est le résultat attendu sur toutes les versions :

Est-il sûr de l'exécuter ?

Oui. Il est conçu pour un usage en production et en évaluation :

• Une longueur fixe, jamais un balayage. Le RelayState de la sonde se décode en exactement 20 octets et l'outil n'envoie aucune autre longueur sous aucun drapeau. Sur une appliance non corrigée, la longueur décodée est le sélecteur de branche, et les branches incluent celles qui créent une session et celles qui provoquent un SIGSEGV du moteur de paquets — redémarrant tout le NetScaler et interrompant le trafic pendant environ 45 secondes. Vingt octets aboutissent à une branche d'erreur interne propre qui ne crée aucune session, et le constructeur de charge utile refuse de construire toute autre longueur, de sorte qu'une modification ailleurs ne peut pas élargir discrètement la sonde.
• Validé par mesure. La sonde de 20 octets a été exécutée 10 fois consécutivement contre une version non corrigée 13.1-63.18 sans aucun core généré et sans redémarrage du moteur de paquets. La vérification elle-même a depuis été exécutée contre les deux branches de maintenance, des deux côtés du correctif, et contre des serveurs virtuels fournisseur de services et IdP-only, sans redémarrage du moteur de paquets sur aucun d'entre eux.
• Aucune authentification, aucun matériel d'identification, aucun changement d'état. Aucune assertion, signature, horodatage, session ou certificat client n'est présenté nulle part dans cette vérification. Le paramètre SAMLResponse doit être présent pour que la branche RelayState soit atteinte, mais son contenu est sans importance, donc ce sont quatre octets de remplissage. La branche n'émet aucun cookie et n'écrit aucune configuration.
• Garde-fou anti-faux-positif. VULNERABLE n'est jamais signalé sur une seule réponse — voir le contrôle.

Si vous modifiez la sonde, ne changez pas la longueur du RelayState décodé et ne balayez pas les longueurs. Vingt octets sont porteurs, et plus court n'est pas plus sûr. D'autres longueurs sont au mieux non testées et au pire une panne d'appliance.

Empreinte des requêtes et des journaux

Trois requêtes HTTP par cible, et une quatrième uniquement lorsque l'appliance renvoie le signal non corrigé :

Les redirections ne sont pas suivies et aucun cookie n'est jamais renvoyé — NetScaler sert un NSC_DLGE expiré qu'un client rejouant la requête transporterait dans la requête 4, transformant le POST en page de connexion.

nsppe journalise le POST SAML dans /var/log/ns.log au niveau informationnel, sans nécessiter de commutateur de débogage, comme un échec de désérialisation de contexte nFactor incluant la ligne nFactor: ctx deserialize aaa_info, base64 decode failed. Il n'y a aucune ligne de création de session ou de connexion à cette longueur, ce qui distingue un scan d'une tentative de contournement.

Comment ça fonctionne

Le correctif est une seule instruction. Lors d'une désérialisation de contexte échouée, la version vulnérable reporte la longueur du RelayState décodé comme statut de la requête ; la version corrigée reporte l'erreur constante 0xe0005, rendue comme Malformed Assertion. Ainsi un seul POST les sépare :

La version corrigée répond Malformed Assertion à toutes les longueurs, ce qui fait de la réponse non corrigée un oracle plutôt qu'une coïncidence.

Le contrôle est ce qui donne un sens à un 500

VULNERABLE repose sur une seule réponse distinctive, donc l'outil vérifie que la réponse dépend réellement de ce qui a été envoyé. Après le signal non corrigé, il répète la requête avec un RelayState de contrôle de la même longueur décodée de 20 octets, ne différant que par les 16 octets après ctx=. Ce contenu est rejeté par un garde en amont du désérialiseur, donc toutes les versions testées — corrigées et non corrigées — y répondent 200 Malformed Assertion. Le verdict ne tient que si les deux réponses diffèrent. Si elles correspondent, quelque chose renvoie 500/43524 indépendamment de l'entrée, et le résultat est INCONCLUSIVE étiqueté flat-response plutôt qu'un faux VULNERABLE. Maintenir le contrôle à la même longueur décodée le garde à l'intérieur de l'enveloppe de sécurité validée et isole le contenu comme seule variable.

Le garde est unidirectionnel. Il ne peut pas valider un verdict PATCHED, car une appliance véritablement corrigée répond de manière identique à la sonde et au contrôle — c'est ce que signifie être corrigé ici. Voir Limitations.

Il répond aussi sur les serveurs virtuels IdP-only

La désérialisation de RelayState s'exécute avant la correspondance de politique SAML, donc un serveur virtuel ne portant qu'un samlIdPPolicy répond à la sonde, pas seulement celui avec un samlAction de fournisseur de services lié. C'est une couverture plus large qu'une vérification de précondition de configuration ne peut offrir.

Un non-résultat n'est jamais une affirmation de sécurité

La réponse vulnérable est la seule auto-corroborante : elle porte un marqueur spécifique, et le contrôle prouve que la réponse dépend de ce qui a été envoyé. PATCHED est aussi une preuve positive — l'erreur corrigée de l'appliance elle-même sur le chemin atteint par la sonde — mais elle est limitée à ce CVE et à ce chemin. INCONCLUSIVE et ERROR ne sont pas du tout des preuves : la sonde n'a jamais atteint le désérialiseur, donc l'état du correctif est inconnu, et c'est pourquoi INCONCLUSIVE est un verdict distinct plutôt que fusionné dans PATCHED. Rapporter le silence comme une réussite se trompe dans la direction dangereuse. Là où vous avez besoin de certitude, confirmez avec show ns version par rapport aux versions dans Remédiation.

Verdicts

Chaque verdict porte une courte étiquette reason. --brief l'affiche comme troisième colonne et --json la porte comme reason.

Les quatre raisons INCONCLUSIVE signifient la même chose pour la prise de décision — inconnu, pas corrigé. L'étiquette nomme la condition à corriger avant de relancer.

Codes de sortie

Le code de sortie 0 n'est pas un certificat de bonne santé. PATCHED, UNAFFECTED et les quatre raisons INCONCLUSIVE s'y fondent, et une seule d'entre elles est un résultat positif. Un wrapper qui doit distinguer « corrigé » de « impossible à classer » doit lire le verdict — première colonne de --brief, ou le champ verdict de --json — et non le code de sortie.

Limitations

• Un WAF ou un équilibreur de charge peut fausser un verdict PATCHED. Malformed Assertion est ce que l'appliance renvoie chaque fois que la sonde n'atteint pas le désérialiseur de contexte, et être corrigée n'est qu'une des raisons pour lesquelles cela se produit. Un dispositif interposé qui supprime, altère ou court-circuite le paramètre RelayState produit donc PATCHED sur une appliance vulnérable, et aucune requête supplémentaire que l'outil pourrait envoyer ne séparerait les deux. Là où quelque chose peut se trouver devant l'appliance, confirmez avec show ns version.
• UNAFFECTED est limité aux versions actuelles. Sur 14.1-43.55 / 13.1-61.27 et antérieures, l'avis indique que l'exposition ne nécessite pas du tout d'action SAML — tout serveur virtuel Gateway ou AAA est affecté — donc un 404 sur une telle version ne met pas l'appliance hors de portée. Ce point est tiré de l'avis plutôt que mesuré.
• Ceci vérifie un seul CVE, pas le niveau de correctif de l'appliance. PATCHED ne dit rien sur aucune autre vulnérabilité NetScaler, y compris CVE-2026-19489 dans le même bulletin.
• Ce n'est pas une vérification d'exploitation, ni une vérification de compromission. VULNERABLE établit que le correctif est absent sur le chemin atteint par la sonde. Cela ne mesure pas jusqu'où un attaquant pourrait pousser le contournement sur votre configuration, et cela ne vous dira pas si quelqu'un l'a déjà fait — traquez cela séparément dans /var/log/ns.log.
• Il ne peut pas vous dire si les branches de déni de service sont atteignables. L'outil envoie une seule longueur validée et n'explore jamais les autres, par conception.
• Atteignabilité. Un résultat reflète ce que l'appliance expose à la position réseau depuis laquelle vous l'exécutez.

Remédiation

Mettez à niveau vers 13.1-63.21 ou ultérieure, ou 14.1-73.32 ou ultérieure (FIPS et NDcPP : 13.1-37.277 pour 13.1-FIPS et 13.1-NDcPP, 14.1-73.32 FIPS pour 14.1-FIPS), selon CTX696939. Les appliances sur 12.1 ou 13.0 n'ont pas de correctif et n'en recevront pas — ces branches sont en fin de vie et devraient être migrées vers une branche prise en charge.

Trois notes supplémentaires :

• Corrigez les deux nœuds d'une paire HA. Un secondaire non corrigé est une appliance pleinement exposée dès qu'il prend le relais.
• Si vous ne pouvez pas corriger aujourd'hui, vérifiez le seul commutateur global qui borne l'impact. La session que ce bug crée sur un serveur virtuel Gateway ignore l'évaluation de politique de session, donc elle ne reprend pas le defaultAuthorizationAction d'un vpn sessionAction lié au vserver — elle retombe sur le set vpn parameter -defaultAuthorizationAction global. La valeur par défaut livrée est DENY ; ALLOW est courant sur le terrain car c'est ce vers quoi les administrateurs se tournent au lieu d'écrire des politiques d'autorisation par utilisateur, et ALLOW est ce qui permet à la session non authentifiée d'atteindre les ressources internes. C'est global, pas par vserver. Cela borne l'impact ; ce n'est pas un correctif.
• Délimitez votre inventaire par configuration SAML, pas par type de serveur virtuel. Vérifiez la configuration en cours d'exécution pour add authentication samlAction et add authentication samlIdPProfile aux côtés de add authentication vserver et add vpn vserver — sous réserve de la mise en garde sur les versions plus anciennes ci-dessus.

CTX696939 corrige aussi CVE-2026-19489, et cette surface chevauche fortement CVE-2026-8452 du bulletin précédent : sur les versions à partir de 14.1-43.56 / 13.1-61.28, les deux problèmes sont conditionnés à une action SAML configurée, donc un seul audit de configuration délimite les deux.

Licence

Ce code est distribué sous une licence MIT.

Avertissement juridique

L'utilisation de cet outil pour attaquer des cibles sans consentement mutuel préalable est illégale. Il est de la responsabilité de l'utilisateur final de respecter toutes les lois locales, étatiques et fédérales applicables. Les développeurs n'assument aucune responsabilité et ne sont pas responsables de tout usage abusif ou dommage causé par ce programme.

Voir aussi

• Citrix CTX696939 — bulletin de sécurité NetScaler
• NVD — CVE-2026-19490
• NVD — CVE-2026-19489
• NVD — CVE-2026-8452