CVE-2026-76460 : une requête suffit pour prendre la racine sur Cisco ISE

Rapport CTI technique du 22 septembre 2026

Résumé exécutif

Cisco a corrigé en urgence le 16 septembre 2026 une vulnérabilité notée 10.0 sur l'échelle CVSS dans Identity Services Engine (ISE) et ISE Passive Identity Connector (ISE-PIC). CVE-2026-76460 permet à un attaquant non authentifié d'envoyer une requête forgée à l'API de gestion exposée par le composant ise-kong et d'obtenir une exécution de commande avec les privilèges root, sans avoir besoin d'identifiants ni d'interaction utilisateur. Cisco a découvert le défaut en traitant un dossier de support technique, ce qui signifie qu'au moins un client était déjà compromis avant la publication de l'avis.

ISE occupe une position centrale dans le contrôle d'accès réseau : c'est le composant qui décide quels postes et quels utilisateurs peuvent rejoindre le réseau d'entreprise, souvent en 802.1X. Une prise de contrôle root sur cette appliance donne à l'attaquant la capacité de modifier les politiques d'accès, d'exfiltrer les identifiants stockés et d'effacer ses propres traces dans les journaux. CISA a ajouté la faille à son catalogue KEV le jour même de la divulgation et a fixé au 19 septembre 2026 la date limite de correction pour les agences fédérales américaines, un délai de trois jours qui traduit la gravité perçue par l'agence.

Chronologie

Date	Événement
Avant le 16/09/2026	Cisco découvre la faille en résolvant un dossier de support client (TAC), indiquant une exploitation déjà en cours
16/09/2026	Cisco publie l'avis de sécurité et confirme l'exploitation active de CVE-2026-76460
16/09/2026	CISA ajoute CVE-2026-76460 au catalogue KEV
17-20/09/2026	Publication de guides de détection et d'indicateurs par runZero, Wiz, Bitsight et SecurityWeek
19/09/2026	Date limite de remédiation pour les agences fédérales américaines (FCEB)
22/09/2026	Rédaction du présent rapport, correctifs disponibles pour toutes les branches supportées

Fiche vulnérabilité

CVE-2026-76460 | CVSS 3.1 : 10.0 (Critique) | Cisco Identity Services Engine (ISE) et ISE-PIC, toutes configurations

La vulnérabilité provient d'un contrôle d'authentification insuffisant sur un point de terminaison de l'API de gestion exposée par ise-kong, la passerelle API REST interne qu'ISE utilise pour ses opérations d'administration. Elle est classée CWE-648 (Incorrect Use of Privileged APIs) : l'API accepte des requêtes d'administration sans vérifier correctement l'identité de l'appelant, ce qui permet à un attaquant distant non authentifié de forger une requête HTTP et d'obtenir une exécution de commande avec les privilèges root sur l'appliance.

Conditions d'exploitation : aucune authentification préalable requise, aucune interaction utilisateur nécessaire. Seule condition : l'interface de gestion d'ISE doit être joignable depuis le réseau de l'attaquant, ce qui est le cas de nombreux déploiements où l'interface d'administration n'est pas strictement cloisonnée derrière un pare-feu ou une liste de contrôle d'accès dédiée.

PoC disponible : non publiquement, à la date de rédaction. Cisco n'a communiqué aucun détail technique exploitable sur le format exact de la requête forgée, ce qui a d'ailleurs conduit les éditeurs de règles réseau (Snort, Suricata) à retirer leurs signatures faute d'artefacts spécifiques à détecter côté flux. L'absence de PoC public n'a pas empêché une exploitation réelle avant la divulgation, ce qui est la signature d'un acteur ayant développé son propre exploit en interne.

Patch/mitigation : versions corrigées 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 et 3.5 Patch 4. ISE 3.0 est en fin de support (EoL) et doit être migré vers une branche maintenue, aucun correctif n'y sera rétroporté. Il n'existe pas de contournement logiciel, mais restreindre l'accès à l'interface de gestion via des listes de contrôle d'accès d'infrastructure (iACL) empêche l'exploitation à distance en attendant le déploiement du correctif.

Diagramme de la chaîne d'attaque

Chaîne d'attaque CVE-2026-76460 sur Cisco ISE
Vue infrastructure de la chaîne d'exploitation, de la requête forgée à la prise de contrôle du plan de contrôle d'accès réseau. Sources : Cisco PSIRT, CISA KEV, Bitsight, Help Net Security.

Analyse technique

Étape 1 : reconnaissance de l'interface de gestion exposée

L'attaquant identifie une appliance Cisco ISE dont l'interface de gestion, et donc l'API ise-kong, est accessible depuis un segment réseau qu'il contrôle ou qu'il a déjà compromis. Contrairement à beaucoup de vulnérabilités d'appliances réseau qui exigent un accès VPN ou un segment interne, ise-kong est parfois exposée plus largement que prévu par les équipes réseau, notamment dans des architectures où ISE dialogue avec des équipements distants (switches, contrôleurs WLAN) sur des sites déportés.

Étape 2 : envoi de la requête forgée et contournement de l'authentification

L'attaquant construit une requête HTTP ciblant un point de terminaison privilégié de l'API ise-kong. Le défaut de contrôle d'authentification (CWE-648) permet à cette requête de passer sans que le composant ne vérifie correctement les droits de l'appelant. C'est ce mécanisme précis qui distingue cette faille d'un simple bug de logique applicative : l'API elle-même est conçue pour des opérations privilégiées, et c'est son usage incorrect côté contrôle d'accès qui ouvre la brèche.

Étape 3 : exécution de commande avec privilèges root

Une fois l'authentification contournée, l'attaquant obtient une exécution de commande directement avec les privilèges root sur le système d'exploitation sous-jacent de l'appliance, sans étape intermédiaire d'élévation de privilèges. Cisco note explicitement que cet accès permet à l'attaquant de dissimuler ou de supprimer les indicateurs de compromission, ce qui complique toute investigation post-incident menée uniquement à partir des journaux locaux de l'appliance.

Étape 4 : impact sur le plan de contrôle d'accès réseau

Avec un accès root sur ISE, l'attaquant contrôle le système qui décide de l'admission des postes sur le réseau d'entreprise. Il peut modifier les politiques d'autorisation pour s'octroyer un accès à des segments normalement cloisonnés, extraire les secrets et certificats utilisés pour l'authentification 802.1X, ou désactiver purement et simplement le contrôle d'accès réseau pour faciliter un mouvement latéral ultérieur.

Indicateurs de compromission

Type	Valeur
Artefact de log	Entrées dans ise-kong/access.log contenant l'identifiant dummyuser, cité par Cisco comme exemple non exhaustif d'entrée suspecte
Commande de vérification	show logging application ise-kong/access.log depuis le CLI d'administration
Corrélation recommandée	Croiser toute occurrence de dummyuser (ou d'un identifiant inattendu) avec les requêtes et réponses HTTP précédentes, les journaux d'opérations de gestion et les traces d'exécution de processus

Aucun hachage de fichier malveillant ni infrastructure C2 associée n'a été publié par Cisco ou par CISA à la date de rédaction. L'indicateur principal reste comportemental (log applicatif), pas un artefact statique.

MITRE ATT&CK

Tactique	Technique	ID	Justification
Accès initial	Exploit Public-Facing Application	T1190	L'attaquant exploite directement l'API de gestion exposée d'ISE sans authentification préalable
Élévation de privilèges	Exploitation for Privilege Escalation	T1068	Le contournement d'authentification débouche directement sur une exécution root, sans étape d'élévation distincte
Évasion de défense	Indicator Removal	T1070	L'accès root permet, selon Cisco, la suppression ou la dissimulation des indicateurs de compromission dans les journaux

Cette cartographie est une lecture technique construite à partir des éléments confirmés par Cisco et CISA, aucune attribution ni cartographie ATT&CK officielle n'a été publiée par un éditeur tiers à la date de rédaction.

Remédiation : checklist opérationnelle

Mettre à jour immédiatement toute instance Cisco ISE ou ISE-PIC vers 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 ou 3.5 Patch 4 selon la branche déployée.
Migrer sans délai les instances encore en version 3.0, qui n'est plus maintenue et ne recevra aucun correctif.
En attendant le déploiement du correctif, restreindre l'accès à l'interface de gestion et à l'API ise-kong via des listes de contrôle d'accès d'infrastructure (iACL), en n'autorisant que les postes d'administration légitimes.
Auditer ise-kong/access.log sur toutes les appliances exposées à la recherche d'identifiants ou de motifs de requêtes anormaux, en particulier avant l'application du correctif.
Considérer comme potentiellement compromise toute appliance ISE dont l'interface de gestion était joignable depuis un segment non cloisonné avant le 16 septembre 2026, et engager une revue des politiques d'accès réseau qu'elle pilotait.
Faire tourner les certificats et secrets utilisés pour l'authentification 802.1X sur les appliances jugées à risque, en priorité si des signes de falsification des politiques d'autorisation sont constatés.
Vérifier l'intégrité des règles de détection réseau : les signatures Snort et Suricata génériques ont été retirées faute d'artefacts de flux spécifiques, la détection repose donc principalement sur l'analyse des journaux applicatifs.