Trois zero-day en chaîne percent Ivanti Connect Secure jusqu’au root sans laisser de trace
Le 13 octobre 2026, Ivanti corrige CVE-2026-104935, un contournement d’authentification exploité en zero-day sur ses passerelles VPN Connect Secure, que Volexity relie à une chaîne de trois failles menant au root. La compromission ne laisse aucune trace détectable par l’outil d’intégrité du constructeur : il faut patcher en urgence et vérifier forensiquement chaque appliance.
13 octobre 2026. Ivanti publie un avis pour CVE-2026-104935, un contournement d’authentification de ses passerelles VPN Connect Secure, et CISA l’ajoute le jour même à son catalogue KEV. 5 octobre 2026. Volexity ouvre une enquête et découvre qu’un acteur inconnu, UTA0576, exploite une chaîne de trois zero-day sur une appliance pourtant « fully patched », en 22.8R2.4. 3 octobre 2026. La première exploitation est observée, deux jours avant le début de l’investigation. Pourquoi c’est important : la chaîne mène un attaquant non authentifié jusqu’au root sans déployer le moindre web shell, et les traces sont effacées si proprement que l’outil d’intégrité du constructeur n’y voit rien.
Une chaîne de trois maillons, de l’anonymat au root
Ce qui frappe dans le rapport de Volexity, c’est que l’attaque n’est pas une seule faille isolée, mais un enchaînement méthodique de trois vulnérabilités distinctes, chacune ouvrant l’accès à la suivante.
Premier maillon, le contournement d’authentification. La requête arrive sur /dana-na/auth/url_default/welcome.cgi, une page de connexion publique. L’attaquant y glisse un en-tête X-DSCGI-PATH pointant vers un script normalement protégé, wu.cgi. Le routage interne de Connect Secure décide de l’autorisation à partir de l’URL, mais de la destination à partir de l’en-tête : le contournement consiste à faire mentir le premier au profit du second.
Deuxième maillon, l’exécution de code à distance. wu.cgi calcule le hash MD5 du nom de fichier fourni, écrit le contenu téléversé dans /home/runtime/tmp/<MD5>, puis vérifie seulement après coup que c’est un ZIP valide. Un script Perl déguisé en .zip échoue à ce contrôle et est supprimé — mais il existe sur le disque pendant une courte fenêtre. UTA0576 exploite cette course en envoyant des requêtes parallèles qui exécutent le script avant sa suppression.
Troisième maillon, l’élévation de privilèges. Le code tourne d’abord dans le contexte de cgi-server. Pour passer root, l’attaquant patche en mémoire la bibliothèque /home/lib/libdsplibs.so, modifie le magasin de configuration DSCache pour qu’une tâche de maintenance du service privilégié dsinvoked lance l’interpréteur Perl au lieu de son script légitime, puis restaure l’état d’origine aussitôt l’exécution root obtenue. Ivanti suit les deux premiers maillons sous CVE-2026-104935 ; le troisième, l’élévation de privilèges, reste non corrigé à ce jour, avec un correctif annoncé « dans les prochaines semaines ».
Une anti-forensique qui rend l’outil d’intégrité aveugle
Le point qui doit alerter tout RSSI, c’est la propreté de la scène de crime. UTA0576 ne déploie ni backdoor ni web shell : pour chaque commande, il ré-exécute la chaîne complète et récupère le résultat directement dans la réponse HTTPS, sans canal C2 séparé.
La partie élévation de privilèges va plus loin. Après chaque exécution root, le script restaure l’entrée DSCache et la bibliothèque libdsplibs.so à leur état d’avant exploitation, puis supprime les entrées correspondantes de deux journaux ciblés : /home/runtime/dlogs/debuglog et /var/log/audit/audit.log. Le résultat est qu’Ivanti reconnaît lui-même que son Integrity Checker Tool — conçu pour repérer les modifications de fichiers inattendues — ne détecte rien, puisque tout se joue en mémoire et que l’état disque est restauré.
La conséquence pratique est brutale : patcher ne suffit pas à innocenter une appliance. Seule une analyse forensique, mémoire et disque, permet de confirmer qu’une passerelle n’a pas été compromise. Volexity a dû collecter des images mémoire, des images disque et des core dumps pour reconstruire la chaîne — c’est le niveau d’effort requis pour voir ce que l’outil du constructeur ne voit pas.
Ce que l’attaquant est venu chercher
L’objectif de UTA0576 n’était pas la passerelle elle-même, mais l’Active Directory qui se trouve derrière. Les actions post-exploitation documentées par Volexity dessinent un ciblage précis des secrets d’administration.
L’acteur a extrait les identifiants de domaine stockés sur l’appliance pour l’authentification LDAP, exfiltré des métadonnées Active Directory, puis déployé un outil Kerberos maison capable de lancer des attaques Kerberoast et de tester des mots de passe. Un outil Python LDAP sur mesure a ensuite cherché, via le compte de service AD compromis, les mots de passe LAPS des administrateurs locaux, les clés de récupération BitLocker et les attributs porteurs de secrets comme userPassword ou unixUserPassword.
S’ajoutent du password spraying, une capture de paquets du trafic LDAP, et une inspection des journaux d’authentification pour repérer les noms d’utilisateurs valides. Le tout visait un seul but : transformer une appliance VPN exposée en point de départ vers le contrôle du domaine. Les résultats, compressés en Base64, étaient exfiltrés par le canal d’exploitation lui-même.
Comment savoir si vous êtes touché
Ivanti indique qu’au moment de l’avis, aucun indicateur de compromission fiable n’était disponible de son côté — une conséquence directe de l’anti-forensique décrite plus haut. Volexity a en revanche publié un jeu d’indicateurs sur son dépôt threat-intel GitHub, daté du 13 octobre 2026.
La détection ne peut donc pas se contenter de chercher un fichier malveillant sur le disque : il n’y en a pas. Les signaux à surveiller sont comportementaux. Des tentatives de mouvement latéral initiées depuis l’appliance VPN vers l’Active Directory, des requêtes LDAP inhabituelles provenant du compte de service de l’appliance, une recherche d’attributs LAPS ou BitLocker dans l’annuaire, ou encore une activité Kerberoast — des demandes de tickets de service en masse — sont autant de symptômes d’une compromission de ce type.
Pour les équipes qui suspectent une intrusion, Ivanti renvoie vers ses procédures de remédiation : réinitialiser l’appliance aux paramètres d’usine et repartir d’une configuration saine, plutôt que de tenter de « nettoyer » une machine dont on ne peut pas prouver l’intégrité. C’est la conséquence logique d’une exploitation root sans trace : quand la confiance dans la machine est détruite, la seule remédiation sûre est la reconstruction.
Le correctif, et ce qu’il ne couvre pas
Ivanti liste des versions corrigées le 13 octobre 2026 : 25.1.1.1 et antérieures vers 25.1.1.2, 25.1.2.2 et antérieures vers 25.1.3.0 ou 25.1.3.1, et 22.8R2.4 et antérieures vers 22.8R2.5. Les versions 22.7.x et antérieures ne sont pas affectées. Rapid7 recommande une mise à jour « en urgence, hors du cycle de patching normal ».
Deux nuances rendent la situation plus inconfortable qu’un simple « patchez et passez à autre chose ». D’abord, le maillon d’élévation de privilèges n’est pas encore corrigé : même à jour, une appliance reste potentiellement exploitable si l’attaquant dispose d’une autre voie d’exécution de code. Ensuite, Ivanti indique qu’une partie de la vulnérabilité avait été découverte par son programme de sécurité produit et corrigée dans la version 25.1.3.0 de juillet 2026, mais que l’exploitation a eu lieu pendant le backport du correctif vers les branches encore supportées. C’est le scénario redouté du zero-day : la fenêtre entre la connaissance interne du bug et sa correction publique.
Cette campagne s’inscrit dans une série documentée. En janvier 2024, la paire CVE-2023-46805 (contournement d’authentification) et CVE-2024-21887 (injection de commande) frappait déjà Connect Secure, exploitée en chaîne par un acteur lié à la Chine. En janvier 2025, CVE-2025-0282, un débordement de tampon, était exploité en zero-day sur les mêmes appliances. Trois années consécutives, trois fois le même schéma : une appliance VPN exposée en bordure, transformée en porte d’entrée vers le domaine. Un VPN reste le point d’entrée préféré d’un attaquant, précisément parce qu’il est pensé comme une porte légitime.
Verdict
Si vous exploitez Ivanti Connect Secure, appliquez le correctif de CVE-2026-104935 dès ce soir, hors cycle, sur les branches 25.1.1.x, 25.1.2.x et 22.8R2.x concernées. Mais ne vous arrêtez pas là : aucune appliance ne doit être considérée comme saine sur la seule foi de l’Integrity Checker Tool. Faites auditer les passerelles exposées pour les indicateurs publiés par Volexity — tentatives de mouvement latéral depuis l’appliance, recherche de LAPS ou de BitLocker, requêtes LDAP anormales — et surveillez l’arrivée du correctif d’élévation de privilèges, car il manque encore une pièce au puzzle. Si vous n’êtes pas sûr d’avoir été visé, la règle est simple : en présence d’une exploitation root sans trace détectable, la prudence consiste à traiter chaque appliance de bordure comme potentiellement compromise jusqu’à preuve forensique du contraire.
Références
- Volexity — A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days, 13 octobre 2026
- Ivanti — Security Advisory CVE-2026-104935, 13 octobre 2026
- Rapid7 — Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935), 13 octobre 2026
- CISA — Known Exploited Vulnerabilities Catalog