Cisco corrige une faille d’authentification déjà exploitée dans son moteur de contrôle d’accès ISE

16 septembre 2026. Cisco publie une salve d’avis de sécurité consacrés à Identity Services Engine (ISE), le moteur de contrôle d’accès qui décide qui a le droit d’entrer sur le réseau. Le même jour. Le constructeur confirme qu’au moins une des failles corrigées est déjà exploitée dans la nature : CVE-2026-76460, un contournement d’authentification à CVSS 10,0. Septembre 2026. Une release de durcissement issue d’un audit interne — mené avec l’appui de modèles d’IA — regroupe six autres vulnérabilités. Pourquoi c’est important : contourner l’authentification d’ISE, c’est contourner la porte elle-même.

ISE, la porte du réseau

ISE n’est ni un pare-feu ni un routeur. C’est l’appareil qui applique les politiques d’accès au réseau : il négocie le 802.1X, répond aux requêtes RADIUS et TACACS+, profile les terminaux et décide, par VLAN ou par ACL, ce qu’un poste a le droit de toucher une fois branché. Dans les grandes organisations, c’est lui qui transforme une prise murale en un accès contrôlé plutôt qu’en un accès libre.

Cette position en fait une cible d’une valeur particulière. Un attaquant qui exécute du code sur ISE ne compromet pas un serveur parmi d’autres : il compromet la machine qui délivre les autorisations. De là, il peut créer des comptes, abaisser des politiques, exfiltrer les journaux d’authentification — et, surtout, rester discret en s’accordant lui-même un accès légitime au réseau. C’est la différence entre un point de pivot ordinaire et un crown jewel : on ne l’atteint pas pour ce qu’il contient, mais pour ce qu’il commande.

CVE-2026-76460 : un contournement d’authentification déjà exploité

La faille la plus urgente est CVE-2026-76460, classée critique avec un score CVSS 10,0. Le vecteur est sans ambiguïté : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Un attaquant distant, non authentifié, sans interaction utilisateur, obtient un impact élevé sur la confidentialité, l’intégrité et la disponibilité, avec un champ d’action étendu (S:C) — la compromission franchit une frontière de confiance.

La cause est une CWE-648, « utilisation incorrecte d’API privilégiées » : le contrôle d’authentification d’un endpoint API est insuffisant. Une requête forgée adressée à cet endpoint permet de contourner l’interface d’administration web et d’accéder à l’appareil sans identifiants. Cisco précise qu’une exploitation réussie peut déboucher sur une exécution de commandes avec les privilèges root.

Trois détails aggravent le tableau. D’abord, la faille touche ISE et ISE-PIC (le Passive Identity Connector) quelle que soit la configuration — il n’y a pas de configuration qui protège. Ensuite, Cisco confirme une exploitation active : la faille a été découverte non pas par un audit, mais pendant la résolution d’un cas de support TAC. Enfin, il n’existe aucun contournement (workaround) : la seule parade logicielle est la mise à jour.

La portée de root a une conséquence directe sur la détection. Un attaquant qui dispose de ce niveau d’accès peut effacer les traces de sa présence. Cisco recommande donc de ne pas se fier aux seuls journaux de l’appareil : croiser les journaux réseau et pare-feu externes pour repérer les téléversements sortants ou les connexions vers des adresses suspectes.

Une release de durcissement issue d’un audit assisté par IA

À côté de ce contournement, Cisco publie une release de durcissement (cisco-sa-hardening-ise-XU5EwX5T) qui regroupe six vulnérabilités découvertes lors d’un audit interne de sécurité. Le détail qui retient l’attention est dans la rubrique « Source » : ces failles ont été trouvées « en utilisant les processus de test existants ainsi que des modèles d’IA de pointe ». C’est l’application concrète de la stratégie que Cisco décrivait dans son billet sur la découverte de vulnérabilités accélérée par l’IA.

Chaque CVE correspond ici à une classe de faiblesse (CWE) plutôt qu’à une faille unique — un choix assumé par Cisco pour regrouper les problèmes par nature et simplifier la communication.

Deux scores à 10,0 et deux à 9,9 dans une seule release de durcissement, c’est un signal rare. L’essentiel n’est pas le nombre, c’est la nature : des classes d’injection et de contrôle d’accès sur un produit dont tout le rôle est de contrôler l’accès.

La salve du 16 septembre va plus loin. D’autres avis couvrent des RCE dans ISE (CVE-2026-20211, CVE-2026-20176, CVE-2026-20307, à 9,9), des RCE authentifiées et des failles d’API (CVE-2026-20282 et suivantes, à 9,1), de l’injection de commandes (CVE-2026-20306, 9,1) et un déni de service RADIUS (CVE-2026-20352, 8,6). Le RADIUS mérite l’attention : c’est le protocole par lequel ISE répond aux demandes d’authentification des équipements du parc — un déni de service sur ce flux bloque les connexions au réseau, pas seulement à la console d’administration.

Ce que l’attaquant obtient une fois root

Il faut nommer l’impact avec précision. Avec root sur ISE, un attaquant ne « lit pas des fichiers » : il modifie la politique d’accès au réseau en direct. Il peut créer un utilisateur local fantôme, désactiver le posture checking qui vérifie la conformité des postes, ouvrir un VLAN sensible à un segment qu’il contrôle, ou exfiltrer la base des comptes et des certificats. Le tout avec l’apparence d’une configuration légitime, puisque c’est l’appareil lui-même qui la produit.

C’est aussi une machine de persistance idéale. Parce qu’ISE reçoit et journalise chaque tentative d’authentification du parc, un attaquant qui y est installé voit passer les identifiants et peut choisir ses prochaines cibles avec une visibilité que peu d’autres positions offrent. La recommandation de Cisco de réimager les nœuds compromis plutôt que de simplement les nettoyer n’est pas un excès de prudence : avec un accès root, on ne peut plus faire confiance à la machine pour attester de sa propre intégrité.

Ce qu’il faut faire

Cinq actions, par ordre de priorité :

• Mettez ISE à jour immédiatement. La faille d’authentification est exploitée et sans workaround : la fenêtre n’est pas une question de « si », mais de « qui est déjà passé ». Les versions corrigées sont 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 et 3.5 Patch 4.
• En attendant la mise à jour, restreignez le plan de gestion. Cisco préconise des iACL (access lists d’infrastructure) n’autorisant que le trafic de gestion et de contrôle strictement nécessaire vers l’appareil. C’est un pansement, mais il réduit la surface du contournement.
• Vérifiez l’exploitation passée. Sur chaque nœud, inspectez access.log à la recherche d’identifiants suspects — Cisco fournit la commande show logging application ise-kong/access.log | include dummyuser — et croisez avec les journaux pare-feu et réseau externes.
• Réimagez tout nœud suspect. Si une activité malveillante est soupçonnée, Cisco recommande de réimager le nœud et de le restaurer depuis une sauvegarde de configuration, pas de le « nettoyer ».
• Traitez ISE-PIC comme ISE. Le Passive Identity Connector est couvert par les mêmes failles ; ISE 3.0 a atteint la fin de maintenance et doit être migré vers une release corrigée.

La version 3.4 est la dernière release supportée pour ISE-PIC, dont la fin de vente est actée : les parcs qui s’appuient encore sur cette appliance doivent planifier leur migration en même temps que la mise à jour.

Verdict

Si vous exploitez ISE en production, traitez CVE-2026-76460 comme un incident en cours, pas comme un correctif de routine : elle est exploitée, sans contournement, et donne root sur l’appareil qui commande l’accès au réseau. Appliquez la mise à jour vers la release corrigée de votre branche 3.x et posez des iACL sur le plan de gestion dans la même fenêtre de maintenance. Si vous ne pouvez pas patcher aujourd’hui, la restriction du plan de gestion par ACL est la seule mesure qui réduit réellement l’exposition en attendant. Dans tous les cas, réimager tout nœud pour lequel le moindre doute d’exploitation subsiste — un accès root invalide la confiance dans les journaux de la machine.

Références

• Cisco — Identity Services Engine Authentication Bypass Vulnerability (CVE-2026-76460)
• Cisco — Identity Services Engine Hardening Release: September 2026
• Cisco — Advance Notification for Publication of September 16, 2026, Security Advisories
• Cisco Blog — Strengthening the Foundation: A Predictable, Customer-Focused Response to AI-Accelerated Vulnerability Discovery