L’essentiel
La mise à jour NX-OS d’octobre 2026 de Cisco corrige des failles critiques permettant à un attaquant d’obtenir les droits root sur les commutateurs de datacenter Nexus, les commutateurs de stockage MDS et les fabric interconnects UCS. La faille NX-API, CVE-2026-76471, est notée CVSS 9,8 et ne demande aucun identifiant si l’API est activée. Cisco a aussi regroupé des dizaines de bugs trouvés en interne en six CVE, dont deux notées 9,8. Aucune exploitation connue, aucun contournement.
Pour les équipes logicielles, le piège est l’automatisation. NX-API est désactivée par défaut, mais on l’active souvent pour que les pipelines configurent le réseau « as code ». Si vos outils cloud et DevOps poussent des VLAN, des routes ou des changements de fabric vers des Nexus, c’est cette interface qu’il faut patcher en premier.
Qu’a publié Cisco ?
Le 7 octobre 2026, Cisco a publié deux types d’avis NX-OS. Le premier est classique : CVE-2026-76471, un dépassement de tas dans NX-API, l’interface HTTP et JSON-RPC qui permet aux scripts et contrôleurs de piloter un commutateur. Une seule requête forgée vers une NX-API exposée peut exécuter du code en root. Sur les fabric interconnects UCS 6300, la même faille est atteignable via l’API XML d’UCS Manager, mais uniquement avec des identifiants valides à faibles privilèges.
Le second est nouveau dans sa forme. Cisco parle de « software hardening release » : une revue interne a mis au jour de nombreuses vulnérabilités et, au lieu d’un avis par bug, Cisco les a regroupées par classe de faiblesse, avec une CVE par classe. Le score de chaque CVE reflète le pire bug qu’elle contient. Selon Cisco, les problèmes ont été trouvés avec ses processus de test existants « ainsi qu’avec des modèles d’IA de pointe ». BleepingComputer et SecurityWeek signalent aussi des failles critiques distinctes dans les fonctions Next Generation OAM et MPLS OAM, ainsi que des bugs critiques dans le gestionnaire de licences Cisco sur site.
Quels commutateurs et fabrics sont exposés ?
La version de durcissement couvre les commutateurs de stockage MDS 9000, les Nexus 3000 et 7000, les Nexus 9000 en mode autonome comme en mode ACI, les fabric interconnects UCS 6300 à 6600 et l’UCS X-Series Direct 9108 100G, quelle que soit leur configuration. En pratique, cela concerne la plupart des datacenters sur site et des baies en colocation équipés de matériel Cisco, y compris la fabric qui porte les clusters VMware, Kubernetes et de stockage.
Le risque immédiat le plus élevé se situe là où une fonction élargit la surface d’attaque : NX-API joignable depuis un réseau de serveurs ou d’automatisation, NGOAM utilisé avec des overlays SRv6 ou VXLAN, ou MPLS OAM. Les versions corrigées sont listées par plateforme dans l’avis de Cisco ; les branches anciennes comme NX-OS 9.3 sur MDS et 8.3 sur Nexus 7000 n’ont pas de correctif et doivent migrer vers une version supportée.
Ce que cela change pour les équipes logicielles aux États-Unis et en Europe
D’abord, le « network as code » a fait de l’API d’administration une partie de votre surface d’attaque. Des outils comme Ansible et les providers Terraform pour NX-OS dialoguent avec les commutateurs via NX-API : l’API est donc activée sur tout le parc et ouverte aux runners CI et aux bastions. Un bug root sans authentification sur ce chemin signifie qu’un agent de build compromis ou un VLAN d’administration à plat peut mener au contrôle de la fabric du datacenter. Limitez NX-API à des adresses d’administration dédiées et traitez les identifiants et runners d’automatisation comme des actifs de niveau zéro.
Ensuite, la chasse aux bugs assistée par IA change la nature des journées de patch. Une CVE représente désormais une classe de bugs, pas un défaut unique. Les tableaux de bord qui comptent les CVE ou comparent des signatures d’exploit sous-estimeront le travail. Cisco prévoit des versions de durcissement similaires pour IOS XE, IOS XR, ASA et Secure Firewall, avec des avis programmés les premier et troisième mercredis de chaque mois. Calez des fenêtres de changement régulières sur ce calendrier plutôt que de réagir à chaque lot.
Enfin, l’absence de contournement impose une vraie planification des interruptions. La mise à jour des commutateurs et des fabric interconnects coupe le trafic si l’architecture n’est pas redondante. Pour les entités financières de l’UE soumises à DORA et les entités essentielles relevant de NIS2, la capacité à corriger rapidement une infrastructure critique fait partie des questions des superviseurs. Gardez trace de ce qui était vulnérable, de la date de correction et des raisons de tout report.
Qu’est-ce que cela change pour les datacenters en France ?
En France, une grande partie des fabrics Nexus d’entreprise tourne en colocation dans les grands pôles d’hébergement, en Île-de-France et autour de Marseille, où les fenêtres de maintenance se négocient avec l’hébergeur. Les DSI qui pilotent ces équipements par Ansible ou Terraform ont intérêt à caler dès maintenant la mise à jour avec leur prestataire plutôt que d’attendre la prochaine fenêtre trimestrielle. Les avis du CERT-FR méritent d’être branchés sur le même canal d’alerte que les avis Cisco, avec un inventaire qui permet de savoir en quelques minutes quels équipements tournent sur une version vulnérable.
Pour les opérateurs d’importance vitale et les opérateurs de services essentiels, dont les systèmes sont encadrés par l’ANSSI, une faille root sans authentification sur le cœur de réseau du datacenter est typiquement le genre de vulnérabilité dont le traitement doit pouvoir être justifié ; la transposition de NIS2 élargit encore le nombre d’entreprises concernées. Côté banque et assurance, DORA ajoute l’exigence de documenter la gestion de ce risque TIC. Un journal des versions avant et après mise à jour, horodaté par équipement, constitue la preuve la plus simple à produire.
Que faire dès maintenant ?
- Inventorier le parc. Recenser chaque Nexus, MDS et fabric interconnect UCS avec sa version NX-OS ou UCS, y compris les équipements de labo, de PRA et en colocation qu’on oublie souvent.
- Repérer NX-API, NGOAM et MPLS OAM. Vérifier sur quels équipements ces fonctions sont activées et qui les utilise. Désactiver tout ce dont aucun pipeline ni contrôleur n’a réellement besoin.
- Réduire l’exposition. Limiter NX-API aux interfaces d’administration et à des adresses sources précises par listes de contrôle d’accès, et renouveler les identifiants utilisés par l’automatisation. N’utiliser le bouclier Live Protect que comme solution transitoire.
- Mettre à jour par vagues. Commencer par les équipements qui exposent NX-API, puis le reste du parc. Tester d’abord la version cible dans le pipeline d’automatisation, car modules et providers peuvent se comporter différemment après une mise à jour majeure de NX-OS.
- Conserver les preuves. Archiver les versions avant et après, les tickets de changement et la date de correction de chaque équipement, pour les audits et les questions ultérieures des autorités, ANSSI ou superviseur financier.
Questions fréquentes
Qu’est-ce que CVE-2026-76471 ?
C’est un dépassement de tas dans la fonction NX-API de Cisco NX-OS, noté CVSS 9,8. Un attaquant distant non authentifié peut envoyer une requête HTTP forgée à une NX-API activée sur un commutateur Nexus 3000 ou Nexus 9000 en mode autonome et exécuter du code en root. Sur les fabric interconnects UCS 6300, la faille est atteignable via l’API XML d’UCS Manager mais exige des identifiants valides à faibles privilèges.
NX-API est-elle activée sur mes commutateurs Nexus ?
NX-API est désactivée par défaut sur les Nexus 3000 et 9000. Elle est souvent activée pour que les outils d’automatisation, les contrôleurs et les scripts gèrent le commutateur en HTTP ou HTTPS. La commande « show feature | include nxapi » indique sur chaque équipement si elle est active.
Qu’est-ce que la version de durcissement Cisco NX-OS ?
C’est un nouveau type d’avis Cisco publié le 7 octobre 2026. Cisco a passé NX-OS en revue en interne, avec ses tests existants et des modèles d’IA de pointe, et a regroupé les vulnérabilités trouvées en six CVE par classe de faiblesse. Chaque CVE porte le score du pire bug de sa classe ; CVE-2026-76455 et CVE-2026-76459 sont notées 9,8. Elle s’applique aux versions concernées quelle que soit la configuration.
Les vulnérabilités Cisco NX-OS sont-elles exploitées ?
Cisco indique n’avoir connaissance d’aucun exploit public ni d’usage malveillant à la date de ses avis d’octobre 2026. Il n’existe pas de contournement : la mise à jour vers une version corrigée est la seule solution complète. Cisco a publié un bouclier temporaire Live Protect pour la faille NX-API.
Quelles versions de NX-OS corrigent les vulnérabilités ?
Pour les Nexus 3000 et Nexus 9000 en mode NX-OS autonome, la version de durcissement cite 10.3(10), 10.4(8), 10.5(6) et 10.6(4) comme premières versions corrigées. MDS 9000, Nexus 7000, Nexus 9000 en mode ACI et fabric interconnects UCS ont leurs propres versions corrigées dans l’avis de Cisco, et certaines branches anciennes doivent migrer vers une version supportée.
Sources
Cisco — Cisco NX-OS Software Security Hardening Release: October 2026
Cisco — Cisco NX-OS Software NX-API Remote Code Execution Vulnerability (CVE-2026-76471)
Cisco — Transition to a Risk-Based Vulnerability Disclosure Model
BleepingComputer — Cisco warns of critical flaws allowing Nexus switch takeover
SecurityWeek — Cisco Patches a Dozen Critical Vulnerabilities