Ivanti Connect Secure : chaîne zero-day exploitée, accès root (CVE-2026-104935)

En bref

• Une chaîne de trois failles donne à un attaquant non authentifié une exécution de commandes root sur les appliances VPN Ivanti Connect Secure. Volexity a documenté la chaîne et l'acteur qu'elle suit sous le nom UTA0576 le 13 octobre 2026.
• Les appliances Ivanti Connect Secure sur les versions affectées sont exposées dès qu'un attaquant peut atteindre l'interface web, car le point d'entrée ne demande ni identifiants ni interaction utilisateur.
• Exploitée dans la nature depuis octobre 2026. La CISA a inscrit les trois CVE de la chaîne au catalogue KEV le 2026-10-13, le 2026-10-30 et le 2026-10-30 ; les échéances fédérales sont le 2026-11-02 et le 2026-11-13 pour les deux dernières.
• Passez en 22.8R2.6 sur la ligne 22.8R2 ou en 25.1.1.3 sur la ligne 25.1.1, puis chassez toute compromission avec les contrôles de « Comment corriger ? » et « Comment vérifier si j'ai été compromis ? ».

Suis-je concerné ?

Toutes ces conditions doivent être réunies :

• Vous exploitez une appliance Ivanti Connect Secure, physique, virtuelle ou cloud, dont un attaquant peut atteindre l'interface web par le réseau.
• L'appliance tourne sur une version affectée : 22.8R2.5 et antérieures sur la ligne 22.8R2, ou 25.1.1.2 et antérieures sur la ligne 25.1.1, pour les correctifs du 29 octobre. Seule la CVE-2026-104935 touche aussi 25.1.1.1 et antérieures et 25.1.2.2 et antérieures.
• Aucun identifiant n'est nécessaire pour démarrer la chaîne, et aucun utilisateur de votre côté n'interagit avec quoi que ce soit. L'acteur observé par Volexity a exploité une appliance 22.8R2.4 totalement corrigée, alors la version la plus récente de cette ligne.

Les lignes de versions corrigées viennent de l'avis d'Ivanti cité par The Hacker News le 31 octobre 2026, et des enregistrements CVE. Dans les sources disponibles, la ligne 25.1.2 n'est affectée que par la CVE-2026-104935. Les lecteurs sur cette ligne et sur la branche 25.1.3 doivent suivre le guide de mise à jour et de migration d'Ivanti, que l'alerte de la CISA du 13 octobre référence. L'enregistrement de la CVE-2026-104935 précise aussi que 22.7R2.14 et antérieures ne sont pas concernées par cette faille.

Ivanti Connect Secure est une appliance VPN d’entreprise en bordure de réseau. Son exposition et les identifiants qu’elle conserve en font une cible de valeur.

Pour vérifier la version installée, lisez-la dans le tableau de bord de la console d'administration Connect Secure et comparez-la au tableau. Le tableau de bord indique la version de l'appliance à laquelle vous êtes connecté ; répétez l'opération par appliance ou par membre de cluster.

Comment corriger ?

1. Mettez à jour chaque appliance affectée vers 22.8R2.6 ou plus récent sur la ligne 22.8R2, ou 25.1.1.3 ou plus récent sur la ligne 25.1.1. Les correctifs du 13 octobre 2026 corrigeaient la CVE-2026-104935, et ceux du 29 octobre 2026 corrigent la CVE-2026-111357 et la CVE-2026-118527.
2. Les appliances de la ligne 22.8R2 atteignent leur fin de vie le 31 janvier 2027, selon l'alerte de la CISA du 13 octobre. Planifiez dès maintenant la migration vers une ligne maintenue plutôt que de re-patcher l'ancienne.
3. Traitez la mise à jour comme une réponse à compromission, pas seulement comme un correctif. L'alerte de la CISA du 13 octobre détaille les étapes pour les organisations qui découvrent une compromission. En cas de suspicion, préservez les preuves en mémoire, sur disque et sur le réseau avec votre équipe de réponse avant toute réinitialisation ou mise à jour. Sauvegardez la configuration, réinitialisez ou reconstruisez l'appliance, mettez-la à jour, puis restaurez la configuration. Réinitialisez ensuite chaque mot de passe, certificat stocké, clé d'API et identifiant de licence.

L'avis d'Ivanti ne liste aucun contournement, car le point d'entrée est la page de connexion publique qu'un VPN doit exposer. Volexity recommande un contrôle temporaire de détection : surveiller les forts volumes de requêtes vers /dana-na/auth/url_default/welcome.cgi portant un en-tête X-DSCGI-PATH. Alertez aussi sur les écarts entre le chemin d'URL et cet en-tête. Ce contrôle ne couvre que les chemins d'entrée connus ; il ne remplace pas la mise à jour.

Quelle est la cause racine ?

La chaîne fonctionne parce que trois décisions de confiance indépendantes s'alignent. L'appliance route une requête selon un en-tête contrôlé par le client. Un gestionnaire d'upload écrit un fichier avant de le valider. Un service root fait confiance à un magasin de configuration qu'un processus compromis peut modifier. Volexity a reconstruit les trois à partir de la mémoire et d'images de core dumps, car UTA0576 supprimait les journaux de l'appliance.

1. Contournement de l'authentification. Une requête vers /dana-na/auth/url_default/welcome.cgi, la page de connexion publique, est acceptée sans authentification. La requête porte un en-tête X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi, qui désigne un script CGI interne exécuté dans un contexte de confiance. L'appliance utilise l'URL pour décider si la requête est permise, mais l'en-tête pour décider où elle va.

2. Exécution de code à distance. Le gestionnaire d'upload de wu.cgi accepte un script Perl nommé avec une extension .zip. Il calcule le hachage MD5 du nom de fichier fourni par le client et écrit le contenu téléversé dans /home/runtime/tmp/<MD5(filename)>. C'est seulement après l'écriture que le gestionnaire vérifie que le fichier est un ZIP valide et le supprime. Dans la courte fenêtre avant suppression, l'attaquant envoie des requêtes parallèles dont l'en-tête X-DSCGI-PATH pointe vers le chemin du fichier téléversé, et le script s'exécute comme l'utilisateur cgi-server.

3. Élévation de privilèges vers root. L'appliance exécute dsinvoked, un service d'arrière-plan privilégié qui lance des tâches de maintenance en root. Il cherche le programme de chaque tâche dans DSCache, un magasin de configuration partagé. Le code de l'attaquant patche sa propre copie en mémoire de la bibliothèque Ivanti /home/lib/libdsplibs.so pour pouvoir modifier DSCache. Il reconfigure ensuite une tâche de maintenance existante pour lancer l'interpréteur Perl au lieu de /home/bin/updateOpswatSDK.pl. Quand dsinvoked exécute la tâche, le script de l'attaquant s'exécute en root, et l'exploit le confirme en lisant /etc/shadow.

Après chaque commande, la charge restaure l'entrée DSCache et annule le patch de la bibliothèque via /proc/self/mem. Elle supprime aussi les entrées correspondantes de /home/runtime/dlogs/debuglog et /var/log/audit/audit.log. Ivanti suit les deux premières failles sous la CVE-2026-104935, et l'élévation de privilèges est la CVE-2026-111357. La CVE-2026-118527 couvre l'emplacement de fichier prévisible qui indique à l'attaquant où atterrit le téléversement.

Comment est-ce exploité ?

1. L'attaquant, sans identifiants, envoie une requête au script de connexion publique /dana-na/auth/url_default/welcome.cgi avec X-DSCGI-PATH pointant vers wu.cgi.
2. Par cette route de confiance, il téléverse un script Perl dont le nom finit en .zip, de sorte que le gestionnaire l'écrit dans le chemin prévisible /home/runtime/tmp/<MD5(filename)>.
3. Avant que la validation ZIP ne supprime le fichier, des requêtes parallèles atteignent le chemin téléversé via la même astuce d'en-tête et l'exécutent comme cgi-server.
4. L'étape Perl lance un script Bash, qui décode et exécute en mémoire un script Python compressé en zlib et encodé en Base64 ; le script brut n'est jamais écrit sur le disque.
5. L'étape Python patche la bibliothèque en mémoire, redirige la tâche de maintenance dans DSCache et demande à dsinvoked de l'exécuter, ce qui a lieu en root.
6. Chaque commande de l'attaquant réexécute toute la chaîne, et son résultat revient dans la réponse HTTP ; Volexity n’a identifié aucun web shell persistant ni porte dérobée dans cet incident.

Volexity a observé UTA0576 exploiter cette chaîne à partir du 3 octobre 2026. Les étapes ci-dessus proviennent de son analyse des charges récupérées ; aucun web shell persistant ni porte dérobée n’a été identifié dans cette investigation.

Comment se déroule l'attaque ?

Une requête non authentifiée qui abuse de la confiance accordée à la page de connexion atteint un gestionnaire d'upload interne, gagne une course contre la suppression, puis s'élève via un service root jusqu'au contrôle total de l'appliance.

Que peut faire un attaquant ?

La chaîne produit une exécution de commandes root non authentifiée sur l'appliance, avec un impact complet en confidentialité, intégrité et disponibilité. L'enregistrement CVE d'Ivanti évalue la CVE-2026-104935 à CVSS v3.1 8,6, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. L'élévation de privilèges seule vaut CVSS v3.1 7,0, CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H selon son enregistrement, car isolée elle exige déjà un point d'appui sur l'appliance.

Avec root, UTA0576 a fait ce qui suit, documenté par Volexity :

• Extraire les identifiants stockés sur l'appliance, dont les identifiants de domaine utilisés pour LDAP.
• Dumper et exfiltrer des métadonnées Active Directory limitées, et interroger l'annuaire via le compte de service de l'appliance.
• Déployer un outil Kerberos sur mesure avec capacité Kerberoast, et un outil LDAP en Python cherchant les mots de passe d'administrateur local LAPS, les clés de récupération BitLocker et les attributs porteurs de mots de passe.
• Mener du password spraying, analyser les journaux d'authentification locaux pour des noms valides, et capturer le trafic LDAP de l'appliance pour récolter identifiants en clair et empreintes NTLM.
• Exfiltrer la configuration de l'appliance, y compris ses méthodes d'authentification, et mener une reconnaissance DNS et locale.

Les conditions sont étroites et favorables à l'attaquant : la seule condition préalable est l'accessibilité réseau de l'interface web. Volexity évalue avec une confiance moyenne qu'UTA0576 a utilisé de grands modèles de langage pour aider à construire la chaîne, et avec une confiance faible que ses motivations sont criminelles plutôt qu'espionnes. L'opération observée par Volexity a été interrompue, donc son objectif final reste inconnu.

Pourquoi le correctif fonctionne-t-il ?

Le correctif du 13 octobre 2026 ferme le point d'entrée. Après lui, la faille de routage qui laissait une URL publique atteindre des scripts CGI internes via l'en-tête X-DSCGI-PATH ne fonctionne plus, donc les étapes de téléversement et d'exécution ne peuvent pas démarrer. Les modifications de code d'Ivanti ne sont pas publiques : cela ne se vérifie pas contre un diff. Le correctif du 29 octobre 2026 corrige la CVE-2026-111357, fermant la route d'un processus compromis vers root via DSCache. Il corrige aussi la CVE-2026-118527, l'emplacement de téléversement prévisible.

Ivanti a déclaré avoir découvert une partie de la faille en interne et l'avoir corrigée dans la version 25.1.3.0 de juillet 2026, et être en train de rétroporter le correctif quand l'exploitation a eu lieu. L'entreprise a expliqué avoir livré d'abord le correctif de la CVE-2026-104935 car cette faille était le chemin d'exploitation principal. L'élévation de privilèges est donc restée non corrigée sur la ligne 22.8R2 pendant les 16 jours entre le 13 et le 29 octobre 2026. Les appliances corrigées le 13 octobre étaient protégées contre le point d'entrée distant, mais tout autre point d'appui d'exécution de code pouvait encore s'élever en root pendant cette fenêtre.

Comment vérifier si j'ai été compromis ?

Commencez par la télémétrie HTTP qui conserve les en-têtes, par exemple les captures réseau ou les journaux de proxy existants. Les journaux d’accès de l’appliance peuvent ne pas enregistrer X-DSCGI-PATH : leur export ne garantit pas la détection. Ces exemples s’appliquent à des journaux texte non compressés contenant les en-têtes et s’inspirent des recommandations de Volexity :

grep -ai "X-DSCGI-PATH" *.log* | grep -a "welcome.cgi"

grep -a "X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi" *.log*
grep -a "X-DSCGI-PATH: /home/runtime/tmp/" *.log*

Une correspondance signale une requête suspecte, sans prouver que le routage ou l’exécution a réussi. Recoupez-la avec d’autres preuves. Des requêtes répétées vers /dana-na/auth/url_default/welcome.cgi depuis une même source sont un autre indice.

Cherchez ensuite les artefacts post-exploitation récupérés par Volexity, sur chaque appliance :

ls -la /tmp/        # ml.py, rq5.py, mk.py, rr.py, sp_run.py, sp_out.txt, spray_hits.json
ls -la /data/.icscap/   # h.py, dsstatmond, cap0–cap7

L'hôte d'opération de l'acteur observé par Volexity était 108.165.147[.]64. Les honeypots de Previdian ont enregistré 105 tentatives depuis 50 adresses au 14 octobre 2026, dont 216.73.160[.]59, 216.73.160[.]61, 216.73.160[.]210 et 45.8.19[.]111.

Deux limites comptent ici. La charge supprime ses propres entrées des journaux de debug et d'audit de l'appliance ; des journaux propres ne prouvent pas l'absence de compromission. L’Integrity Checker Tool d’Ivanti ne peut pas exclure cette exploitation : le patch de bibliothèque est en mémoire et la modification DSCache est annulée. Les charges temporaires et outils post-exploitation peuvent néanmoins laisser des traces sur disque. Volexity et la CISA indiquent toutes deux que confirmer une compromission exige de la forensique réseau et mémoire. Les étapes complètes de réponse de la CISA sont dans « Comment corriger ? ».

Chronologie

• 2026-10-01 : Defused Cyber enregistre des tentatives d'exploitation avant divulgation contre ses leurres, qu'il attribue à la CVE-2026-104935.
• 2026-10-03 : UTA0576 commence à exploiter la chaîne de façon répétée contre l'appliance d'un client de Volexity, en version 22.8R2.4 build 19097, la plus récente alors.
• 2026-10-05 : Volexity ouvre l'investigation qui reconstruira la chaîne depuis la mémoire et les core dumps.
• 2026-10-13 : Ivanti publie les correctifs de la CVE-2026-104935, Volexity publie l'analyse de la chaîne, et la CISA inscrit la faille au KEV avec échéance au 2026-10-16.
• 2026-10-14 : Previdian rapporte 105 tentatives d'exploitation depuis 50 adresses IP contre ses capteurs honeypot.
• 2026-10-15 : L'enregistrement CVE de la CVE-2026-111357 est publié par MITRE, indiquant la faille exploitée dans la nature.
• 2026-10-29 : Ivanti publie les correctifs de la CVE-2026-111357 et de la CVE-2026-118527 en 22.8R2.6 et 25.1.1.3.
• 2026-10-30 : La CISA inscrit les deux CVE de la chaîne au KEV, avec échéances fédérales au 2026-11-02 et au 2026-11-13.

FAQ

Une appliance uniquement interne a-t-elle besoin du correctif ?

Oui, dès qu'un attaquant réseau peut atteindre son interface web, y compris via un réseau de bastion ou une exposition mal configurée. La première requête de la chaîne vise la page de connexion publique : elle ne demande ni compte VPN ni accès préalable. Si l'interface est réellement inatteignable, le risque se réduit aux initiés et aux attaquants en pivot, et la mise à jour reste la solution.

J'ai corrigé la CVE-2026-104935 le 13 octobre. Suis-je tranquille ?

Seulement si vous avez depuis atteint 22.8R2.6 ou 25.1.1.3. Le correctif du 13 octobre fermait le point d'entrée distant, mais l'élévation de privilèges est restée non corrigée jusqu'au 29 octobre. Vérifiez la version, terminez la mise à jour, et rappelez-vous que tout autre point d'appui d'exécution de code sur l'appliance pouvait s'élever pendant cette fenêtre.

L'Integrity Checker Tool peut-il confirmer que l'appliance est saine ?

Non. L'exploit patche le code de la bibliothèque en mémoire seulement et restaure le magasin de configuration, donc un contrôle d’intégrité sans alerte n’exclut pas une compromission. Volexity précise qu'une investigation forensique de la mémoire, du disque et du réseau est nécessaire, et qu'UTA0576 supprimait ses entrées des journaux, aussi bien du journal de debug Ivanti que du journal d'audit Linux.

Pourquoi vois-je un autre score pour la CVE-2026-111357 ?

L'enregistrement CVE publié par MITRE, mis à jour le 31 octobre 2026, l'évalue à CVSS v3.1 7,0 avec le vecteur ci-dessus. Certaines couvertures du 31 octobre indiquent 8,8 pour la même faille. L'article suit l'enregistrement CVE comme source primaire ; c'est aussi lui qui alimente les données d'enrichissement de la CISA. Ce score ne compte qu'isolément, car le point d'entrée de la chaîne ne demande aucun identifiant.

Était-ce un rançongiciel ou de l'espionnage ?

Aucun des deux n'est confirmé. Volexity évalue avec une confiance faible qu'UTA0576 est motivé par le crime, et les actions observées préparaient un mouvement latéral : vol d'identifiants, reconnaissance Active Directory et password spraying. L'opération observée par Volexity a été interrompue avant son objectif final, qui reste inconnu.

Quel est le lien entre les trois CVE ?

La CVE-2026-104935 couvre ensemble le contournement d'authentification et la course d'exécution de code. La CVE-2026-111357 couvre l'élévation vers root, et la CVE-2026-118527 l'emplacement de fichier prévisible qui fait atterrir le téléversement à un chemin connu. Les entrées KEV de la CISA pour les deux dernières précisent que chacune se chaîne avec les deux autres. L'enregistrement CVE de la CVE-2026-118527 n'était pas encore publié au 31 octobre 2026.

Quelle est l'ampleur de l'exploitation ?

Aucun nombre de victimes n'est publié. Defused Cyber a enregistré des tentatives dès le 1er octobre, et Previdian en comptait 105 contre ses capteurs au 14 octobre. Le cabinet watchTowr a déclaré à The Hacker News que cette faille rejoint 14 autres entrées Ivanti et Pulse Connect Secure au catalogue KEV. Les tentatives sont confirmées ; le nombre de compromissions réussies ne l'est pas.

Repérez les appliances VPN exposées de votre parc avec Ostorlab

Une appliance joignable depuis Internet est la seule condition préalable dont cette chaîne a besoin. La découverte de surface d'attaque d'Ostorlab inventorie les hôtes exposés de votre organisation. Elle vous dit quelles appliances Ivanti Connect Secure existent et où vérifier les versions en premier.

Références

• Volexity, A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days : https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/ (vérifié le 31 octobre 2026)
• Indicateurs de menace Volexity pour la campagne UTA0576 : https://github.com/volexity/threat-intel/tree/main/2026/2026-10-13%20Ivanti (vérifié le 31 octobre 2026)
• Avis de sécurité Ivanti, CVE-2026-104935 : https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935 (vérifié le 31 octobre 2026)
• Enregistrement CVE-2026-104935 : https://www.cve.org/CVERecord?id=CVE-2026-104935 (vérifié le 31 octobre 2026)
• Enregistrement CVE-2026-111357 : https://www.cve.org/CVERecord?id=CVE-2026-111357 (vérifié le 31 octobre 2026)
• Alerte CISA, CISA Adds Two Known Exploited Vulnerabilities to Catalog, 30 octobre 2026 : https://www.cisa.gov/news-events/alerts/2026/10/30/cisa-adds-two-known-exploited-vulnerabilities-catalog (vérifié le 31 octobre 2026)
• Flux JSON du catalogue KEV de la CISA : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 31 octobre 2026)
• The Hacker News, Attackers Chain Three Ivanti Connect Secure Flaws to Gain Unauthenticated Root Access, 31 octobre 2026 : https://thehackernews.com/2026/10/attackers-chain-three-ivanti-connect.html (vérifié le 31 octobre 2026)
• The Hacker News, CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts, 14 octobre 2026 : https://thehackernews.com/2026/10/cisa-urges-immediate-ivanti-connect.html (vérifié le 31 octobre 2026)
• Alerte CISA, CISA Urges Patching of Newly Exploited Ivanti Connect Secure Vulnerability, 13 octobre 2026 : https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure (liée depuis The Hacker News, vérifié le 31 octobre 2026)