Le moteur d'identité de Cisco a neuf nouvelles failles, et l'une décroche un 10 sur 10

Cisco a publié le 16 septembre 2026 une série d'avis de sécurité décrivant neuf vulnérabilités dans Identity Services Engine (ISE), la plateforme que les entreprises utilisent pour décider quels appareils et quels utilisateurs peuvent rejoindre leurs réseaux. Une faille sort du lot. Répertoriée sous la référence CVE-2026-76460, elle permet à un attaquant non authentifié de contourner depuis le réseau l'interface de gestion web d'une appliance affectée, et le Product Security Incident Response Team de Cisco dit avoir connaissance d'une exploitation active. Le score CVSS est de 10,0, le maximum. La CISA l'a ajoutée à son catalogue des vulnérabilités exploitées connues le jour même et a donné aux agences fédérales civiles jusqu'au 19 septembre pour la corriger.

À lire aussi: Une faille zero-day dans la passerelle e-mail de Cisco donne un accès root aux attaquants à partir d'un seul message · Une faille d'authentification de Rejetto HFS trouvée par IA attire des tentatives d'exploitation.

Le délai serré est révélateur. En vertu de la directive opérationnelle contraignante 26-04, la CISA fixe d'ordinaire une date de remédiation à plusieurs semaines, et une fenêtre de trois jours signale que le risque est au présent et que le correctif est prêt à être déployé. Pour toute organisation qui exploite ISE et l'expose à internet, la marge est mince.

Ce que fait Cisco ISE

ISE n'est pas un produit de niche. C'est le moteur de politiques qui sous-tend l'authentification 802.1X, le profilage des appareils et l'évaluation de leur conformité pour les accès filaires, sans fil et VPN. Quand un ordinateur portable, un téléphone ou un lecteur de badge tente d'atteindre le réseau de l'entreprise, ISE est souvent le système qui vérifie l'identifiant, évalue l'appareil et répond oui ou non. C'est l'expression technique de l'idée du zero trust : ne faire confiance à personne tant que l'identité et l'état de l'appareil n'ont pas été vérifiés.

C'est ce rôle qui fait qu'une faille ici compte davantage qu'une faille dans un outil périphérique. Un attaquant capable de contourner l'authentification d'ISE, ou d'exécuter des commandes sur l'appliance, ne compromet pas seulement un serveur. Il atteint le plan de contrôle qui décide qui a le droit d'entrer sur le réseau. Quand le système qui vérifie les identités est lui-même contournable, le modèle de sécurité bâti par-dessus perd son socle.

Les neuf failles

Les divulgations du 16 septembre s'étendent sur plusieurs avis et vont d'un contournement d'authentification quasi parfait à des failles d'injection de commandes qui exigent d'abord des identifiants.

• CVE-2026-76460 (CVSS 10,0) : un contournement d'authentification de l'API REST sans authentification. Cisco l'attribue à un contrôle d'authentification insuffisant sur un point de terminaison de l'API, et une requête forgée suffit à atteindre l'interface de gestion. C'est la faille activement exploitée.
• CVE-2026-76423 (CVSS 10,0) : un second contournement d'authentification de l'API REST, divulgué dans un avis distinct couvrant six problèmes supplémentaires.
• CVE-2026-76424 : une faille d'accès arbitraire aux fichiers pouvant mener à l'exécution de code à distance.
• CVE-2026-76446 : une faille d'entité externe XML qui permet à un attaquant authentifié de lire certains fichiers du système d'exploitation sous-jacent.
• CVE-2026-20305 et CVE-2026-20306 (CVSS 9,1) : une injection de commandes dans les outils de diagnostic et l'API REST. Les deux exigent une authentification, mais permettent une élévation jusqu'à root.
• CVE-2026-20307 (CVSS 9,9) : une faille d'exécution de code à distance qui exige des identifiants privilégiés valides.
• CVE-2026-20176 : une faille d'exécution de commandes authentifiée qui permet une élévation jusqu'à root. Sur un déploiement à nœud unique, son exploitation peut mettre le nœud hors ligne, ce qui empêcherait les terminaux qui ne se sont pas déjà authentifiés d'atteindre le réseau.
• CVE-2026-20211 : un problème d'exécution de code à distance corrigé en même temps que les autres.

Les failles d'injection de commandes ont été signalées par des chercheurs de STAR Labs SG, selon Forkast. C'est la deuxième fois cette année que ce groupe trouve une faille d'injection de commandes au niveau root dans la même plateforme. Les avis de Cisco indiquent qu'aucun contournement ne corrige les failles d'exécution de code à distance de ce groupe, et que les clients doivent mettre à niveau à la place.

Exploitée avant d'être corrigée

CVE-2026-76460 a été découverte via un dossier de support du Technical Assistance Center de Cisco, ce qui signifie qu'au moins un environnement client était déjà compromis avant que la faille soit pleinement comprise et corrigée. Ce scénario d'origine est connu. Les appliances de périphérie et d'infrastructure produisent peu de la télémétrie des terminaux que les centres d'opérations de sécurité sont conçus pour surveiller, si bien que leur compromission tend à n'apparaître que lorsqu'un élément en aval tombe en panne ou qu'un client appelle l'éditeur pour signaler un comportement étrange. À ce moment-là, un intrus qui visait la persistance a généralement eu le temps de s'organiser.

L'avis de Cisco confirme une exploitation dans la nature mais ne nomme aucun acteur de la menace, n'attribue pas l'activité et n'en décrit pas l'ampleur. La notation de changement de portée du vecteur CVSS signifie qu'une exploitation réussie peut toucher des ressources au-delà du composant vulnérable, de sorte qu'un nœud ISE compromis doit être traité comme un possible tremplin plutôt que comme un incident isolé.

Pourquoi l'infrastructure d'identité est toujours visée

La divulgation d'ISE s'inscrit dans un schéma qui a marqué 2026. Secret Server de Delinea, la propre passerelle de messagerie de Cisco, Check Point, MikroTik et ConnectWise ont tous eu affaire à des failles de périphérie ou d'infrastructure exploitées dans la nature, et plusieurs d'entre elles ont atterri dans le catalogue de la CISA. Le point commun est la position. Ces systèmes se trouvent en dehors du périmètre d'identité qu'ils contribuent à faire respecter, si bien que l'authentification multifacteur et les contrôles des terminaux n'arrêtent pas l'exploitation initiale. Ils tournent en continu, parlent à internet quand ils ne le devraient pas et sont rarement reconstruits.

Les plateformes d'identité et d'accès sont une version particulièrement attrayante de cette cible, car les compromettre ne demande pas de vaincre l'authentification. Il suffit de réécrire la réponse. Un système de contrôle d'accès au réseau détourné peut admettre l'appareil d'un attaquant comme s'il était géré et conforme. Dans ce scénario, la surveillance classique peut voir du trafic normal sur un segment de confiance, car du point de vue du réseau tout est en ordre.

Il existe aussi une dimension de chaîne d'approvisionnement. Ces plateformes sont dignes de confiance par conception, ce qui signifie que leurs API, leur gestion des entités externes et leurs outils de diagnostic se trouvent dans le rayon d'impact des organisations qui les déploient. Chaque fonction de confort, depuis une interface REST que les administrateurs automatisent jusqu'à une page de diagnostic qui exécute des commandes, élargit un peu la surface d'attaque dont héritent les défenseurs.

Le correctif, et le cas particulier d'ISE-PIC

Cisco a publié des versions corrigées sur les branches prises en charge : 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 et 3.5 Patch 4, certaines corrections arrivant dans 3.5 Patch 3. Sa consigne habituelle pour l'avis sur l'exécution de code à distance est de mettre à niveau plutôt que d'atténuer, car aucun contournement n'existe.

Les déploiements hérités demandent une autre forme d'attention. ISE-PIC, la gamme Passive Identity Connector, s'arrête à la version 3.4, que Cisco a marquée en fin de commercialisation. Les organisations qui l'exploitent encore font face à ces failles sans possibilité de mise à niveau sur place et devront planifier une migration. C'est dans ce genre de trous que se logent d'ordinaire les expositions les plus durables, car ces systèmes sont assez anciens pour que personne n'en soit responsable et assez importants pour que personne ne veuille les éteindre.

Ce que les défenseurs doivent faire

1. Recenser chaque instance ISE, y compris les clusters de laboratoire, de préproduction et les clusters oubliés, et déterminer lesquels sont joignables depuis internet.
2. Appliquer un correctif vers une version corrigée de votre branche. Là où c'est impossible dans un délai court, restreindre l'accès par des règles de pare-feu ou une ACL et traiter l'appliance comme un actif surveillé.
3. Chercher des preuves d'exploitation, pas seulement d'exposition. Examiner les journaux de l'API et du web pour repérer des requêtes inhabituelles avant le correctif, chercher de nouveaux comptes locaux ou tâches planifiées, et passer en revue les connexions sortantes.
4. Renouveler tout ce que l'appliance peut atteindre. Si ISE détient des identifiants ou une confiance que d'autres systèmes consomment, partir du principe que ces relations se trouvaient dans le rayon d'impact.
5. Traiter toute détection positive comme une violation. Un accès root ou administratif à la plateforme d'identité peut survivre à la machine sur laquelle il a été obtenu.

Réserves et points à surveiller

• L'attribution reste ouverte. Les avis ne nomment aucun acteur de la menace et ne décrivent pas l'ampleur de l'utilisation de CVE-2026-76460.
• La date du catalogue KEV est un plancher, pas un plafond. Le 19 septembre concerne les agences fédérales civiles. Les organisations privées font face à la même exposition sans obligation de déclaration.
• Le balayage suit généralement le catalogue. Dès qu'une faille entre dans la liste KEV, le sondage massif des instances exposées tend à arriver en quelques jours. Réduire l'exposition publique vaut la peine quel que soit le calendrier de correction.
• Les failles d'injection de commandes ne font pas les gros titres, mais elles comptent. Elles exigent des identifiants, mais elles aboutissent à root, un chemin court entre l'accès administratif et le contrôle total.

La leçon utile n'est pas que Cisco a passé une mauvaise semaine. C'est que les systèmes auxquels on confie la décision de savoir qui a sa place sur un réseau comptent parmi les actifs les plus précieux d'une organisation, et qu'ils sont souvent les moins observés. Les équipes qui traversent ce genre d'incident sans dégâts sont généralement celles qui savaient déjà ce qu'elles possédaient et ont pu corriger avant qu'un scanner ne se présente.

Couverture : Cisco Systems Headquarters (Building 10), San José, par Travis Wise (CC BY 2.0) via Wikimedia Commons.