Deux zero-day RCE de Citrix NetScaler sont exploités sans qu’aucun correctif ne soit publié
watchTowr documente deux zero-day d’exécution de code à distance dans Citrix NetScaler ADC et Gateway, déjà exploités avant qu’aucun correctif n’existe. Tant que Citrix n’a rien publié, la seule parade est l’isolement : préserver les preuves, couper l’appliance du réseau et garder la gestion hors d’Internet.
26 septembre 2026. watchTowr annonce sur X l’exploitation active de deux vulnérabilités zero-day d’exécution de code à distance dans Citrix NetScaler ADC et NetScaler Gateway. 26 septembre 2026, 22 h 19 UTC. Un second message de l’entreprise précise le tableau : deux failles RCE, toutes deux non corrigées, exploitées avant qu’aucun correctif n’existe, découvertes lors d’investigations forensiques. Semaine du 28 septembre 2026. C’est la fenêtre dans laquelle Citrix est censé communiquer et publier des correctifs — sans que rien ne soit garanti. Pourquoi c’est important : NetScaler tient la bordure du réseau — VPN, accès distant, répartition de charge, authentification — et une RCE non corrigée sur cette position revient à laisser une porte d’entrée ouverte sur l’ensemble du système d’information.
Deux failles, zéro correctif, zéro bulletin
La situation est inhabituelle, et c’est précisément ce qui la rend dangereuse. watchTowr n’a publié aucune preuve technique, nommé aucune victime, et n’a pas indiqué de quelles investigations forensiques provenaient les traces d’exploitation. Citrix, ou plutôt son propriétaire Cloud Software Group, n’a rien confirmé au moment de la publication : pas de bulletin, pas de correctif, pas d’indicateurs de compromission, pas même une liste de versions concernées.
Le premier message de watchTowr sur X, le 26 septembre 2026, disait réagir à des rumeurs de plusieurs failles RCE non corrigées dans NetScaler. « Tant que les détails sont rares, l’information est crédible », écrivait l’entreprise. Le message de 22 h 19 UTC a fourni le compte rendu complet : deux vulnérabilités, toutes deux des exécutions de code à distance, toutes deux non corrigées, exploitées avant qu’un correctif n’existe, découvertes pendant des investigations forensiques. Citrix était censé communiquer et livrer des correctifs « en début de semaine du 28 septembre ».
Ces nouvelles failles ne sont pas le contournement d’authentification CVE-2026-19490, corrigé le 19 août 2026 et ajouté au catalogue KEV de la CISA le 9 septembre 2026. Pour cette faille-là, un correctif existe depuis août. Pour les deux nouvelles, rien n’existe encore — et c’est la différence entre un bulletin qu’on traite en urgence et un incident qu’on traite dans l’incertitude.
Ce que NetScaler expose à la bordure
NetScaler ADC et NetScaler Gateway ne sont pas des équipements anodins. Ils terminent le SSL, répartissent la charge, et surtout portent l’accès distant : SSL VPN, ICA Proxy, CVPN, RDP Proxy. Ils authentifient les utilisateurs avant que ceux-ci n’atteignent le réseau interne. Une RCE sur cette position signifie qu’un attaquant n’a pas besoin de contourner l’authentification — il exécute du code sur l’appliance elle-même, avant tout contrôle.
C’est exactement le scénario que l’histoire récente a déjà joué. CVE-2019-19781 (« Shitrix ») a été exploitée en masse en janvier 2020. CVE-2023-3519 a suivi en 2023. En 2025, une faille NetScaler exploitée en zero-day contre des organisations néerlandaises a conduit le NCSC des Pays-Bas à publier des scripts de vérification. Et en août 2026, watchTowr avait déjà montré qu’un heap overflow de NetScaler corrigé en juin pouvait être transformé en exécution de code à distance — signe que l’entreprise connaît intimement cette surface d’attaque.
Le précédent de 2025 : patcher ne suffit pas
En 2025, après l’exploitation zero-day d’une faille NetScaler contre des cibles néerlandaises, le National Cyber Security Centre néerlandais a rappelé que mettre à jour seul ne supprime pas le risque. Un attaquant qui a pris pied avant le correctif conserve son accès après la mise à jour. L’agence a donc distribué des scripts de vérification couvrant l’appliance en direct, les core dumps et les images complètes, avec un README honnête : le script cherche des fichiers révélateurs, n’est lié à aucune vulnérabilité particulière et n’offre aucune garantie d’efficacité.
Cette logique s’applique mot pour mot au cas présent. Puisque l’exploitation décrite par watchTowr a eu lieu avant l’existence de tout correctif, installer le futur correctif ne dira jamais à un exploitant si un attaquant est déjà entré. C’est la différence entre un incident de « patch à appliquer » et un incident de « compromission à écarter ».
En ligne, isoler, ou éteindre ?
Sans bulletin, il n’existe aucune mitigation officielle et aucun indicateur de compromission publié. Chaque exploitant de NetScaler doit donc trancher lui-même une décision à trois branches : laisser l’appliance en ligne, l’isoler, ou l’éteindre.
Des administrateurs ont déjà choisi la troisième option. Sur Reddit, un fil du sous-forum r/Citrix rapporte qu’un administrateur a reçu un appel de l’équipe sécurité de son fournisseur informatique lui enjoignant d’éteindre immédiatement ses NetScaler, sans plus de détails. D’autres participants disent avoir fait de même. L’origine précise de ces avertissements de fournisseurs n’est pas établie, mais le réflexe dit quelque chose de la confiance du terrain : quand le bulletin n’existe pas, couper l’exposition est la seule mitigation certaine.
La question des versions ajoute une incertitude de plus. Citrix n’a pas dit si les builds d’août — 14.1-73.32 et 13.1-63.21 — ou des builds plus récents sont concernés par les nouvelles failles. Et NetScaler 13.1 a atteint sa fin de maintenance le 15 septembre 2026 : rien ne garantit qu’il recevra un correctif.
La consigne Citrix en cas de compromission suspectée
Citrix a publié de longue date une procédure pour les appareils suspectés de compromission. Elle vaut comme checklist minimale tant qu’aucun bulletin n’existe. Dans l’ordre : préserver les preuves d’abord — un instantané d’une instance VPX, les journaux des serveurs syslog distants et de la NetScaler Console, un support bundle et un core dump du moteur de paquets. Puis isoler l’appliance du réseau. Changer chaque mot de passe et secret de compte de service stocké dessus, réinitialiser les mots de passe des utilisateurs qui s’y sont connectés, et révoquer ses certificats et clés privées. Enfin, garder l’interface de gestion hors d’Internet — « les services de gestion de NetScaler ne devraient jamais être exposés à l’Internet public », rappelle la documentation.
Cette dernière ligne est la seule mitigation réellement préventive qui existe aujourd’hui, sans bulletin. Une appliance dont l’interface de gestion n’est pas exposée et dont l’accès VPN est restreint à des plages connues réduit la surface sur laquelle une RCE inconnue peut s’exercer, même sans correctif.
Verdict
Si vous exploitez des NetScaler ADC ou Gateway exposés sur Internet, traitez l’incident comme une compromission potentielle, pas comme un simple retard de patch : préservez les preuves, passez vos journaux au crible et préparez-vous à isoler — la première communication de Citrix peut tomber à tout moment et déclencher un scan de masse en quelques heures. Si vous ne pouvez pas vous passer de l’accès distant immédiatement, restreignez le VPN et l’interface de gestion aux plages d’adresses légitimes et surveillez l’appliance comme un hôte déjà suspect, pas comme un équipement sain. Si vos appliances portent du trafic critique, documentez dès maintenant la procédure d’isolement et de reconstruction : une faille exploitée avant correctif laisse, par définition, un doute que seule une reconstruction propre lève. NetScaler est redevenu la cible de bordure par excellence — et cette fois, la première défense n’est pas un patch, c’est la réduction d’exposition.