Ivanti Connect Secure : le correctif d'octobre ne suffit plus

Le 21 octobre, nous vous alertions sur CVE-2026-104935, une faille exploitée sur les passerelles VPN Ivanti Connect Secure, et sur l'alerte du CERT-FR qui l'accompagnait. Beaucoup d'équipes ont appliqué le correctif publié mi-octobre et refermé le dossier.

Il faut le rouvrir. Selon la presse spécialisée, Ivanti a mis à jour son avis le 29 octobre : la faille d'octobre n'était que le premier maillon d'une chaîne de trois vulnérabilités, exploitée pour obtenir les droits root sur l'équipement. Les deux nouvelles failles ont été ajoutées le 30 octobre au catalogue KEV de la CISA, qui recense les vulnérabilités activement exploitées.

Ce que l'on sait

CVE-2026-104935 (CVSS 8,6) : le contournement d'authentification déjà connu, qui donne une exécution de commandes à distance sans compte.
CVE-2026-111357 (CVSS 8,8) : une fonction critique accessible sans authentification, qui permet une élévation de privilèges locale.
CVE-2026-118527 (CVSS 4,3) : des identifiants prévisibles, qui permettent de déposer des fichiers sur l'équipement.
Exploitation : selon les articles cités, Ivanti confirme une exploitation touchant « un nombre limité de clients ». La société Volexity, qui a analysé l'attaque avec l'éditeur, suit l'attaquant sous le nom UTA0576.
Zero-day : d'après Volexity, cité par GBHackers et CyberPress, l'activité remonte au 3 octobre, sur un équipement qui était alors entièrement à jour.

Prise isolément, la note de 4,3 de CVE-2026-118527 n'aurait alerté personne. Enchaînée aux deux autres, elle participe à une prise de contrôle totale. C'est une bonne raison de ne pas trier ses correctifs sur le seul score CVSS.

Pourquoi le correctif d'octobre ne suffit pas

Selon The Hacker News, les deux nouvelles failles touchent les versions 25.1.1.2 et antérieures et 22.8R2.5 et antérieures. Ce sont précisément les versions qui corrigeaient la faille d'octobre. Une passerelle mise à jour mi-octobre reste donc exposée aux deux autres maillons.

Les versions qui corrigent l'ensemble de la chaîne sont, selon la presse, 25.1.1.3 et 22.8R2.6. Pour une autre branche, reportez-vous à l'avis d'Ivanti, qui indique selon The Hacker News que sa dernière version corrige toutes les vulnérabilités enchaînées et exploitées.

Ce que l'attaquant a fait une fois entré

C'est la partie la plus instructive. Selon l'analyse de Volexity relayée par GBHackers et CyberPress, l'attaquant ne s'est pas contenté de l'équipement :

il a extrait les identifiants stockés sur la passerelle ;
avec le compte de service Active Directory relié à l'équipement, il a recherché les mots de passe administrateur gérés par LAPS, les clés de récupération BitLocker et les attributs contenant des mots de passe ;
il a mené des attaques par pulvérisation de mots de passe, testé des identifiants Kerberos et cartographié le DNS interne ;
il a analysé le trafic à la recherche d'identifiants LDAP, HTTP Basic et NTLM.

Il n'a déposé ni webshell ni porte dérobée persistante, et il a effacé une partie des journaux de débogage et d'audit. Volexity souligne qu'un résultat propre de l'outil de vérification d'intégrité d'Ivanti ne suffit pas à exclure une compromission : les captures mémoire et les images disque ont été déterminantes.

Autrement dit, une passerelle VPN compromise ne reste pas un problème de passerelle. Elle devient un point d'appui pour atteindre l'annuaire, les postes chiffrés et les comptes à privilèges.

Ce que nous recommandons

Inventorier toutes vos passerelles Ivanti Connect Secure, y compris celles de test ou de secours, et relever leur version exacte.
Mettre à jour vers 25.1.1.3 ou 22.8R2.6, ou vers la version indiquée par Ivanti pour votre branche. Une passerelle corrigée à la mi-octobre est à reprendre.
Chercher des traces, sans vous fier au seul outil d'intégrité. Les articles citent des pistes : un volume inhabituel de requêtes vers welcome.cgi, des incohérences entre le chemin demandé et l'en-tête X-DSCGI-PATH, des fichiers suspects dans /tmp, une activité inattendue de l'équipement vers le réseau interne.
Considérer les secrets comme exposés si l'équipement a pu être atteint : compte de service Active Directory relié, mots de passe LAPS, clés BitLocker, certificats et comptes locaux. Les recommandations du CERT-FR détaillées dans notre article du 21 octobre restent la bonne méthode.
Surveiller l'annuaire : requêtes du compte de service vers des attributs sensibles, tentatives d'authentification en rafale, nouveaux tickets Kerberos inhabituels.

Notre regard

Cette affaire illustre deux réflexes à adopter. D'abord, une faille exploitée sur un équipement de bordure doit être suivie dans la durée : l'avis initial n'est souvent que le début de l'histoire. Ensuite, la question « sommes-nous à jour ? » ne suffit pas. Il faut aussi se demander ce qu'un attaquant aurait pu atteindre depuis cet équipement, et s'assurer qu'il n'y est pas déjà.

Vous exploitez une passerelle Ivanti et vous souhaitez une recherche de compromission, ou vérifier ce qu'un attaquant pourrait atteindre depuis votre accès distant ? Contactez nos experts.