Ivanti referme la chaîne de trois zero-day sur Connect Secure, mais l’outil d’intégrité ne détecte toujours rien
Le 29 octobre 2026, Ivanti ajoute CVE-2026-111357 et CVE-2026-118527 à son avis sur Connect Secure et publie les correctifs qui complètent la chaîne d’exploitation menant au root. Les correctifs du 13 octobre ne couvrent pas ces deux failles, et l’outil d’intégrité du constructeur ne voit pas la compromission : il faut patcher en 25.1.1.3 ou 22.8R2.6 et vérifier forensiquement chaque appliance.
29 octobre 2026. Ivanti ajoute deux vulnérabilités à son avis sur Connect Secure et publie les correctifs qui complètent la chaîne d’exploitation : CVE-2026-111357 et CVE-2026-118527. 30 octobre 2026. La CISA inscrit les deux failles à son catalogue KEV, preuve d’une exploitation active. 3 octobre 2026. Les premières compromissions observées par Volexity remontent à cette date, sur une appliance pourtant « fully patched ». Pourquoi c’est important : le correctif tant attendu est là, mais il ne couvre pas ce qu’on croyait déjà corrigé — et l’Integrity Checker Tool d’Ivanti ne détecte toujours pas la compromission.
Deux failles de plus, la chaîne se referme
L’histoire commence le 13 octobre, quand Ivanti corrige CVE-2026-104935, un contournement d’authentification de ses passerelles VPN Connect Secure. Nous la racontions alors : Volexity venait de documenter une chaîne de trois zero-day qui mène un attaquant non authentifié jusqu’au root, sans web shell ni canal C2 persistant. Mais un maillon manquait : l’élévation de privilèges restait non corrigée, avec un correctif annoncé « dans les prochaines semaines ».
Les semaines sont passées, et le tableau s’est complété — dans les deux sens.
CVE-2026-111357 est une absence d’authentification sur une fonction critique (CWE-306). Ivanti la note 8,8 en CVSSv3.1 : un attaquant local authentifié peut élever ses privilèges jusqu’au root. C’est précisément le troisième maillon que Volexity avait isolé en octobre, celui qui patche en mémoire la bibliothèque libdsplibs.so et fait exécuter un Perl par le service privilégié dsinvoked. Le registre CVE et Rapid7 la notent plus bas — 7,0 — parce qu’ils retiennent une complexité d’attaque élevée et un périmètre inchangé, là où Ivanti retient une complexité faible et un changement de périmètre. Peu importe l’écart : c’est la brique qui transforme une exécution de code en contrôle total de l’appliance.
CVE-2026-118527 est plus discrète, notée 4,3 : une génération de nombres ou d’identifiants prévisibles (CWE-340). Concrètement, elle permet à un attaquant authentifié de déposer un contenu qu’il contrôle à un emplacement connu du disque. Isolée, elle paraît bénigne. Chaînée aux deux autres, elle est le dernier verrou qui saute : d’après l’entrée KEV de la CISA, elle autorise un téléversement de fichier à un chemin prévisible — la primitive dont on a besoin pour poser un exécutable au bon endroit.
Un correctif en deux temps qui piège les équipes pressées
Le point qui va coûter cher, c’est la matrice des versions. Le correctif du 13 octobre couvrait CVE-2026-104935 : versions 25.1.1.2 et 22.8R2.5. Beaucoup d’équipes se sont arrêtées là, à juste titre — ces versions fermaient la faille annoncée.
Or Rapid7 est sans ambiguïté : les correctifs du 13 octobre ne remédient pas à CVE-2026-111357 ni à CVE-2026-118527. Il faut aller plus loin.
# Vérifier la version d'une appliance Ivanti Connect Secure
# Les versions corrigées pour la chaîne complète sont :
# 25.1.1.3 (branche 25.1) — ou 22.8R2.6 (branche 22.8)
# Toute version antérieure reste exposée aux deux nouvelles failles. La table des corrections se lit ainsi. Pour CVE-2026-111357 et CVE-2026-118527 : les branches 25.1.1.2 et antérieures passent en 25.1.1.3, et les branches 22.8R2.5 et antérieures passent en 22.8R2.6. Pour CVE-2026-104935, la branche 25.1.1.1 et antérieures passait déjà en 25.1.1.2, et 22.8R2.4 et antérieures en 22.8R2.5. Les appliances ISA4500, ISA6500 et ISA8500 sous 25.1.3.0 ou plus récent ne sont pas concernées.
Ivanti recommande de quitter la branche 22.8 pour 25.1.1.3 ou plus, ou d’appliquer 22.8R2.6 si la migration n’est pas immédiatement possible. Le piège est là : une équipe qui a appliqué 25.1.1.2 en croyant être à jour reste exposée aux deux failles supplémentaires, alors que la CISA a déjà acté l’exploitation active.
L’outil d’intégrité aveugle, et la leçon forensique
Le second enseignement tient en une phrase, et elle devrait faire réfléchir tout RSSI : Volexity rapporte que l’activité observée échappe à l’Integrity Checker Tool d’Ivanti.
L’ICT est conçu pour repérer les modifications de fichiers inattendues sur l’appliance. Le problème est structurel : UTA0576, l’acteur suivi par Volexity, opère en mémoire. Chaque commande passe par une ré-exécution de la chaîne complète, le résultat revient directement dans la réponse HTTPS, et l’état du disque est restauré après coup — entrée DSCache remise en place, journaux debuglog et audit.log nettoyés. Un outil qui compare des fichiers ne peut pas voir ce qui ne s’est jamais écrit sur le disque.
La conséquence pratique est brutale : un résultat ICT propre ne disculpe pas une appliance. Seule une analyse forensique, mémoire et disque, tranche. 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 exigé pour voir ce que l’outil du constructeur ne voit pas. Avant tout redémarrage ou réinitialisation, préservez la mémoire et les journaux.
# Chasse aux indicateurs documentés par Volexity (avant tout reboot) :
# 1. Requêtes vers /dana-na/auth/url_default/welcome.cgi avec un
# en-tête X-DSCGI-PATH, par exemple :
# X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi
# 2. Fichiers suspects dans /tmp/ (ml.py, rq5.py, mk.py, rr.py, pu.txt)
# et /data/.icscap/ (dsstatmond, cap*, h.py)
# 3. IP d'exploitation : 108.165.147.64 Ce que l’attaquant venait chercher
L’objectif final n’était pas la passerelle, mais l’Active Directory derrière elle. Volexity a observé le vol d’identifiants de domaine, des requêtes LDAP ciblant les mots de passe LAPS des administrateurs locaux et les clés de récupération BitLocker. Autrement dit : une fois le root obtenu sur la passerelle VPN, l’attaquant a pivoté vers les secrets qui ouvrent le reste du parc.
C’est ce qui justifie de traiter cet incident comme une compromission de l’annuaire, pas comme un simple correctif à appliquer. Les mots de passe LAPS, les clés BitLocker et les comptes de service AD exposés doivent être rotés après remédiation, même si l’ICT n’a rien signalé.
Verdict
Si vous exploitez Ivanti Connect Secure, patchez immédiatement en 25.1.1.3 ou 22.8R2.6 — pas en 25.1.1.2, qui ne couvre pas les deux nouvelles failles. La CISA a déjà tranché l’exploitation active ; l’échéance fédérale court. Si vous aviez déjà appliqué le correctif du 13 octobre, corrigez à nouveau : vous n’êtes pas protégé contre CVE-2026-111357 et CVE-2026-118527. Et dans tous les cas, ne vous contentez pas d’un scan ICT propre : préservez mémoire et journaux, cherchez les IOC de Volexity, et si un doute subsiste, suivez la procédure de reconstruction d’Ivanti puis rotez les secrets AD exposés. La chaîne est désormais corrigeable — mais la confiance dans l’état d’une appliance ne se restaure pas avec un simple redémarrage.
Références
- Rapid7 — Additional Ivanti Connect Secure zero-days exploited in the wild (CVE-2026-111357, CVE-2026-118527), 2 novembre 2026
- CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog, 30 octobre 2026
- Volexity — A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days, 13 octobre 2026
- Ivanti — Security Advisory CVE-2026-104935 (mise à jour)
- ETTAYEB — Trois zero-day en chaîne percent Ivanti Connect Secure jusqu’au root sans laisser de trace