# Ivanti Connect Secure : trois frontières franchies pour atteindre root

> Volexity a reconstruit la chaîne exploitée contre Ivanti Connect Secure : routage CGI, fichier temporaire exécutable, puis broker privilégié. Analyse et portée.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/ivanti-connect-secure-chaine-zero-day-2026/

**Intrusion observée dès le 3 octobre 2026 ; avis Ivanti du 13 octobre, complété le 29.** Une passerelle VPN n'est pas un serveur ordinaire : elle est exposée à Internet, termine l'authentification des utilisateurs et dispose souvent de secrets pour parler à l'annuaire interne. Dans le cas étudié par [Volexity](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), un attaquant a combiné un contournement d'authentification, une course sur un fichier temporaire et une élévation de privilèges pour exécuter des commandes comme `root` sur Ivanti Connect Secure. Le [CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-013/) confirme l'exploitation active de CVE-2026-104935 ainsi que des deux failles ajoutées ensuite, CVE-2026-111357 et CVE-2026-118527.

## Première frontière : le chemin vérifié n'est pas le chemin exécuté

La requête publique vers `welcome.cgi` devait servir la page de connexion. Le frontal décidait qu'elle était autorisée parce que cette URL était publique. Mais une valeur d'en-tête, `X-DSCGI-PATH`, pouvait désigner un autre script CGI, normalement protégé. Le contrôle de sécurité et le routeur interne ne portaient donc pas sur la même destination. Volexity décrit l'accès ainsi obtenu au gestionnaire `wu.cgi` ; l'attaquant n'avait pas besoin d'une session VPN valide pour atteindre le code interne.

L'invariant qui manque est simple : après réécriture et routage, le composant effectivement appelé doit rester celui auquel l'autorisation s'applique. Vérifier seulement l'URL visible puis accepter une destination issue d'un autre champ laisse deux interprétations d'une même requête. C'est une famille de bugs que l'on retrouve dans les proxies et les passerelles, même si les champs précis diffèrent.

## Deuxième frontière : écrire puis valider

Le gestionnaire `wu.cgi` recevait un fichier présenté comme une archive ZIP. D'après [l'analyse des traces et des dumps mémoire](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), il calculait un nom temporaire à partir du nom transmis, écrivait le contenu sur disque, puis vérifiait seulement ensuite si le fichier était un ZIP valide. Un contenu qui échouait à cette vérification était supprimé, mais il avait **existé entre l'écriture et la suppression**.

L'attaquant utilisait la même confusion de routage pour viser ce fichier temporaire pendant cette courte fenêtre. Des requêtes parallèles augmentaient les chances qu'une demande d'exécution arrive avant le nettoyage. Le résultat documenté est l'exécution d'un script Perl sous l'utilisateur `cgi-server`. La validation après écriture ne protégeait pas l'état intermédiaire ; elle ne faisait que réduire sa durée. La course appartient à CVE-2026-104935 avec le contournement d'authentification, selon la présentation d'Ivanti reprise par Volexity.

Les étapes précédentes donnent un point d'exécution moins privilégié, avant l'accès `root`. Les présenter directement comme un accès administrateur masquerait la troisième frontière.

## Troisième frontière : le broker root fait confiance à un état modifiable

Le service privilégié `dsinvoked` lance des tâches de maintenance en consultant leur définition dans `DSCache`. Volexity rapporte que l'attaquant a modifié **en mémoire** une bibliothèque du processus `cgi-server`, lui permettant de changer l'entrée `DSCache` d'une tâche existante. Il a remplacé temporairement le programme attendu par l'interpréteur Perl, puis demandé au broker d'exécuter la tâche avec un script choisi. Le broker, qui tournait comme `root`, a appliqué la configuration altérée.

La faiblesse est une rupture de provenance : un service `root` traite une valeur de configuration comme une instruction fiable alors qu'un processus moins privilégié a pu la modifier. Le test de l'attaquant, rapporté par Volexity, consistait à vérifier l'accès à `/etc/shadow`. L'équipe a ensuite observé le retour de la configuration et de la bibliothèque en mémoire vers leur état précédent. L'avis du 13 octobre indiquait encore que le correctif de l'élévation était en préparation ; [Volexity a ajouté le 29 octobre](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/) qu'Ivanti l'avait publié sous **CVE-2026-111357**. Le [CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-013/) recense également **CVE-2026-118527**, une autre faiblesse exploitée permettant à un attaquant authentifié de téléverser un fichier arbitraire ; il ne faut pas l'attribuer mécaniquement à chaque exécution observée dans la première enquête.

## Ce que l'attaquant a réellement fait après l'exploit

Volexity a documenté l'utilisation du compte de service LDAP de la passerelle pour interroger Active Directory, chercher des mots de passe LAPS et des clés de récupération BitLocker, tester des identifiants et inspecter le trafic LDAP. Les commandes et leurs résultats empruntaient les requêtes HTTPS de la chaîne d'exploitation. L'équipe n'a pas identifié de webshell permanente nécessaire à cette opération : l'attaquant réexécutait la chaîne pour chaque commande. Des journaux ont été filtrés et réécrits ; les modifications mémoire et les entrées `DSCache` ont été remises en place. Ces observations expliquent pourquoi un simple contrôle d'intégrité des fichiers sur disque ne suffit pas à écarter l'intrusion.

Les données recherchées ne prouvent pas que tous les secrets de toutes les installations ont été volés. Elles montrent le **type de conséquences** possible quand l'équipement de bordure possède déjà un lien de confiance avec l'annuaire. Le [CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-013/) dit avoir connaissance de mouvements latéraux utilisant de tels secrets et recommande de les traiter comme compromis lorsqu'une appliance l'est.

## Comment on aurait pu trouver et vérifier la chaîne

Un audit autorisé aurait comparé, pour chaque requête, l'URL soumise, le script réellement exécuté et la décision d'autorisation ; une divergence donne le premier signal. Le second test consiste à observer le cycle de vie d'un upload invalide : existe-t-il sur disque avant validation, est-il adressable, et pour combien de temps ? Le troisième suit les appels du processus non privilégié à `DSCache` et les ordres que `dsinvoked` exécute ensuite. L'instrumentation de la mémoire et des dumps est essentielle si les modifications ne persistent pas sur disque. Cette démarche est une reconstruction pédagogique ; Volexity a réellement utilisé mémoire, images disque et core dumps pour établir la chaîne de l'incident étudié.

Le correctif doit être accompagné d'une réponse à incident si l'équipement était exposé pendant la fenêtre d'attaque. Le [CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-013/) préconise d'isoler la machine, de conserver mémoire et journaux, de rechercher les indicateurs, puis de traiter les certificats, comptes de service et autres secrets ayant transité sur la passerelle. Une appliance mise à jour cesse d'être vulnérable à la chaîne corrigée ; elle ne redevient pas automatiquement digne de confiance si l'attaquant a déjà atteint son annuaire.

**Sources principales :** [enquête Volexity](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), [alerte CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-013/), [avis Ivanti](https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935?language=en_US).