Trois zero-days Ivanti ont donné le root à un VPN entièrement à jour. L'outil d'intégrité du fournisseur ne le voit pas

Le mardi 13 octobre 2026, Volexity a publié son analyse d'une intrusion partie d'un boîtier VPN Ivanti Connect Secure. Un acteur qu'elle n'avait jamais observé, désormais suivi sous le nom UTA0576, a enchaîné trois vulnérabilités zero-day pour exécuter du code en root sans s'authentifier. Le boîtier était entièrement à jour à ce moment-là, en version 22.8R2.4, Build 19097. L'attaquant n'a déployé ni malware ni web shell.

Le même jour, Ivanti a publié des correctifs pour deux des trois failles, un contournement d'authentification et un bug d'exécution de code à distance, suivis ensemble sous l'identifiant CVE-2026-104935 et notés 8,6 sur l'échelle CVSS. La CISA a ajouté CVE-2026-104935 à son catalogue des vulnérabilités exploitées connues (KEV) le 13 octobre et a donné aux agences civiles fédérales jusqu'au 16 octobre. La troisième faille, une élévation de privilèges, n'avait pas de correctif : Volexity a écrit qu'Ivanti la corrigerait dans une prochaine version « dans les semaines à venir ». Le 15 octobre, elle a reçu son propre identifiant, CVE-2026-111357, noté 7,0, attribué par MITRE et non par Ivanti. Au 19 octobre, le flux d'avis de sécurité d'Ivanti n'indiquait aucun correctif pour elle, et le catalogue de la CISA ne la contenait pas.

Volexity a décrit une seule victime. Ivanti a dit avoir connaissance d'une exploitation « touchant un nombre limité de clients » au moment de la divulgation. Le 14 octobre, The Hacker News a rapporté que Previdian, qui exploite des capteurs honeypot, avait enregistré 105 tentatives d'exploitation depuis 50 adresses IP ; son PDG a dit que les charges utiles servaient surtout à tester l'exécution de code. BleepingComputer a rapporté que Shadowserver suit plus de 5 500 instances Connect Secure exposées en ligne, sans information sur le nombre de celles déjà corrigées.

Je n'administre pas de boîtier Connect Secure. J'ai lu le rapport en CTO qui vend des logiciels à des entreprises et en développeur indépendant qui publie ses propres apps, parce qu'il casse trois hypothèses sur lesquelles on s'appuie presque tous : à jour veut dire sûr, l'outil de vérification du fournisseur le verrait, et le correctif clôt l'incident.

La chaîne, en clair

Volexity a dû reconstituer l'attaque à partir d'images mémoire, d'images disque et de core dumps, parce que l'attaquant avait effacé des traces dans les journaux.

Première étape : welcome.cgi, la page de connexion publique, accepte des requêtes sans authentification. Le boîtier utilisait l'URL pour décider si une requête était autorisée, et un en-tête, X-DSCGI-PATH, pour décider où elle allait. Pointe l'en-tête vers un script protégé et la page de connexion t'y transmet.

Deuxième étape : wu.cgi, un gestionnaire d'envoi de fichiers, écrit le fichier envoyé sur le disque avant de vérifier que c'est un ZIP valide. L'attaquant a envoyé un script Perl avec l'extension .zip et a lancé des requêtes en parallèle pour l'exécuter dans la courte fenêtre avant que le gestionnaire ne le supprime.

Troisième étape : un service root nommé dsinvoked exécute des tâches de maintenance et lit dans un magasin de configuration partagé quel programme chaque tâche lance. L'attaquant a modifié une bibliothèque dans la mémoire de son propre processus, a pointé une tâche vers l'interpréteur Perl, a fait exécuter celui-ci en root par dsinvoked, puis a remis l'entrée et la bibliothèque en place.

Toute la chaîne était rejouée à chaque commande, et chaque résultat revenait dans la réponse HTTPS. Aucune porte dérobée n'attendait sur le boîtier. Volexity documente une exploitation dès le 3 octobre. Defused, une autre société de renseignement sur les menaces, a dit à Cybersecurity Dive avoir vu les premières activités le 1er octobre, sur ses honeypots et sur des instances de clients.

« À jour » dépendait de la branche

Le détail que je soulignerais figure dans l'avis d'Ivanti, tel que rapporté par The Register, Rapid7 et Dark Reading : Ivanti avait trouvé « une partie de cette vulnérabilité » grâce à son propre programme de sécurité et l'avait corrigée dans la 25.1.3.0, publiée en juillet. « Nous travaillions à rétroporter le correctif vers les autres versions prises en charge quand l'exploitation a eu lieu », a dit Ivanti, cité par Dark Reading.

Les versions touchées sont la 22.8R2.4 et antérieures, la 25.1.2.2 et antérieures, et la 25.1.1.1 et antérieures, chacune dans sa propre ligne de code ; l'enregistrement CVE d'Ivanti indique que la 22.7R2.14 et les antérieures ne sont pas touchées. Les versions corrigées sont la 22.8R2.5, la 25.1.1.2, la 25.1.3.0 et la 25.1.3.1. La victime était donc à jour sur sa branche, alors que l'enregistrement CVE d'Ivanti classe la 25.1.3.0, la version de juillet de la ligne la plus récente, comme non touchée par CVE-2026-104935 : environ trois mois d'avance que les branches plus anciennes n'ont pas eus. L'alerte de la CISA ajoute que la version 22.8 arrive en fin de vie le 31 janvier 2027.

C'est utile à savoir pour tout produit qui a plusieurs lignes prises en charge. Une ligne plus ancienne reçoit toujours les correctifs de sécurité, mais plus tard. La branche que tu fais tourner est une décision de sécurité, pas seulement de compatibilité.

L'outil que le fournisseur recommande est celui que cette attaque a battu

La mise à jour de sécurité d'octobre d'Ivanti demande aux clients de mettre à niveau et d'« exécuter régulièrement l'Integrity Checker Tool ». Le rapport de Volexity dit que cette chaîne ne laisse rien à trouver à cet outil : le patch de la bibliothèque n'a existé qu'en mémoire, l'entrée de configuration a été restaurée, et la bibliothèque sur le disque n'a jamais été modifiée. L'alerte de la CISA répète l'avertissement : l'outil « peut ne pas détecter de preuves d'exploitation » parce que les commandes s'exécutent en mémoire.

Le nettoyage est allé plus loin. La charge utile a supprimé des entrées récentes du journal de debug du boîtier et du journal d'audit Linux, effacé ses propres scripts et résultats temporaires, et lancé un tcpdump renommé, appelé dsstatmond, depuis un répertoire caché avec huit fichiers de capture tournants. Volexity dit ne pas avoir établi complètement jusqu'où chaque étape de nettoyage a réussi sur l'appareil de la victime. L'intention est claire de toute façon.

Un contrôle d'intégrité au vert est une affirmation sur des fichiers sur disque. Cette attaque a été conçue pour laisser ces fichiers intacts.

Corriger peut effacer les preuves

C'est ici que je ralentirais. Le guide de mise en œuvre de la CISA pour la Binding Operational Directive 26-04, daté du 10 juin, demande aux agences fédérales de collecter les preuves avant l'étape de correction, parce que « le patching peut compromettre la disponibilité des artefacts ». Son étape de preuves commence par « l'acquisition immédiate des données volatiles », ce qui inclut la mémoire. L'entrée KEV de CVE-2026-104935 porte la mention « Forensic triage required per BOD 26-04: Yes ». La directive ne contraint que les agences civiles fédérales. Le raisonnement vaut pour tout le monde.

Quand l'attaque vit en mémoire, l'ordre compte. Si la mise à niveau redémarre le boîtier avant que quelqu'un ait capturé sa mémoire, la meilleure preuve a disparu, et il reste des journaux que l'attaquant a retouchés. Corrige vite, oui. Mais s'il y a le moindre signe que le boîtier a servi, capture d'abord.

La vraie cible, c'était l'annuaire

Ce qu'UTA0576 a fait avec le root dit ce qu'un VPN vaut pour un attaquant. Il a extrait les identifiants de domaine stockés sur le boîtier. Il a utilisé le compte de service Active Directory du boîtier pour chercher des mots de passe administrateur local LAPS, des clés de récupération BitLocker et des attributs contenant des mots de passe. Il a déployé un outil Kerberos sur mesure, fait du password spraying, et tenté d'extraire des identifiants du trafic LDAP capturé. Volexity estime avec un haut niveau de confiance qu'il s'agissait d'une préparation au mouvement latéral, et avec un faible niveau de confiance que le mobile est criminel plutôt que de l'espionnage.

Le signe qui l'a trahi était banal. Sean Koessel, vice-président des services professionnels de Volexity, a dit à Cybersecurity Dive que l'équipe avait remarqué des « échecs d'authentification provenant de l'interface interne » du boîtier VPN. Un VPN n'a aucune raison de tester des mots de passe contre ton propre annuaire.

Volexity estime aussi, avec un niveau de confiance moyen, que l'acteur a utilisé des grands modèles de langage pour développer des exploits et pour la post-exploitation, citant des « scripts très spécifiques utilisant des identifiants codés en dur » plutôt que des outils génériques. J'orchestre mon propre travail avec Claude Code, donc ce point ne m'a pas surpris : un script écrit pour un seul réseau coûte désormais peu, et un script jetable ne correspond à aucune signature connue. Les défenseurs utilisent les mêmes outils. Dark Reading a rapporté qu'un porte-parole d'Ivanti a dit que la découverte de juillet venait du propre projet LLM d'Ivanti, qui utilise plusieurs modèles d'IA pour trouver et corriger des failles dans ses produits. Volexity a remercié le programme Trusted Access for Cyber d'OpenAI, en disant que ses modèles cyber réduisent drastiquement le temps d'analyse. Le fournisseur a trouvé une partie du bug en premier ; le correctif n'a quand même pas atteint toutes les branches à temps.

Ce que je vérifierais maintenant

Si tu fais tourner un boîtier Connect Secure, ou si tu en hérites via un client ou un prestataire IT :

1. Compare la version exacte à la liste des versions corrigées ci-dessus, et prévois de quitter la 22.8 avant le 31 janvier 2027.
2. Si tes journaux capturent les en-têtes de requête, cherche des rafales de requêtes vers /dana-na/auth/url_default/welcome.cgi portant un en-tête X-DSCGI-PATH, et tout décalage entre le chemin de l'URL et cet en-tête, comme le recommande Volexity. Elle s'attend à ce que les attaquants trouvent d'autres chemins.
3. Cherche des tentatives d'authentification venant de l'interface interne du boîtier, et des restes dans /tmp/.
4. Si quelque chose paraît anormal, capture la mémoire et le disque avant de mettre à niveau. Suis ensuite la liste de récupération de la CISA : sauvegarder la configuration, réinitialiser aux paramètres d'usine ou reconstruire sur la dernière version, restaurer la configuration, réinitialiser tous les mots de passe de domaine, d'administrateur et locaux, révoquer et réémettre les certificats stockés, et réinitialiser les clés d'API et les identifiants du serveur de licences stockés.
5. Demande ce que le compte de service d'annuaire du VPN peut lire. S'il peut lire des mots de passe LAPS ou des clés de récupération BitLocker, le VPN détient une clé de chaque machine que ces secrets protègent.
6. Surveille l'avis d'Ivanti pour le correctif de l'élévation de privilèges, la faille que MITRE suit maintenant sous CVE-2026-111357. Tant qu'il n'est pas publié, ce sont les points d'entrée corrigés qui se tiennent entre Internet et cette étape root.

Si tu achètes des logiciels ou des services IT, la question change aussi. Pas « êtes-vous à jour ? » mais « quelle branche, à quelle vitesse les rétroportages l'atteignent-ils, et comment sauriez-vous qu'un boîtier à jour avait déjà servi ? »

Le boîtier de cette histoire a fait ce que la checklist demandait. La checklist mesurait la mauvaise chose.

Sources

• Volexity, "A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days" (13 octobre 2026)
• Ivanti, "October 2026 Security Update" (13 octobre 2026)
• CISA, "CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure" (13 octobre 2026)
• CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog" (13 octobre 2026)
• CISA, "Known Exploited Vulnerabilities Catalog", entrée CVE-2026-104935 (consulté le 19 octobre 2026)
• CISA, "BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk" (10 juin 2026)
• Rapid7, "Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935)" (13 octobre 2026)
• The Register, "Ivanti patches Connect Secure zero-day after researchers confirm in-the-wild attacks" (14 octobre 2026)
• Cybersecurity Dive, "Hacker targets Ivanti Connect Secure in chained exploitation" (14 octobre 2026)
• BleepingComputer, "Ivanti warns of Connect Secure zero-day exploited in attacks" (13 octobre 2026)
• Dark Reading, "Ivanti ICS Zero-Day Attacks Highlight Vendor Patching Hurdles" (14 octobre 2026)
• The Hacker News, "CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts" (14 octobre 2026)
• Enregistrement CVE CVE-2026-104935 (attribué par Ivanti) (consulté le 19 octobre 2026)
• NVD, CVE-2026-111357 (publié le 15 octobre 2026)
• Ivanti, flux d'avis de sécurité (consulté le 19 octobre 2026)