Ce que Citrix Bleed 2 expose réellement
Citrix Bleed 2, référencée sous CVE-2025-5777, est une faille de sécurité mémoire dans les équipements que beaucoup d’organisations utilisent comme porte d’entrée exposée sur internet : Citrix NetScaler ADC et NetScaler Gateway. Selon les informations de BleepingComputer, le bug est une lecture mémoire hors limites qui permet à un attaquant non authentifié d’extraire des données de zones mémoire restreintes de l’appareil — sans identifiant valide. En pratique, cette mémoire divulguée peut contenir des jetons de session utilisateur actifs.
Le nom est délibéré. Il fait écho au « Citrix Bleed » original (CVE-2023-4966) de 2023, exploité à grande échelle contre des cibles de la santé et de la finance dans le monde entier. La suite de 2025 suit le même schéma : lire une mémoire que l’on ne devrait pas pouvoir lire, récupérer tout élément de session qui s’y trouve, et le réutiliser.
Les versions affectées sont précises. Les appareils sont vulnérables sur les versions antérieures à 14.1-43.56, antérieures à 13.1-58.32, et sur les versions FIPS et NDcPP antérieures à 13.1-37.235-FIPS/NDcPP et 12.1-55.328-FIPS/NDcPP. Le bulletin de sécurité CTX693420 de Citrix documente les versions corrigées et les étapes de remédiation. Seuls les appareils configurés en Gateway (serveur virtuel VPN, ICA Proxy, CVPN, RDP Proxy) ou en serveur virtuel d’authentification AAA sont exposés — mais cette configuration décrit exactement le rôle d’accès distant pour lequel la plupart des entreprises déploient NetScaler.
Le calendrier compte ici. Citrix a publié le correctif le 17 juin 2025. En une dizaine de jours, la société de sécurité ReliaQuest a signalé des signes d’exploitation dans la nature, et une preuve de concept publique a suivi début juillet. Le 10 juillet 2025, la CISA a ajouté CVE-2025-5777 à son catalogue des vulnérabilités activement exploitées et a donné aux agences fédérales un seul jour pour remédier — un délai inhabituellement court qui signale le sérieux avec lequel l’agence a évalué le risque.
Pourquoi un jeton de session volé franchit directement la MFA
La raison pour laquelle cette vulnérabilité est dangereuse au-delà de sa description de « lecture mémoire » tient à ce que ces octets représentent. Un jeton de session est la preuve qu’un utilisateur s’est déjà authentifié. Si un attaquant vole un jeton valide dans la mémoire de l’appareil, il peut le rejouer et hériter de cette session — y compris toute authentification multifacteur satisfaite au démarrage de la session. L’invite MFA ne se déclenche jamais une seconde fois, car du point de vue de la passerelle, la session est déjà de confiance.
Ce n’est pas théorique. L’analyse par Arctic Wolf de la campagne de rançongiciel Anubis décrit exactement cette chaîne : des acteurs malveillants ont extrait des éléments de session d’appareils NetScaler exposés, utilisé les jetons récupérés pour contourner la MFA, et établi un point d’ancrage depuis des adresses IP publiques liées à des fournisseurs d’hébergement VPS. Le groupe Anubis — apparu publiquement vers le 23 février 2025 — a ensuite déployé cloudflared (le client de tunnel de Cloudflare) pour construire des canaux sortants furtifs, ajouté des outils légitimes de gestion à distance comme ScreenConnect, Zoho Assist et MeshAgent, exécuté Mimikatz pour récolter des identifiants, et utilisé rclone, s5cmd et S3 Browser pour exfiltrer des données avant le chiffrement.
Des groupes de rançongiciels ont publiquement discuté de la faille sur des forums de pirates, selon The Hacker News, ce qui est le schéma qui transforme une seule CVE divulguée en voie d’intrusion banalisée. Pour une banque, un opérateur télécom ou une grande entreprise, la séquence — vol de jeton, contournement MFA, tunnel, extraction d’identifiants, exfiltration — constitue une compromission complète, pas une alerte évitée de justesse. Et comme le point d’entrée est un appareil exposé sur l’internet public par conception, la géographie n’offre aucune protection : un appareil à Alger est aussi accessible qu’un appareil à Francfort.
Publicité
Ce que les équipes IT et sécurité algériennes devraient faire cette semaine
Ceci est un avis proactif. Rien ici n’affirme qu’une organisation algérienne spécifique est compromise — le point est que NetScaler est un produit d’accès distant largement déployé, que la faille est activement exploitée à l’échelle mondiale, et que les mesures défensives sont peu coûteuses par rapport aux conséquences. Voici la séquence concrète pour toute équipe utilisant NetScaler ADC ou Gateway.
1. Inventoriez chaque appareil NetScaler et confirmez son numéro de version dès aujourd’hui
Avant toute chose, répondez à une question avec certitude : combien d’instances NetScaler exploitons-nous, et sur quelle version chacune fonctionne-t-elle ? Vérifiez à la fois la production et tout appareil de test, de reprise après sinistre (DR) ou de filiale acquise oublié — les passerelles fantômes sont la façon dont les programmes de correctifs manquent la seule machine qui compte. Consignez la chaîne de firmware exacte (par ex. 13.1-55.x) par rapport aux seuils corrigés : 14.1-43.56, 13.1-58.32, 13.1-37.235-FIPS/NDcPP, 12.1-55.328-FIPS/NDcPP. Tout ce qui est en dessous de sa bande est vulnérable. Ne vous fiez pas à « on pense avoir corrigé en juin » — vérifiez la version en cours d’exécution sur l’appareil lui-même, car un correctif planifié qui a échoué silencieusement est identique à un correctif réussi jusqu’à ce que vous vérifiiez.
2. Corrigez vers les versions corrigées — et retirez les versions en fin de vie plutôt que de les entretenir
Mettez à niveau chaque appareil vulnérable vers la version corrigée de sa branche, en suivant le chemin de mise à niveau du bulletin CTX693420. Si un appareil est sur NetScaler 12.1 ou 13.0 non-FIPS — des branches que Citrix a placées en fin de vie — aucun correctif n’arrive ; la solution est de migrer vers une branche prise en charge (13.1 ou 14.1). Planifiez la fenêtre de maintenance maintenant plutôt que d’attendre une semaine « plus calme », car la fenêtre d’exploitation est déjà ouverte. Pour les paires haute disponibilité, corrigez et validez d’abord le secondaire, basculez, puis corrigez le primaire, afin que la passerelle reste opérationnelle tout du long.
3. Fermez chaque session ICA et PCoIP active après le correctif — le correctif seul ne suffit pas
C’est l’étape que les équipes sautent, et c’est celle qui décide si le correctif a réellement fermé la porte. Comme la faille divulgue des jetons de session actifs, tout jeton volé avant que vous ne corrigiez reste valide après la correction — le correctif arrête les nouvelles fuites mais n’invalide pas les jetons déjà exfiltrés. La consigne de Citrix est explicite : après la mise à niveau, exécutez kill icaconnection -all et kill pcoipConnection -all pour fermer toutes les sessions ICA et PCoIP actives, forçant chaque utilisateur à se réauthentifier. Traitez un appareil corrigé mais dont les sessions ne sont pas fermées comme toujours potentiellement compromis.
4. Recherchez l’empreinte post-exploitation, pas seulement la CVE
Le correctif supprime la vulnérabilité ; il ne supprime pas un attaquant qui l’a déjà utilisée. Examinez les journaux NetScaler à la recherche d’anomalies d’authentification — le même compte apparaissant depuis une IP d’entreprise normale et une adresse hébergée sur VPS, des sessions avec des IP sources incohérentes, ou des connexions en dehors des heures ouvrées. Sur le réseau interne, cherchez les signatures de la boîte à outils Anubis documentées par Arctic Wolf : processus cloudflared inattendus, agents RMM non autorisés (ScreenConnect, Zoho Assist, MeshAgent), artefacts Mimikatz, et outils de transfert en masse comme rclone ou s5cmd atteignant le stockage cloud. N’en trouver aucun est rassurant ; en présumer aucun sans chercher est ainsi que le temps de présence s’étire sur des mois.
5. Renouvelez les identifiants et secrets que la passerelle a pu exposer
S’il existe la moindre preuve — ou un doute raisonnable — qu’un appareil était accessible pendant la fenêtre d’exploitation, considérez les secrets associés comme compromis. Renouvelez les mots de passe des comptes de service, réinitialisez tout identifiant ayant transité par la passerelle, et réémettez les clés de signature de session le cas échéant. Pour les institutions régulées, documentez l’évaluation et le calendrier de remédiation ; un enregistrement propre et daté de « détecté, corrigé, sessions fermées, identifiants renouvelés » est exactement ce qu’un auditeur ou un régulateur demandera plus tard.
Où cela s’inscrit dans la posture de sécurité algérienne de 2026
Citrix Bleed 2 est un exemple net de la classe de risque qui définira la défense d’entreprise en 2026 : l’appareil exposé sur internet comme cible de plus haute valeur. Les concentrateurs VPN, les passerelles et les équipements de sécurité en périphérie sont attrayants précisément parce qu’ils sont de confiance, accessibles, et souvent sous-surveillés — les organisations corrigent les ordinateurs portables toutes les deux semaines mais laissent un NetScaler intact pendant un an parce que « ça marche tout seul ». La leçon n’est pas spécifique à Citrix. Chaque équipement en périphérie — de n’importe quel fournisseur — mérite la même discipline : un inventaire des versions connu, un délai de correctif rapide mesuré en jours pour les CVE exploitées, une hygiène de session après chaque mise à jour, et une surveillance des journaux qui saurait réellement détecter un rejeu de jeton.
Pour les banques, opérateurs télécoms et grandes entreprises algériennes qui construisent une maturité accrue de leurs services numériques, c’est une occasion d’intégrer dès maintenant la vélocité de correctif des équipements en périphérie dans les procédures opérationnelles standard, tant que l’exemple est frais. Un délai d’un jour de la CISA est le repère d’un régulateur étranger, pas un mandat local — mais c’est un étalon utile pour ce que « urgent » devrait signifier en interne. Les équipes capables d’inventorier, corriger, fermer les sessions et chercher en une semaine sont des équipes qui ont transformé une course effrénée en un guide reproductible. Cette capacité, plus que tout correctif isolé, est le gain durable.
Questions Fréquemment Posées
Le correctif seul nous protège-t-il de Citrix Bleed 2 ?
Non. Le correctif empêche l’appareil de divulguer de nouveaux jetons de session, mais tout jeton volé avant la correction reste valide. C’est pourquoi la consigne de Citrix exige de fermer toutes les sessions ICA et PCoIP actives (kill icaconnection -all et kill pcoipConnection -all) après la mise à niveau — cela force la réauthentification et invalide toute session qu’un attaquant a pu détourner. Corrigez sans fermer les sessions et vous laissez peut-être la porte ouverte.
Nous utilisons la MFA sur notre VPN — sommes-nous protégés ?
Pas à elle seule. CVE-2025-5777 est dangereuse précisément parce qu’elle défait la MFA : en volant un jeton de session actif dans la mémoire de l’appareil, un attaquant hérite d’une session ayant déjà franchi l’authentification, donc le défi MFA ne se redéclenche jamais. La MFA reste une défense en profondeur essentielle, mais contre cette faille spécifique, la protection est le correctif, la fermeture des sessions et la surveillance du rejeu de jetons — pas l’invite MFA.
Comment savoir si nous avons déjà été exploités avant le correctif ?
Cherchez l’empreinte post-exploitation plutôt que la CVE elle-même. Examinez les journaux d’authentification NetScaler à la recherche du même compte apparaissant à la fois depuis une IP normale et une adresse hébergée sur VPS, et de sessions avec des IP sources incohérentes. Sur les hôtes internes, traquez les tunnels cloudflared, les agents de gestion à distance non autorisés comme ScreenConnect ou MeshAgent, les artefacts Mimikatz, et les outils de transfert de données en masse comme rclone atteignant le stockage cloud — la boîte à outils qu’Arctic Wolf a documentée dans la campagne Anubis.
Sources et lectures complémentaires
- CISA Tags Citrix Bleed 2 as Exploited, Gives Agencies a Day to Patch — BleepingComputer
- CitrixBleed 2 to Cloudflared: The Tools and Techniques Behind Anubis Ransomware Attacks — Arctic Wolf
- Ransomware Groups Turn to Citrix Bleed 2 Flaw — The Hacker News
- NetScaler ADC and NetScaler Gateway Security Bulletin (CTX693420) — Citrix
- Known Exploited Vulnerabilities Catalog — CISA














