NetScaler, la faille qui révèle les limites d'une simple page de connexion

Une exploitation qui précède la connexion

Citrix a indiqué, dans un bulletin du 27 septembre 2026, avoir observé l'exploitation de CVE-2026-88771 et CVE-2026-88772. Une référence CVE est un identifiant public attribué à une vulnérabilité. La première faille autorise l'exécution de commandes sans connexion préalable sur les équipements touchés, y compris avec leur configuration par défaut. Pour une organisation, le danger apparaît donc avant même que le portail vérifie l'identité du visiteur.

La seconde vulnérabilité concerne les configurations utilisant DTLS, un protocole qui protège des échanges réseau transportés sans connexion continue. D'autres avis, publiés les 3 et 8 octobre, ont visé des configurations SAML. Ce standard sert à transmettre des informations d'identité entre services. Les attaques décrites pouvaient lancer des scripts arbitraires sur les machines ciblées et provoquer un déni de service, donc rendre un service indisponible.

Pourquoi le portail devient un point faible

Dans un déploiement Citrix courant, NetScaler Gateway reçoit d'abord la connexion de l'utilisateur. Il transmet ensuite une preuve sécurisée à StoreFront, qui affiche les applications et bureaux autorisés. L'application Citrix installée sur l'appareil ouvre alors une autre connexion avec le protocole ICA. Ce protocole transporte l'affichage et les interactions du bureau distant. Le portail valide enfin le ticket avant de relayer cette session.

Cette chaîne explique l'exposition. Le service initial doit rester joignable depuis Internet pour que les utilisateurs puissent démarrer leur bureau. Une faille située à cet endroit touche donc un composant placé avant plusieurs contrôles ultérieurs. Les portails de bureau distant, interfaces d'administration et autres pages d'authentification publiques partagent cette faiblesse. Leur présence en ligne donne aux attaquants une surface qu'ils peuvent tester sans posséder de compte.

La méthode proposée déplace le premier filtre

Cloudflare part de cette observation pour proposer un contrôle indépendant devant le serveur d'authentification. Sa méthode consiste à imposer une connexion unique avant que la requête atteigne NetScaler. Cloudflare Access décide alors qui peut seulement approcher l'application. L'environnement Citrix conserve ses fonctions habituelles, comme le choix du bureau autorisé et la validation du ticket de session. La première barrière ne dépend ainsi plus du seul logiciel exposé.

Cette approche relève du modèle Zero Trust, ou confiance zéro. Celui-ci exige une décision d'accès explicite plutôt qu'une confiance accordée par défaut. L'interprétation de Cloudflare est qu'une réduction préalable de l'exposition limite la portée d'une future faille inconnue. Un visiteur non autorisé rencontre la page Cloudflare, sans atteindre directement le portail NetScaler pour lui envoyer une tentative d'exploitation.

Une barrière inutile si l'origine reste accessible

Déplacer la page visible ne suffit pourtant pas. Si le serveur répond encore sur son adresse d'origine ou sur un autre nom, un attaquant peut éviter le contrôle ajouté. Cloudflare présente plusieurs moyens de fermer ce détour. Un tunnel sortant peut supprimer tout trafic entrant vers une adresse publique. Si cette adresse doit rester, le pare-feu du serveur peut limiter les sources admises aux adresses réservées au compte.

D'autres vérifications ajoutent des couches. Le serveur peut authentifier la connexion venant de Cloudflare avec un certificat présenté par les deux parties. Il peut aussi valider un jeton JSON, une preuve signée contenant notamment son émetteur, son expiration et l'application visée. En parallèle, un pare-feu applicatif web, ou WAF, examine les requêtes HTTP destinées au service. Cloudflare a publié une règle d'urgence de ce type le 1er octobre.

Ce que l'analyse démontre, et ce qu'elle laisse ouvert

Le correctif Citrix reste la réponse immédiate décrite par la publication. Chaque équipement doit être recensé, mis à jour puis testé, avec un risque d'interruption pour les utilisateurs. Un WAF peut donner du temps pendant ce déploiement, mais il réagit à des formes d'attaque connues ou estimées malveillantes. Cloudflare soutient que l'intelligence artificielle accélère la découverte de variantes, ce qui renforce selon lui l'intérêt de défenses indépendantes et cumulées.

Les limites sont importantes. Protéger l'authentification web ne couvre pas automatiquement les autres services de la passerelle, notamment les interfaces utilisant DTLS. Le transport du bureau distant demande une conception réseau et des règles distinctes. Cloudflare présente une architecture logique, pas le résultat mesuré d'un déploiement client ni un ordre technique strict. Certains contrôles sont facultatifs et dépendent de la configuration ainsi que des droits associés au service.

Pour vérifier sa méthode, Cloudflare propose de tester le portail sans connexion, puis avec un compte extérieur au groupe autorisé. Il faut aussi essayer les adresses directes et les noms alternatifs afin de repérer un éventuel contournement. Un utilisateur approuvé doit encore pouvoir ouvrir son bureau et reprendre sa session. Enfin, les journaux du contrôle d'accès, du pare-feu et du serveur doivent confirmer le parcours observé. Ces essais restent à répéter après une modification du routage, de l'identité ou du mécanisme de secours.