Une faille d’authentification de l’API Cisco ISE ouvre un accès distant aux privilèges root

Cisco a publié des correctifs d’urgence pour une vulnérabilité zero-day critique affectant Identity Services Engine et ISE Passive Identity Connector. La faille est déjà exploitée et les attaques réussies peuvent permettre l’exécution de commandes avec les privilèges root.

Référencée sous le numéro CVE-2026-76460, cette vulnérabilité obtient le score CVSS maximal de 10,0. Elle concerne Cisco ISE et ISE-PIC, quelle que soit la configuration des produits.

Cisco a publié son avis de sécurité à 16 h 00 GMT le 16 septembre 2026. Le même jour, la CISA a ajouté la vulnérabilité à son catalogue des vulnérabilités exploitées connues et fixé au 19 septembre 2026 la date limite de remédiation pour les agences fédérales américaines.

Il n’existe pas de mesure de contournement complète. Les administrateurs doivent installer la version corrigée appropriée et rechercher sur les appliances concernées d’éventuelles traces d’une exploitation antérieure.

Une API d’administration n’applique pas correctement l’authentification

CVE-2026-76460 existe parce qu’un endpoint d’API ISE n’applique pas des contrôles d’authentification suffisants. Cisco associe ce problème à CWE-648, qui concerne l’utilisation incorrecte d’API privilégiées.

Un attaquant distant non authentifié peut envoyer une requête spécialement conçue à une appliance vulnérable. Cette requête peut contourner les protections de l’interface d’administration web et fournir un accès non autorisé au système.

La vulnérabilité ne nécessite ni identifiants volés, ni compte existant, ni intervention d’un administrateur. Elle est également considérée comme présentant une faible complexité, ce qui signifie que son exploitation ne dépend pas de conditions de concurrence inhabituelles ni de prérequis difficiles à réunir.

Son vecteur CVSS 3.1 complet est le suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X

La modification de la portée reflète des conséquences qui s’étendent au-delà du composant initialement vulnérable. La confidentialité, l’intégrité et la disponibilité sont toutes considérées comme fortement affectées.

Cisco avertit que l’exploitation peut permettre l’exécution de commandes avec les privilèges root. À ce niveau de privilèges, un intrus peut modifier l’appliance, perturber son fonctionnement ou compromettre les éléments de preuve qui y sont stockés. L’accès root rend également l’analyse post-incident moins fiable, car un attaquant peut supprimer des journaux ou dissimuler les traces de l’intrusion.

Cisco suit cette vulnérabilité en interne sous la référence CSCww39530. Son identifiant d’avis est cisco-sa-ISE-ABP-VNSW7Tn5.

Chaque branche ISE prise en charge nécessite un correctif spécifique

Les produits vulnérables sont les suivants :

• Cisco Identity Services Engine
• Cisco ISE Passive Identity Connector

Cisco précise que l’exposition ne dépend pas de la configuration de l’équipement. Les organisations ne doivent donc pas supposer qu’un mode de déploiement inhabituel, la désactivation d’une fonctionnalité ou un autre paramètre local suffit à supprimer le risque.

La version corrigée à installer dépend de la branche logicielle utilisée :

Version installée de Cisco ISE ou ISE-PIC	Première version contenant le correctif
3.1	3.1 Patch 12
3.2	3.2 Patch 11
3.3	3.3 Patch 12
3.4	3.4 Patch 7
3.5	3.5 Patch 4

Les administrateurs qui utilisent l’une de ces branches doivent installer le correctif indiqué ou une version corrigée ultérieure disponible pour cette branche.

Cisco ISE Software Release 3.0 a atteint la fin de sa maintenance logicielle. Aucun correctif n’est répertorié pour cette version ; les organisations qui l’utilisent encore doivent donc migrer vers une version prise en charge intégrant le correctif.

L’avis de sécurité du fournisseur constitue la référence officielle pour la correspondance entre les versions et les correctifs. Les organisations disposant de déploiements distribués doivent inventorier chaque nœud, et pas seulement le système d’administration principal.

Des attaques en cours entraînent un délai de remédiation fédéral de trois jours

L’équipe Product Security Incident Response Team de Cisco a confirmé que la faille était exploitée dans la nature. L’entreprise a découvert la vulnérabilité en traitant un dossier du Cisco Technical Assistance Center, et non dans le cadre d’une évaluation interne planifiée.

Aucun acteur malveillant n’a été identifié. Cisco n’a pas établi de lien entre cette activité et une organisation criminelle, une opération soutenue par un État ou un groupe de ransomware identifié, et les informations disponibles ne précisent pas quelles cibles les attaquants visaient.

La CISA a ajouté CVE-2026-76460 à son catalogue des vulnérabilités exploitées connues le 16 septembre 2026. Les agences fédérales doivent achever la remédiation requise au plus tard le 19 septembre 2026.

L’entrée KEV impose aux agences d’appliquer les mesures d’atténuation de Cisco tout en respectant la directive BOD 26-04, « Prioritizing Security Updates Based on Risk », ainsi que les exigences de la CISA en matière de triage forensique. Les dispositions applicables de la BOD 26-04 couvrent également les services cloud. Si aucune mesure d’atténuation n’est disponible, la CISA demande aux parties concernées de cesser d’utiliser le produit.

Un triage forensique est expressément requis. On ignore encore si la vulnérabilité est utilisée dans des campagnes de ransomware.

Le délai très court reflète une exploitation observée et non une possibilité d’attaque purement théorique. Les responsables des actifs doivent également déterminer si chaque appliance est exposée à Internet ou accessible depuis des réseaux à partir desquels un attaquant pourrait envoyer des requêtes à son plan d’administration.

Les iACL peuvent réduire l’exposition, mais pas corriger la faille

Cisco n’a identifié aucune mesure de contournement permettant de traiter complètement CVE-2026-76460. L’installation d’une version corrigée constitue la seule mesure de remédiation indiquée.

Pendant le déploiement des correctifs, les administrateurs peuvent mettre en place des listes de contrôle d’accès à l’infrastructure, ou iACL, afin de limiter le trafic à destination de l’appliance concernée. Ces contrôles doivent autoriser uniquement les connexions nécessaires d’administration et de plan de contrôle provenant de systèmes et de réseaux explicitement autorisés.

Cette mesure peut réduire les chemins accessibles à un attaquant distant, notamment lorsque les services d’administration étaient largement accessibles. Elle ne corrige toutefois pas la logique d’authentification défaillante de l’endpoint d’API.

La priorité doit être donnée aux systèmes exposés à Internet et aux appliances accessibles depuis des segments réseau moins fiables. Toutefois, le seul fait qu’un équipement soit déployé sur un réseau interne ne suffit pas à garantir sa sécurité. Un poste de travail, un serveur ou un compte d’accès distant compromis peut fournir à un attaquant la position réseau nécessaire pour atteindre une interface d’administration insuffisamment restreinte.

Les restrictions réseau doivent rester en place après l’installation du correctif lorsque les contraintes opérationnelles le permettent. Elles constituent une limite supplémentaire autour d’un service d’infrastructure doté de privilèges élevés, mais ne doivent pas être considérées comme un substitut à la mise à jour logicielle.

Les défenseurs doivent examiner les journaux de chaque nœud

Cisco recommande d’examiner les données d’access.log à la recherche de noms d’utilisateur et d’activités d’API suspects. Dans un déploiement ISE distribué, les enquêteurs doivent examiner chaque nœud, car les entrées pertinentes peuvent ne pas apparaître sur le système principal ou central.

Cisco fournit l’exemple suivant pour rechercher des éléments dans le journal de la passerelle d’API :

admin#show logging application ise-kong/access.log | include dummyuser

La valeur dummyuser est fournie à titre d’exemple et ne constitue pas à elle seule un indicateur de compromission complet. Une correspondance peut signaler une activité malveillante, mais les enquêteurs doivent la confronter aux requêtes environnantes, aux adresses source, aux horodatages et au comportement administratif attendu. Ils doivent également rechercher d’autres noms d’utilisateur anormaux et ne pas se limiter à cette seule valeur.

D’autres journaux de la passerelle d’API peuvent être obtenus en collectant un support bundle incluant les journaux de débogage. Cisco recommande de protéger le bundle avec un chiffrement à clé partagée, de le déchiffrer dans l’environnement d’investigation, puis d’examiner les fichiers situés sous :

./ise/logs/apigateway/access.log..gz

Les éléments de preuve locaux peuvent être incomplets. Comme la faille peut potentiellement permettre l’exécution de commandes avec les privilèges root, un attaquant parvenu à ses fins pourrait modifier les journaux, supprimer des fichiers ou dissimuler son activité sur l’appliance.

Les enquêteurs doivent corréler les enregistrements ISE avec les données de télémétrie conservées ailleurs, notamment les événements des pare-feu et les données de flux réseau. Ils doivent rechercher des téléversements sortants inexpliqués depuis un nœud ISE, des téléchargements impliquant des adresses externes suspectes, ainsi que des connexions entrantes ou sortantes inhabituelles associées au déploiement.

En cas de suspicion de compromission, Cisco recommande vivement de réinstaller les nœuds concernés à partir d’une image et de les restaurer depuis des sauvegardes de configuration lorsque cela est nécessaire. L’installation du correctif ne suffit pas à supprimer une persistance ou des modifications non autorisées qu’un attaquant aurait déjà introduites.

Installer le correctif en priorité, puis déterminer si un accès a déjà eu lieu

La réponse immédiate doit suivre deux axes en parallèle : fermer le chemin d’accès vulnérable à l’API et déterminer si des attaquants l’ont emprunté avant la remédiation.

Les administrateurs doivent identifier chaque nœud ISE et ISE-PIC, vérifier sa version exacte, installer le correctif correspondant et restreindre le trafic d’administration à l’aide d’iACL jusqu’à la fin du déploiement. Les systèmes en version 3.0 nécessitent une migration, et non l’installation d’un correctif classique.

Ils doivent ensuite préserver et examiner les journaux disponibles, recueillir les éléments de preuve réseau externes et considérer toute activité inexpliquée sur le plan d’administration comme un incident potentiel. Lorsque les indicateurs laissent penser qu’une exploitation a réussi, une réinstallation à partir d’une image est plus sûre que de faire confiance à l’intégrité d’un système qui a pu être contrôlé avec les privilèges root.