La réponse courte
Une Cisco ISE non corrigée peut être prise en main par une seule requête forgée — sans login, sans identifiants. CVE-2026-76460 (CVSS 10.0) est une faille de contournement d'authentification sur un point d'entrée d'API d'ISE qui débouche sur l'exécution arbitraire de commandes en root. Cisco a confirmé une exploitation active, la CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities en septembre 2026, et Cisco indique qu'il n'existe aucun contournement. La remédiation consiste à mettre à jour ISE vers une version corrigée sans délai.
Pour les équipes en France et dans l'UE, le point sensible tient à l'emplacement de la faille : ISE est le système qui décide qui et quoi est autorisé sur le réseau ; le posséder revient à posséder la politique d'accès elle-même. Ces boîtiers bénéficient d'une confiance implicite et entrent rarement dans un périmètre de test — c'est justement pourquoi ils doivent y figurer. C'est la posture que nous intégrons à un test d'intrusion et audit de sécurité : traiter les systèmes censés appliquer votre sécurité comme une surface d'attaque et prouver qu'ils tiennent.
Ce que Cisco a divulgué
Cisco Identity Services Engine (ISE) est le cerveau des politiques du contrôle d'accès réseau en entreprise. Elle authentifie les utilisateurs et les appareils, applique qui peut atteindre quel segment de réseau et pilote 802.1X, l'accès invité, les contrôles de posture et la segmentation. Ce rôle en fait l'un des points de passage les plus sensibles d'une architecture d'entreprise : un attaquant qui contrôle ISE ne compromet pas un seul serveur, il obtient un levier sur les règles qui régissent l'accès à tout le reste.
En septembre 2026, Cisco a divulgué CVE-2026-76460, une vulnérabilité due à des contrôles d'authentification insuffisants sur un point d'entrée d'API précis dans ISE et l'ISE Passive Identity Connector (ISE-PIC). Un attaquant distant non authentifié peut envoyer une requête forgée à ce point d'entrée, contourner l'interface de gestion web et, in fine, exécuter des commandes avec les privilèges root sur le système sous-jacent. Cisco l'a évaluée à CVSS 10.0 — le sommet de l'échelle —, a précisé qu'ISE et ISE-PIC sont concernés quelle que soit la configuration, et a confirmé l'absence de contournement.
Le PSIRT de Cisco a également indiqué avoir connaissance d'une exploitation active. Peu après la divulgation, la CISA a ajouté CVE-2026-76460 à son catalogue Known Exploited Vulnerabilities, ce qui déclenche un délai de remédiation obligatoire pour les agences fédérales civiles américaines et constitue un signal fort pour tous les autres. L'inscription au KEV signifie que les attaques sont confirmées, pas théoriques — et comme un exploit réussi s'exécute en root, un intrus peut aussi masquer ou supprimer les indices mêmes qu'un défenseur chercherait.
Pourquoi une requête devient root
Ce qui rend ce bug si grave, c'est l'absence totale de prérequis. Aucun mot de passe à deviner, aucune session à détourner, aucun leurre de phishing sur lequel un utilisateur doit cliquer. L'attaquant envoie une seule requête forgée à un point d'entrée d'API qui n'applique pas l'authentification, et ce seul défaut ouvre la surface de gestion. Comme le processus exploité s'exécute avec des privilèges élevés, la chaîne se termine par l'exécution de commandes en root sur l'hôte — une compromission complète de l'appareil à partir d'un point de départ non authentifié.
Cette combinaison — non authentifié, à distance, sans interaction utilisateur, résultat en root — explique pourquoi le score CVSS atteint 10.0 et pourquoi l'exploitation a suivi la divulgation si vite. Un attaquant qui possède ISE possède le système qui décide de l'accès réseau : il peut créer ou modifier la politique d'accès, autoriser ses propres appareils, désactiver la segmentation qui le contenait, lire les données d'identité et de posture détenues par ISE, et utiliser le boîtier comme point d'ancrage durable et de confiance pour se déplacer latéralement. Pour un contrôle de sécurité, c'est le pire des scénarios, car la brèche se produit à l'intérieur même du mécanisme installé pour la prévenir.
Aucun indicateur de fonctionnalité ni réglage de politique ne neutralise CVE-2026-76460, d'où l'insistance de Cisco sur l'absence de contournement. Le code vulnérable se trouve dans le chemin d'authentification de l'API elle-même. Cisco a publié des versions corrigées sur les branches prises en charge — ISE et ISE-PIC 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 et 3.5 Patch 4 — et la mise à jour vers l'une d'elles est la seule vraie remédiation. À titre provisoire, le temps de planifier la mise à jour, des listes de contrôle d'accès d'infrastructure (iACL) qui restreignent le trafic vers les interfaces de gestion et d'API d'ISE peuvent bloquer le chemin distant dont un attaquant a besoin.
Ce que cela implique pour les équipes en France
La première leçon est que le contrôle d'identité fait partie de votre surface d'attaque, il ne remplace pas sa sécurisation. Les équipes font confiance implicitement à la pile de sécurité — le NAC, le serveur d'identité, le pare-feu — et laissent ces appareils hors des évaluations qu'elles mènent contre leurs propres applications. Or un boîtier accessible depuis Internet ou depuis le réseau de gestion, avec un chemin pré-authentification vers le root, est exactement ce qu'un attaquant cherche en premier — et ici il donne le contrôle de la politique d'accès en une étape. La même discipline de durcissement que vous appliquez à votre plateforme Cloud & DevOps — moindre privilège, exposition réseau réduite, pipelines de correctifs rapides et supervision — doit s'étendre aux boîtiers d'identité et de réseau, pas s'arrêter au code que vous avez écrit.
La deuxième leçon porte sur la vélocité de correction comme capacité opérationnelle. Quand un bug passe de la divulgation au KEV de la CISA en peu de temps, est noté 10.0 et n'a aucun contournement, la seule variable que vous maîtrisez est la rapidité avec laquelle vous identifiez les nœuds affectés et déployez le correctif. Les organisations qui tiennent un inventaire d'actifs à jour, savent quels boîtiers exposent des interfaces de gestion ou d'API et peuvent planifier une mise à jour hors bande en quelques heures refermeront la brèche avant qu'elle ne serve contre elles ; celles qui découvrent leur exposition pendant un incident, non. Cette préparation est un processus à bâtir à l'avance, pas à improviser sous le feu.
Troisièmement, il s'agit d'un événement de conformité et de notification, pas seulement d'un ticket informatique. ISE régit l'accès à des systèmes qui traitent couramment des données personnelles et réglementées ; une compromission root de l'appareil relève donc directement des attentes du RGPD, de NIS2 et — pour le secteur financier — de DORA en matière de contrôle d'accès et de remédiation rapide et documentée. En France, les OIV et les entités relevant de la loi de programmation militaire ont des obligations supplémentaires de sécurité et de signalement à l'ANSSI. Pouvoir montrer quels nœuds étaient affectés, quand vous avez corrigé, si vous avez appliqué des iACL entre-temps et ce que vous avez recherché comme preuves d'exploitation, c'est le dossier que régulateurs et auditeurs demanderont en premier.
Que faire maintenant
- Recensez chaque nœud ISE. Trouvez tous les déploiements Cisco ISE et ISE-PIC, y compris les instances de secours, secondaires et de laboratoire — celles qui manquent à votre liste sont celles qui restent non corrigées.
- Corrigez sans délai. Appliquez la version corrigée pour votre branche — 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 ou 3.5 P4. Il n'y a aucun contournement, traitez-la donc comme un changement d'urgence, pas comme une fenêtre de maintenance planifiée.
- Restreignez l'accès entre-temps. Tant que chaque nœud n'est pas corrigé, utilisez des iACL pour limiter le trafic vers les interfaces de gestion et d'API d'ISE aux réseaux d'administration de confiance, coupant le chemin distant dont un attaquant a besoin.
- Recherchez des traces d'exploitation. Examinez les journaux ISE et réseau à la recherche d'appels d'API inattendus, de politiques d'accès nouvelles ou modifiées, d'appareils autorisés inconnus et d'activité root. Si un nœud était accessible et non corrigé, enquêtez en supposant qu'il puisse déjà être compromis — et rappelez-vous qu'un attaquant root a pu altérer les journaux.
- Contenez et faites tourner, puis testez. Faites tourner les identifiants, certificats et secrets qu'ISE détenait ou pouvait observer, validez l'intégrité de vos politiques d'accès, et ajoutez les boîtiers d'identité et d'accès réseau au périmètre de votre prochain test d'intrusion pour que la prochaine inscription au KEV déclenche l'action automatiquement.
Questions fréquentes
Qu'est-ce que la CVE-2026-76460 ?
C'est une faille critique de contournement d'authentification (CVSS 10.0) dans une API de Cisco Identity Services Engine (ISE) et d'ISE Passive Identity Connector (ISE-PIC). Des contrôles d'authentification insuffisants sur un point d'entrée précis laissent un attaquant distant non authentifié envoyer une requête forgée, contourner l'interface de gestion web et, in fine, exécuter des commandes en root. Les deux produits sont concernés quelle que soit la configuration, et il n'existe aucun contournement.
Comment la faille est-elle exploitée ?
L'attaque ne requiert aucune authentification ni interaction du côté de la cible. Un attaquant envoie une requête spécialement forgée à un point d'entrée d'API vulnérable qui n'applique pas l'authentification ; ce contournement ouvre la surface de gestion, et une exploitation réussie se termine par l'exécution de commandes en root. Comme ISE décide qui et quoi peut se connecter au réseau, en prendre le contrôle revient à contrôler la politique d'accès réseau.
Quelles versions sont concernées, et quels sont les correctifs ?
Cisco ISE et ISE-PIC sont concernés quelle que soit la configuration. Cisco a publié des versions corrigées : ISE/ISE-PIC 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 et 3.5 Patch 4. Il n'y a aucun contournement ; l'application de la version corrigée est la seule remédiation. Comme bouclier temporaire, des iACL restreignant le trafic vers l'appareil concerné peuvent empêcher l'exploitation à distance.
La CVE-2026-76460 est-elle exploitée dans la nature ?
Oui. Le PSIRT de Cisco a confirmé avoir connaissance d'une exploitation active, et la CISA a ajouté la faille à son catalogue américain Known Exploited Vulnerabilities en septembre 2026, ce qui oblige les agences fédérales civiles à corriger dans un délai fixé. L'inscription au KEV signifie des attaques confirmées ; toute organisation exploitant un déploiement ISE affecté doit donc traiter le correctif comme une urgence.
Que doivent faire les équipes maintenant ?
Recensez chaque nœud ISE et ISE-PIC, y compris les instances de secours et de laboratoire, et appliquez immédiatement la version corrigée pour votre branche. Pendant la correction, utilisez des iACL pour restreindre l'accès de gestion et d'API à des réseaux de confiance. Examinez les journaux à la recherche d'appels d'API inattendus, de politiques d'accès modifiées et d'activité root, et supposez une compromission si l'appareil était accessible et non corrigé. Faites tourner les identifiants et certificats détenus par ISE, et ajoutez les boîtiers d'identité et de réseau à votre prochain test d'intrusion.
Sources
SecurityWeek — Active Exploitation Triggers Emergency Patch for Cisco ISE Zero-Day
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog