Une vulnérabilité d’Ivanti Connect Secure déclenche une alerte de la CISA, mais appliquer un correctif ne suffit pas
Ivanti fait face à une réponse d’urgence après que des attaquants ont exploité une vulnérabilité d’Ivanti Connect Secure contre des appliances entièrement corrigées avant sa divulgation le 13 octobre. La CISA a ajouté CVE-2026-104935 à son catalogue Known Exploited Vulnerabilities le même jour. La faille permet à un attaquant distant de contourner l’authentification et d’exécuter des commandes arbitraires sans interaction de l’utilisateur.
La consigne immédiate est simple : installer la version corrigée d’Ivanti. Le problème plus difficile consiste à déterminer si les attaquants ont déjà pénétré les systèmes, dérobé des identifiants et supprimé les preuves les plus visibles. Les enquêteurs ont constaté que l’opérateur observé exploitait à répétition les appliances plutôt que d’installer une porte dérobée conventionnelle.
Ce comportement remet en cause la réponse classique consistant à corriger puis analyser. Un correctif ferme le vecteur d’entrée divulgué, mais il ne révoque pas les secrets volés et ne prouve pas que l’appliance était auparavant saine. Pour les passerelles VPN exposées, la remédiation exige désormais à la fois une maintenance logicielle et une enquête sur incident.
La CISA fait de la vulnérabilité d’Ivanti Connect Secure une urgence
L’alerte de la CISA fait passer CVE-2026-104935 d’une faiblesse logicielle théorique à une priorité confirmée de réponse aux incidents.
L’alerte fédérale de l’agence, publiée le 13 octobre, indique que des acteurs malveillants exploitent cette vulnérabilité pour dérober des identifiants et exfiltrer des données. La CISA a également inscrit la faille dans son catalogue Known Exploited Vulnerabilities, généralement appelé KEV.
Une inscription au KEV a davantage de poids opérationnel qu’un avis de vulnérabilité ordinaire. Elle signifie que la CISA dispose d’éléments montrant que des attaquants utilisent la faille hors laboratoire. Les agences civiles fédérales doivent remédier aux entrées KEV conformément à des exigences fédérales contraignantes.
Les produits concernés occupent une position particulièrement sensible dans les réseaux d’entreprise. Ivanti Connect Secure est une passerelle d’accès distant qui relie les utilisateurs aux applications internes et aux ressources cloud. Elle doit accepter le trafic Internet tout en maintenant des connexions de confiance avec les systèmes d’identité internes.
Cette position rend un contournement réussi de l’authentification particulièrement lourd de conséquences. L’attaquant ne part pas d’un poste de travail ordinaire d’employé. Il part d’un appareil conçu pour servir d’intermédiaire entre Internet et les services protégés.
CVE-2026-104935 obtient un score CVSS de 8,6. Elle est classée comme un contournement d’authentification par usurpation, ce qui signifie que l’appliance fait indûment confiance à des informations utilisées pour acheminer une requête. Son exploitation exige peu de complexité, aucun compte existant et aucune interaction de la victime.
Ivanti indique que les versions concernées sont :
Version 25.1.1.1 et les versions antérieures de cette branche de code
Version 25.1.2.2 et les versions antérieures de cette branche de code
Version 22.8R2.4 et les versions antérieures de cette branche de code
Les versions corrigées disponibles comprennent 25.1.1.2, 25.1.3.0, 25.1.3.1 et 22.8R2.5. Les administrateurs doivent faire correspondre la mise à jour à la branche déployée et confirmer les recommandations actuelles dans l’avis de sécurité.
Ivanti indique que les versions 22.7.x et antérieures ne sont pas affectées par cette vulnérabilité spécifique. Cette affirmation ne doit pas être interprétée comme une garantie générale de support ou de sécurité pour les logiciels plus anciens. Les organisations doivent examiner séparément l’état du cycle de vie et les autres vulnérabilités affectant leur version installée.
L’entreprise a déclaré avoir connaissance d’une exploitation limitée lors de la divulgation de la faille. « Limitée » décrit les cas connus d’Ivanti, et non le nombre total d’appliances compromises. Les opérateurs sophistiqués minimisent souvent les traces, tandis que de nombreuses organisations ne disposent pas d’une télémétrie complète provenant de leurs appliances réseau.
L’exposition sur Internet renforce l’urgence. Shadowserver suivait plus de 5 500 instances apparentes de Connect Secure en ligne après la divulgation. Ce nombre peut inclure des pots de miel, des observations dupliquées et des systèmes ayant déjà reçu une mise à jour.
Ce décompte illustre néanmoins la surface d’attaque accessible. Une fois les détails techniques diffusés, les attaquants peuvent rechercher des passerelles vulnérables bien plus rapidement que nombre d’entreprises ne peuvent planifier leur maintenance. Une appliance exposée est donc menacée à la fois par l’opérateur initial et par de futurs imitateurs.
C’est pourquoi la CISA a employé le mot « immédiatement ». Les cycles mensuels ordinaires de correctifs supposent que les défenseurs disposent du temps nécessaire pour tester, planifier et déployer une mise à jour. L’exploitation confirmée d’un zero-day fait disparaître cette hypothèse.
Toutefois, la mise à jour n’est que la première décision. La campagne observée a commencé avant la divulgation publique et visait une appliance exécutant la dernière version disponible. Chaque organisation concernée doit donc se demander quand l’exposition a commencé, et pas seulement à quel moment son correctif a été installé.
Les attaquants ont obtenu les privilèges root sans se connecter
L’exploit a fonctionné parce que trois faiblesses formaient une chaîne, transformant une requête publique de connexion en exécution de commandes avec les privilèges root.
Volexity a découvert cette activité au cours d’une enquête commencée le 5 octobre. Ses chercheurs ont remonté les comportements suspects jusqu’à une appliance Ivanti Connect Secure exécutant la version 22.8R2.4, Build 19097. Cette version était entièrement corrigée à ce moment-là.
L’entreprise a identifié une exploitation remontant au 3 octobre. Un autre fournisseur de renseignement sur les menaces aurait observé des signes associés dès le 1er octobre. La divulgation publique et les correctifs sont arrivés le 13 octobre, laissant une période significative d’exposition inconnue.
Volexity suit l’opérateur non identifié sous le nom UTA0576. Cette étiquette désigne un groupe d’activité, et non une organisation ou un commanditaire gouvernemental confirmé. L’entreprise a estimé, avec un faible niveau de confiance, que l’opération observée était motivée par des activités criminelles plutôt que par l’espionnage.
La première étape a abusé du routage des requêtes autour de welcome.cgi, un composant public servant la page de connexion de l’appliance. Les attaquants ont fourni un autre chemin dans l’en-tête X-DSCGI-PATH. L’appliance vérifiait l’autorisation de l’URL publique, mais utilisait l’en-tête pour sélectionner la destination.
Cette incohérence a dirigé une requête non authentifiée vers wu.cgi, un gestionnaire de téléversement protégé. Le résultat était un contournement de l’authentification. Un composant censé se trouver derrière les contrôles de connexion est devenu accessible via une requête publique.
La deuxième étape exploitait une brève condition de concurrence dans la gestion des fichiers. Une condition de concurrence survient lorsque la sécurité dépend de l’ordre d’achèvement de deux opérations. Ici, le gestionnaire de téléversement écrivait un fichier fourni avant de vérifier s’il s’agissait d’une archive ZIP valide.
L’attaquant a téléversé un script Perl avec une extension .zip. Le gestionnaire a finalement rejeté et supprimé le fichier invalide. Toutefois, le fichier a brièvement existé sur le disque avant sa suppression.
UTA0576 a envoyé des requêtes parallèles visant à exécuter le fichier temporaire pendant cette fenêtre. La répétition de ces requêtes augmentait la probabilité que l’une d’elles arrive avant le nettoyage. Un bon synchronisme produisait une exécution de code sous le compte restreint cgi-server.
Ivanti a regroupé les étapes de contournement de l’authentification et d’exécution de code à distance sous CVE-2026-104935. Ses versions du 13 octobre corrigent ces parties de la chaîne. La troisième étape, qui élevait les privilèges jusqu’à root, est traitée séparément.
Pour l’élévation de privilèges, l’opérateur a manipulé la manière dont un service d’arrière-plan privilégié faisait confiance aux données de configuration. L’exploit a modifié une bibliothèque Ivanti dans la mémoire du processus. Il a ensuite redirigé une tâche de maintenance légitime vers un script Perl malveillant.
Le service privilégié a exécuté ce script avec les privilèges root. L’accès root donne à un opérateur le niveau de contrôle pratique le plus élevé sur l’appliance sous-jacente. L’exploit vérifiait son succès en testant s’il pouvait lire /etc/shadow, qui stocke des informations protégées sur les mots de passe dans les systèmes Linux.
L’opérateur a ensuite restauré la configuration et l’instruction mémoire modifiées. Il a également supprimé des entrées sélectionnées des journaux de débogage Ivanti et des journaux d’audit Linux. Ces actions ont réduit les preuves laissées derrière chaque commande.
La reconstitution technique complète montre que l’attaque ne se résumait pas à une seule requête avec une charge utile permanente. L’opérateur réexécutait la chaîne d’exploitation chaque fois qu’une autre commande était nécessaire.
Cette méthode est contraignante, mais elle offre un avantage défensif à l’attaquant. Les enquêteurs n’ont trouvé aucune porte dérobée de première étape ni aucun web shell conventionnel sur l’appliance compromise. Les commandes et leur sortie transitaient par les requêtes HTTPS de l’exploit.
Certaines étapes de la charge utile n’existaient qu’en mémoire. L’une d’elles décompressait un script Python encodé en Base64 puis l’exécutait sans conserver le script brut sur le disque. L’exécution uniquement en mémoire limite ce que les analyses ordinaires fondées sur les fichiers peuvent récupérer ultérieurement.
Volexity a indiqué que la chaîne contournait également l’Integrity Checker Tool d’Ivanti. Cet outil recherche les modifications inattendues de fichiers, mais l’attaque modifiait temporairement la mémoire et les données de configuration. L’exploit restaurait ces changements après avoir obtenu l’accès root.
Cette distinction importe pour chaque organisation concernée. Un contrôle d’intégrité ne signalant aucune modification inattendue de fichiers ne prouve pas qu’une exploitation n’a jamais eu lieu. Il répond seulement à la question plus restreinte pour laquelle l’outil a été conçu.
Le vol d’identifiants a fait du VPN un point de départ
UTA0576 a utilisé la passerelle compromise pour accéder à des données d’identité, transformant une faille d’appliance en un problème plus large d’accès à l’entreprise.
L’activité post-exploitation de l’opérateur était centrée sur les identifiants, les informations d’annuaire, la reconnaissance réseau et l’exfiltration de données. Ces actions suggèrent une préparation à des mouvements au-delà de l’appliance VPN. Volexity a déclaré que la campagne avait été interrompue avant que l’objectif final de l’attaquant ne devienne clair.
Active Directory était une cible principale. Active Directory est le service d’annuaire de Microsoft destiné à gérer les identités d’entreprise, les ordinateurs, les autorisations et l’authentification. Une appliance VPN s’y connecte souvent via un compte de service afin de vérifier les utilisateurs distants.
UTA0576 a utilisé l’accès de l’appliance pour interroger un contrôleur de domaine interne. Les enquêteurs ont récupéré un outil LDAP personnalisé ainsi que des scripts Python associés. LDAP est un protocole utilisé pour rechercher et gérer des informations d’annuaire.
L’opérateur a recherché plusieurs types de données de valeur :
Identifiants Local Administrator Password Solution
Informations de récupération BitLocker
Attributs contenant des valeurs de mots de passe stockées
Métadonnées de comptes utilisateur et chemins des scripts de connexion
Noms d’utilisateur valides trouvés dans les enregistrements d’authentification
Local Administrator Password Solution, ou LAPS, gère les mots de passe des administrateurs locaux pour les appareils Windows. Les informations de récupération BitLocker peuvent déverrouiller des disques Windows chiffrés. Le vol de l’un ou l’autre peut étendre l’accès longtemps après l’application du correctif au VPN vulnérable.
L’attaquant a compressé et encodé les résultats de l’annuaire avant de les transférer par le canal de l’exploit. Volexity a estimé avec un niveau de confiance élevé que l’opérateur avait exfiltré les informations accessibles par les requêtes Active Directory ciblées.
UTA0576 a également examiné les captures de paquets stockées sur l’appliance. L’opérateur a exécuté un analyseur conçu pour trouver des identifiants et des éléments destinés au cassage de mots de passe dans le trafic réseau enregistré. Ses cibles comprenaient des identifiants LDAP en clair, des identifiants HTTP Basic Authentication et des hachages défi-réponse NTLM.
Les hachages NTLM peuvent permettre des attaques hors ligne contre les mots de passe ou d’autres techniques d’abus d’identifiants. Le risque dépend de la configuration de l’organisation, de la qualité des mots de passe et des contrôles d’authentification. Leur collecte crée néanmoins une charge de remédiation qui dépasse la mise à jour d’un seul appareil.
Les enquêteurs ont découvert un utilitaire de capture de paquets renommé, exécuté depuis un répertoire caché. Il filtrait le trafic associé à des protocoles en clair, notamment LDAP, HTTP, FTP et Telnet. Huit fichiers de capture en rotation limitaient le stockage tout en remplaçant continuellement les anciens trafics.
La campagne comprenait également des requêtes DNS internes et une reconnaissance des noms d’hôtes. L’opérateur utilisait un script auxiliaire pour mener des attaques de password spraying contre des comptes Active Directory. Le password spraying consiste à tester un petit ensemble de mots de passe probables sur plusieurs comptes afin d’éviter des échecs répétés sur un même nom d’utilisateur.
Ces activités montrent pourquoi un appareil en périphérie peut devenir une position de renseignement précieuse. Il traite les flux d’authentification et voit du trafic réseau que les terminaux ordinaires ne reçoivent parfois jamais. Le compromettre fournit à la fois un point d’entrée et une plateforme d’observation des relations internes.
L’opérateur observé a également recherché des répertoires de configuration VPN et des journaux d’authentification. Ces enregistrements peuvent révéler des méthodes d’authentification, des noms d’utilisateur, des domaines internes et des services connectés. Même des recherches infructueuses peuvent aider un attaquant à cartographier l’étape suivante.
C’est le renversement central de l’alerte de la CISA. Les organisations achètent une passerelle d’accès à distance pour faire respecter des frontières d’identité. Dans cet incident, la passerelle est devenue un moyen de contourner l’authentification, puis une source de matériel d’authentification supplémentaire.
Ce risque ne se limite pas aux comptes locaux de l’appareil. Les administrateurs doivent considérer chaque secret que l’appareil a stocké, transmis, capturé ou auquel il pouvait accéder par l’intermédiaire d’un compte de service intégré. Le périmètre pertinent peut inclure des identifiants d’annuaire, des clés de récupération, des jetons et des mots de passe d’utilisateurs.
La rotation des identifiants doit suivre les éléments de preuve et l’architecture. Réinitialiser chaque compte sans plan peut perturber les opérations tout en laissant de côté des identifiants de service moins visibles. Les équipes doivent identifier les intégrations de l’appareil et prioriser les secrets dotés d’un accès privilégié ou réutilisable.
Les organisations doivent aussi examiner l’activité provenant de la passerelle. Une exploitation réussie peut faire paraître des connexions malveillantes comme provenant d’un appareil réseau de confiance. Les systèmes en aval peuvent traiter ces connexions différemment du trafic internet ordinaire.
Volexity a trouvé des signes de préparation à un mouvement latéral, c’est-à-dire le déplacement depuis l’appareil initial vers d’autres systèmes. L’entreprise n’a pas affirmé que toutes les techniques observées avaient réussi. Elle n’a pas non plus déterminé l’objectif final de l’opérateur.
Cette incertitude doit limiter les conclusions, et non retarder le confinement. Les défenseurs disposent de preuves vérifiées de vol d’identifiants et d’exfiltration de données dans au moins un environnement étudié. Ils doivent éviter de supposer qu’un appareil mis à jour met fin à toutes les conséquences d’un accès antérieur.
Le correctif ferme le point d’entrée, pas l’enquête
Le conflit principal oppose désormais le correctif à la preuve : installer un logiciel corrigé est nécessaire, mais ne peut pas établir si une exploitation antérieure a réussi.
Ivanti conseille à ses clients d’effectuer la mise à niveau immédiatement et d’exécuter régulièrement son Integrity Checker Tool. Ces mesures réduisent l’exposition et peuvent identifier certaines formes d’altération. Elles ne couvrent pas toutes les techniques documentées dans cet incident.
Volexity a constaté que l’opérateur supprimait certaines entrées de journal sélectionnées et annulait des modifications temporaires. L’attaquant supprimait également des scripts et les résultats de leur exécution après les avoir utilisés. Plusieurs composants importants ne s’exécutaient qu’en mémoire.
Ce comportement antiforensique modifie la valeur d’une analyse propre. Un résultat attendu peut signifier que l’appareil est sain. Il peut aussi signifier que l’attaquant a évité les artefacts mesurés par l’outil sélectionné.
L’analyse de réponse de Rapid7 recommande donc de rechercher des signes de compromission après avoir appliqué la mise à jour. Les organisations qui identifient une activité suspecte doivent suivre les recommandations de récupération d’Ivanti et préserver les preuves utiles.
La télémétrie réseau peut fournir des indices lorsque les journaux de l’appareil ne le peuvent pas. Volexity recommande de rechercher des volumes inhabituels de requêtes vers le chemin public welcome.cgi. Les défenseurs peuvent aussi examiner les divergences entre l’URL demandée et l’en-tête X-DSCGI-PATH.
Ces indicateurs sont utiles mais incomplets. Les attaquants peuvent adapter les chemins, le calendrier, l’infrastructure et les commandes post-exploitation. L’absence d’un schéma publié ne doit jamais devenir un test universel d’absence de compromission.
L’acquisition de mémoire peut révéler des artefacts volatils que les vérifications sur disque ne détectent pas. Toutefois, collecter la mémoire d’une passerelle de production exige des procédures et une expertise appropriées. Un redémarrage ou une reconstruction imprudente peut détruire les preuves nécessaires à la compréhension de l’incident.
Cela crée un compromis opérationnel. Les équipes veulent retirer rapidement du service l’appareil vulnérable. Les enquêteurs veulent préserver suffisamment d’état pour déterminer ce qui s’est produit et quels identifiants doivent être remplacés.
La séquence appropriée dépend de l’exposition, des besoins métier, de la redondance et du soutien médico-légal disponible. Les organisations doivent impliquer tôt les équipes de réponse aux incidents lorsqu’elles trouvent des indicateurs ou des connexions inexpliquées provenant de l’appareil. Elles doivent documenter chaque action de confinement et son heure.
Une réponse défendable sépare généralement quatre questions :
La version installée est-elle vulnérable ?
L’appareil était-il accessible pendant la fenêtre d’exploitation ?
Existe-t-il des preuves de tentatives ou d’exploitation réussie ?
Quels systèmes et identifiants étaient accessibles après la compromission ?
Le correctif ne répond qu’à la première question. Les registres d’exposition, les journaux réseau, les preuves en mémoire, les journaux d’identité et la télémétrie en aval répondent aux autres. Traiter ces questions comme interchangeables crée une fausse confiance.
La faiblesse non résolue d’élévation de privilèges ajoute une complication supplémentaire. Ivanti a corrigé les composants de contournement de l’authentification et d’exécution de code à distance le 13 octobre. Volexity a indiqué qu’Ivanti prévoyait une version ultérieure pour la faille distincte d’élévation de privilèges.
Cela ne signifie pas que la chaîne documentée reste exploitable après les correctifs d’octobre. Fermer ses étapes d’entrée non authentifiée et d’exécution devrait interrompre cette voie précise. Les administrateurs doivent néanmoins suivre la version supplémentaire et l’installer lorsqu’Ivanti la rendra disponible.
Les organisations doivent aussi vérifier que les mises à jour se sont réellement terminées. Les clusters d’appareils, les nœuds de secours, les systèmes de reprise après sinistre et les passerelles de test oubliées peuvent rester vulnérables après la modification de l’appareil principal. Les inventaires d’actifs doivent être comparés aux données de version réelles.
La découverte externe peut aider à révéler une exposition non gérée. Le tableau de bord d’exposition de Shadowserver offre une vue extérieure, mais aucun jeu de données externe ne fournit un inventaire parfait. Les registres internes de propriété restent essentiels.
Une réponse complète doit inclure les contrôles d’identité. Les équipes doivent examiner les schémas d’authentification, l’utilisation des comptes de service, les requêtes privilégiées vers l’annuaire, les signaux de password spraying et les accès inhabituels aux clés de récupération. Les secrets concernés doivent être renouvelés une fois que les équipes en ont compris les dépendances.
Les systèmes en aval méritent un examen distinct. Les connexions provenant de l’appareil VPN peuvent avoir hérité d’une relation de confiance ou contourné des contrôles appliqués aux clients ordinaires. Les enquêteurs doivent identifier le trafic inhabituel provenant de la passerelle pendant la fenêtre suspectée.
La conclusion la plus sûre est aussi la moins pratique : il n’existe pas de bouton unique « tout est clair » pour cet incident. Un logiciel corrigé, des résultats d’intégrité propres et l’absence d’indicateurs publiés fournissent chacun des éléments de preuve. Aucun ne prouve indépendamment qu’un appareil n’a jamais été compromis.
Les précédents zero-days d’Ivanti accentuent la pression
CVE-2026-104935 survient après des exploitations répétées de produits en périphérie, de sorte que les clients évaluent la maturité de la réponse autant qu’un correctif isolé.
Ivanti Connect Secure a fait face à plusieurs vulnérabilités graves activement exploitées ces dernières années. Début 2024, des attaquants ont enchaîné CVE-2023-46805 avec CVE-2024-21887. Cette combinaison permettait le contournement de l’authentification et l’injection de commandes contre des passerelles exposées sur internet.
La CISA a réagi de manière énergique durant cet épisode. Les agences fédérales ont reçu pour instruction d’appliquer des mesures d’atténuation, d’exécuter des vérifications d’intégrité et, à terme, de déconnecter les appareils concernés dans des conditions précisées. Des analyses ultérieures ont averti que des attaquants pouvaient maintenir leur accès malgré certaines actions de récupération.
En janvier 2025, Ivanti a divulgué l’exploitation active de CVE-2025-0282, un dépassement de tampon sur la pile affectant Connect Secure. Plus tard la même année, une autre faille de Connect Secure, CVE-2025-22457, a été associée à une exploitation par un groupe d’espionnage lié à la Chine.
Le nouvel incident ne prouve pas que chaque appareil Ivanti est compromis ou particulièrement peu sûr. Les produits d’entreprise en périphérie de plusieurs fournisseurs attirent des recherches intensives et un intérêt soutenu de la part des attaquants. Leur position rend une exploitation réussie particulièrement précieuse.
Volexity a établi une comparaison directe avec l’exploitation récente d’appareils SonicWall Secure Mobile Access. Dans les deux cas, des attaquants disposant d’un accès root ont inspecté des captures de paquets afin de récupérer des identifiants. Ce recoupement suggère une stratégie plus large contre des systèmes de périphérie réseau de confiance.
Les passerelles VPN partagent plusieurs caractéristiques favorables aux attaquants. Elles sont accessibles depuis internet, fonctionnent souvent en continu et se connectent directement à l’infrastructure d’identité. Elles exécutent aussi des environnements d’exploitation spécialisés que de nombreux produits de sécurité des terminaux ne peuvent pas surveiller normalement.
Un poste de travail peut disposer d’une détection sur terminal, de contrôles applicatifs et d’une télémétrie détaillée des processus. Un appareil de sécurité offre souvent moins d’outils d’investigation à son propriétaire. Les attaquants peuvent exploiter ce manque de visibilité tout en opérant depuis une position réseau hautement fiable.
Le schéma répété exerce une pression à la fois sur les fournisseurs et les clients. Les fournisseurs doivent raccourcir le délai entre la découverte d’une faille partielle et la protection de chaque branche prise en charge. Les clients doivent réduire leur dépendance aux avis d’urgence comme principal mécanisme de détection.
Ivanti a indiqué qu’une partie de CVE-2026-104935 avait été découverte dans le cadre de son programme de sécurité des produits. Ce composant a été corrigé dans la version de juillet 2026 de la version 25.1.3.0. L’exploitation s’est produite alors que l’entreprise rétroportait le correctif vers d’autres versions prises en charge.
Cette chronologie mérite un examen attentif, mais elle ne justifie pas une accusation simpliste. Le rétroportage de modifications de sécurité entre branches de versions peut exiger de l’ingénierie et des tests de compatibilité. Les informations publiques n’établissent pas quand Ivanti a compris l’ensemble de la chaîne d’exploitation ni son utilisation réelle.
Le résultat a néanmoins révélé une lacune dans les correctifs. Certains clients utilisant d’autres branches prises en charge sont restés vulnérables après qu’une branche a reçu un correctif pertinent. Des attaquants ont opéré durant cet intervalle et compromis une version considérée comme actuelle pour sa ligne.
Cela soulève une question pratique en matière d’achats. Les acheteurs doivent demander comment les fournisseurs propagent les correctifs de sécurité entre les branches prises en charge. Ils doivent également demander si des conseils de détection accompagnent le correctif et comment les appareils préservent les preuves médico-légales.
Les clients peuvent réduire leur exposition future sans attendre un autre avis. Ils peuvent réduire au minimum l’accessibilité directe depuis internet, restreindre les interfaces d’administration et surveiller le trafic provenant des passerelles. Ils peuvent également centraliser les journaux afin qu’un attaquant ne puisse pas effacer localement tous les enregistrements utiles.
La segmentation compte également. Un appareil d’accès à distance ne doit pas bénéficier d’une portée illimitée simplement parce qu’il exerce une fonction de confiance. Ses comptes de service ne doivent détenir que les autorisations nécessaires, tandis que les protocoles d’authentification en clair doivent être supprimés lorsque cela est possible.
Ces mesures n’éliminent pas le risque de zero-day. Elles limitent ce que les attaquants peuvent obtenir lorsqu’un appareil est compromis. La leçon récurrente des incidents impliquant Ivanti, SonicWall, Citrix et d’autres équipements en périphérie est que les appliances périmétriques ont elles aussi besoin d’un confinement interne.
La pression sur Ivanti ne se limitera donc pas à la publication de mises à jour. Les clients surveilleront la rapidité avec laquelle arrivera le correctif restant pour l’élévation de privilèges. Ils évalueront également si les nouvelles versions améliorent la collecte de preuves et résistent aux manipulations ne laissant de traces qu’en mémoire.
Trois signaux indiqueront si la réponse a fonctionné
La prochaine phase dépendra de l’augmentation de l’exploitation, du correctif Ivanti restant et de preuves de compromission au-delà des environnements initialement étudiés.
Le premier signal sera de savoir si les analyses et l’exploitation s’étendent après la divulgation publique. Les détails techniques sont désormais disponibles, même si Volexity a retenu le code d’exploitation opérationnel. D’autres acteurs peuvent néanmoins étudier la faille de routage, reproduire la condition de concurrence et développer leur propre implémentation.
Une forte hausse des requêtes impliquant welcome.cgi ou des valeurs X-DSCGI-PATH suspectes renforcerait la nécessité d’un confinement d’urgence. Les rapports des entreprises de réponse aux incidents montreront si UTA0576 est resté l’opérateur principal ou est devenu l’un parmi beaucoup d’autres.
Le deuxième signal sera le correctif promis par Ivanti pour la vulnérabilité distincte d’élévation de privilèges. Les administrateurs doivent suivre l’avis de l’entreprise, les notes de version et les recommandations relatives aux versions prises en charge. Ils doivent vérifier chaque nœud actif et de secours après le déploiement.
Une publication rapide supprimerait une autre voie d’élévation locale documentée dans la chaîne d’attaque. Un retard laisserait les clients gérer une incertitude supplémentaire, même après l’application du correctif pour CVE-2026-104935 elle-même.
Le troisième signal sera la découverte d’une compromission en aval. De nouveaux rapports concernant des identifiants d’annuaire volés, un accès non autorisé à la récupération BitLocker ou des mouvements latéraux élargiraient l’impact connu de l’incident. Ils confirmeraient également qu’une remédiation uniquement centrée sur l’appliance était trop limitée.
Les organisations ne devraient pas attendre ces rapports avant de vérifier leurs propres environnements. L’opérateur observé a recherché des secrets d’identité immédiatement après avoir obtenu un accès root. Ce comportement définit le périmètre minimal d’investigation pour les systèmes exposés.
Les défenseurs devraient préserver les journaux de passerelle, de pare-feu, d’identité, de DNS et d’annuaire couvrant toute la période d’exposition. Ils devraient rechercher les connexions provenant de l’appliance qui ne correspondent pas au comportement habituel d’accès à distance. Les comptes de service concernés et les secrets réutilisables exigent une attention particulière.
La vulnérabilité d’Ivanti Connect Secure constitue également un test plus large des programmes de gestion des vulnérabilités. La rapidité d’inventaire compte autant que la rapidité de correction. Une organisation ne peut pas protéger une passerelle de secours, un appareil de laboratoire oublié ou une appliance héritée dont personne n’est responsable.
L’avertissement de la CISA devrait donc déclencher un flux de travail coordonné. Les opérations de sécurité, l’ingénierie réseau, les équipes d’identité et les intervenants en réponse aux incidents ont besoin de la même chronologie et de la même liste d’actifs. Chaque équipe voit une partie différente du chemin d’attaque.
L’application de correctifs reste urgente, mais ce n’est que le premier mouvement. La question la plus importante est de savoir si votre organisation peut prouver à quelles ressources l’appliance a accédé avant l’arrivée du correctif. Examinez l’avis, confirmez chaque version déployée, préservez les preuves et enquêtez dès maintenant sur l’activité provenant des passerelles. Si l’appareil avait accès à des données d’identité précieuses, traitez-vous cela comme une maintenance de routine ou comme une possible violation de données ?
