Ivanti Connect Secure : corriger et rechercher une compromission

Une faille d’Ivanti Connect Secure permet à un attaquant distant d’exécuter des commandes sans authentification. Volexity documente son exploitation. Pour les administrateurs, la priorité est d’identifier les versions concernées, d’appliquer le correctif adapté et de rechercher une éventuelle intrusion : la mise à jour ne suffit pas à écarter une compromission antérieure.

Louis et son lapin dans une illustration sur : Ivanti Connect Secure : corriger et rechercher une compromission

Une faille d’Ivanti Connect Secure permet à un attaquant distant d’exécuter des commandes sans authentification. Volexity documente son exploitation. Pour les administrateurs, la priorité est d’identifier les versions concernées, d’appliquer le correctif adapté et de rechercher une éventuelle intrusion : la mise à jour ne suffit pas à écarter une compromission antérieure.

Sur une passerelle d’accès distant comme Connect Secure, la correction et l’examen d’une intrusion répondent à deux questions distinctes. La première porte sur la vulnérabilité du système ; le second cherche à établir ce qu’un attaquant a pu y faire avant l’installation du correctif. Rapid7 recommande donc de rechercher une compromission même après la mise à jour.

La fiche CVE publiée sous l’autorité d’attribution d’Ivanti décrit CVE-2026-104935 comme un contournement d’authentification par usurpation permettant l’exécution de commandes arbitraires. Elle indique une attaque réseau de faible complexité, sans privilège initial ni interaction de l’utilisateur, avec un score CVSS 3.1 de 8,6.

Identifier précisément les branches déployées

La première vérification consiste à relever le numéro complet de version de chaque appliance. Les seuils dépendent de la branche et de sa révision : un numéro abrégé ne permet pas de déterminer correctement l’exposition.

Rapid7 et le Center for Internet Security indiquent les seuils affectés et les versions corrigées suivants :

Branche Versions concernées Versions corrigées indiquées
25.1.1 25.1.1.1 et antérieures dans cette branche 25.1.1.2
25.1.2 25.1.2.2 et antérieures dans cette branche 25.1.3.0 ou 25.1.3.1
22.8R2 22.8R2.4 et antérieures dans cette branche 22.8R2.5

Les trois versions limites figurant dans ce tableau sont donc concernées selon ces sources. L’alerte du NHS England emploie une formulation « prior to » qui semble les exclure. Cette divergence justifie de confirmer la matrice de mise à niveau auprès d’Ivanti avant l’intervention, sans considérer ces versions limites comme épargnées.

La fiche CVE précise que 22.7R2.14 et les versions antérieures ne sont pas touchées par cette CVE particulière. Cette exclusion ne renseigne pas leur exposition à d’autres vulnérabilités et ne constitue pas une appréciation générale de leur sécurité.

Distinguer le correctif de la chaîne complète d’attaque

Le tableau permet d’identifier la mise à jour à examiner. La procédure applicable, les éventuelles mesures d’atténuation et les consignes de récupération restent à confirmer auprès d’Ivanti.

Il faut aussi distinguer CVE-2026-104935 de la chaîne complète décrite par Volexity. Dans son enquête, l’entreprise rapporte un routage abusif de requêtes vers un composant CGI protégé, suivi d’une exécution de code et d’une élévation de privilèges distincte. Cette dernière étape a permis d’exécuter des commandes avec les privilèges root sur une appliance 22.8R2.4 alors à jour. Ces privilèges correspondent au niveau de contrôle obtenu sur le système dans ce cas précis.

Dans leurs publications du 13 octobre 2026, Volexity et Rapid7 indiquaient que le correctif de cette élévation de privilèges distincte restait à venir. Les mises à jour visant CVE-2026-104935 ne doivent donc pas être présentées comme corrigeant toute la chaîne. La disponibilité ultérieure d’un correctif pour cette autre faille reste à vérifier auprès du fournisseur.

L’inscription au catalogue des vulnérabilités exploitées connues de CISA, le KEV, renforce la priorité donnée à cette alerte. Selon Rapid7 et la reprise des données du catalogue par CIRCL, CVE-2026-104935 y a été ajoutée le 13 octobre 2026, avec une échéance au 16 octobre pour les entités soumises aux exigences fédérales américaines applicables. Cette échéance n’est pas une date limite réglementaire universelle.

Rechercher les signes d’entrée et les actions qui ont suivi

Volexity situe au plus tard au 3 octobre 2026 le début de l’exploitation répétée reconstituée dans son enquête. Sur l’appliance étudiée, l’entreprise décrit notamment des recherches de secrets Active Directory, une exfiltration de données et une altération des journaux. Ces observations orientent l’examen d’un système suspect, sans établir que toutes les appliances vulnérables ont subi les mêmes actions.

Pour rechercher des traces, Volexity recommande notamment de surveiller les requêtes anormalement nombreuses vers la page de connexion concernée, les incohérences entre le chemin demandé et l’en-tête de routage, ainsi que l’activité après exploitation. L’entreprise prévient que d’autres chemins pourraient être employés : limiter l’examen au seul parcours observé risquerait de laisser de côté une autre forme d’exploitation.

L’examen doit ainsi porter sur les signes d’entrée comme sur les actions qui ont pu suivre. Lorsque l’exploitation est suspectée, Rapid7 renvoie aux procédures de récupération du fournisseur. Leurs étapes restent à obtenir auprès d’Ivanti ; le récit de l’attaque ne permet pas de les reconstituer.

Pourquoi le contrôle d’intégrité peut manquer une compromission

Selon Volexity, l’Integrity Checker Tool recherche des modifications de fichiers sur disque. Or la chaîne observée modifiait notamment du code en mémoire puis restaurait certaines données. Un contrôle centré sur l’état des fichiers peut ainsi manquer des traces de cette activité. Une absence d’alerte de l’outil ne suffit donc pas à écarter une compromission.

La capture publiée par Volexity provient de son enquête et de son outil commercial d’analyse mémoire Volcano. Elle montre des alertes dans le cas étudié, notamment liées à une activité de capture réseau. Elle illustre le type de traces que l’analyse mémoire peut apporter en complément de l’examen des fichiers, sans mesurer l’efficacité générale de cette détection ni représenter toutes les exploitations.

Dans le suivi de l’incident, il faut donc conserver séparément la version identifiée, la correction appliquée et le résultat de la recherche de compromission. Un résultat normal du contrôle d’intégrité ne doit pas clore à lui seul ce dernier volet. Si des indices subsistent, les consignes de récupération du fournisseur restent la référence à consulter.

Sources