Cisco corrige cinq failles critiques dans NX-OS qui donnent la racine sur les switches Nexus 3000 et 9000
Le 7 octobre 2026, Cisco publie cinq correctifs critiques pour NX-OS, le système des switches Nexus 3000 et 9000 : une requête forgée peut exécuter du code avec les droits root, sinon planter le processus et forcer un redémarrage. Vérifiez si NX-API, NGOAM ou MPLS OAM est activé sur vos équipements, puis patchez ou désactivez ces fonctions.
7 octobre 2026. Cisco publie cinq correctifs critiques pour NX-OS, le système d’exploitation de ses switches de datacenter Nexus. CVE-2026-76471. C’est le numéro de la première, une exécution de code à distance via l’API du switch. Root. C’est le niveau de privilège obtenu par un attaquant qui exploite l’une de ces failles, sinon il fait planter le processus et force le relancement de l’équipement. Pourquoi c’est important : les Nexus 3000 et 9000 transportent le cœur de réseau de milliers d’entreprises, et ces cinq failles touchent des fonctions de gestion et d’overlay que beaucoup d’équipes laissent activées sans y penser.
Cinq failles, un même défaut de validation
Les cinq vulnérabilités partagent une racine commune : un défaut de validation des entrées. Cisco le dit sans détour dans ses avis — il s’agit d’une validation insuffisante qui, selon la faille, s’exploite par une requête HTTP forgée ou par des paquets IP fabriqués. Le dénominateur commun, c’est qu’un attaquant non authentifié peut atteindre le code vulnérable dès qu’il peut joindre le switch.
L’exécution de code à distance n’est pas le seul scénario. Si la RCE n’aboutit pas, l’attaquant peut au minimum faire planter le processus concerné et forcer le périphérique à se recharger, ce qui équivaut à un déni de service sur un équipement qui porte le trafic. Sur un switch d’agrégation ou de cœur, un rechargement non planifié n’est pas un incident bénin : c’est une coupure.
Les cinq failles se répartissent en trois groupes, selon la fonction qu’elles ciblent.
- NX-API. La CVE-2026-76471 s’exploite par une requête HTTP forgée envoyée à l’API de gestion du switch. C’est la porte d’entrée la plus directe, mais la fonction est désactivée par défaut.
- NGOAM. Les CVE-2026-76485, CVE-2026-76486 et CVE-2026-76501 visent le Next Generation OAM, l’outil d’opérations, d’administration et de maintenance. Elles s’exploitent par des paquets IP fabriqués envoyés à une interface, à condition que NGOAM soit activé. La CVE-2026-76486 exige en plus le Segment Routing over IPv6 (SRv6) ou l’overlay NV actif, et la CVE-2026-76501 exige SRv6, disponible seulement sur certains modèles de Nexus 9000.
- MPLS OAM. La CVE-2026-76465 s’exploite par une requête MPLS echo-request forgée adressée à l’IP de l’équipement. La fonction est désactivée par défaut, et les Nexus 9000 équipés d’ASIC Silicon One ne la supportent pas — ils ne sont donc pas concernés par cette faille précise.
Ce découpage n’est pas un détail technique : il détermine qui est réellement exposé.
Le risque réel tient aux fonctions activées
La question que doit se poser chaque équipe réseau tient en une phrase : quelles fonctions tournent sur mes switches ? NX-API, NGOAM et MPLS OAM ne sont pas activées partout, et c’est la clé du périmètre réel.
NX-API est la porte des automatisations — les scripts Ansible, les collectes de télémétrie, les intégrations CI/CD qui pilotent le réseau. Dès qu’une équipe automatise la configuration de ses Nexus, elle a de bonnes chances d’avoir ouvert NX-API, souvent sur une adresse de gestion joignable depuis le réseau d’administration. C’est précisément la surface qu’aime un attaquant en mouvement latéral.
NGOAM et MPLS OAM relèvent d’un autre registre : l’exploitation et le diagnostic des overlays. NGOAM est activé dans les déploiements qui surveillent la continuité des tunnels et des chemins, et MPLS OAM dans les réseaux MPLS qui ont besoin de tester leurs LSP. Ces fonctions sont moins systématiques, mais elles sont précisément présentes là où le réseau est le plus critique — les cœurs MPLS et les architectures EVPN/VXLAN.
La conséquence opérationnelle est nette. Un switch qui n’active aucune de ces trois fonctions n’est pas directement exploitable par ces failles, même s’il reste vulnérable sur le papier. Un switch qui les active en cumule la surface.
Nexus 7000 et mode ACI épargnés
Le périmètre matériel mérite d’être noté avec précision. Les vulnérabilités touchent les Nexus 3000 et Nexus 9000 fonctionnant en mode NX-OS autonome. Deux familles sont explicitement non concernées : les Nexus 7000, et les Nexus 9000 exploités en mode ACI.
Cette distinction compte. Beaucoup de datacenters font tourner leurs Nexus 9000 en mode ACI, l’architecture pilotée par contrôleur de Cisco. Dans ce mode, la surface de gestion est différente, et ces cinq failles ne s’appliquent pas. Une équipe qui gère un parc en ACI doit le savoir avant de déclencher une alerte générale.
Pour les autres, le tri est simple : inventorier les switches en mode NX-OS autonome, puis déterminer quelles fonctions sont activées sur chacun.
Les parades : désactiver, protéger, patcher
Cisco fournit trois niveaux de réponse, et ils ne se substituent pas l’un à l’autre.
D’abord, réduire la surface. L’éditeur recommande de désactiver NX-API, NGOAM et MPLS OAM si ces fonctions ne sont pas utilisées. C’est la mesure la plus immédiate et la plus efficace : sans la fonction active, le vecteur d’attaque disparaît, même sans correctif.
Ensuite, le bouclier Live Protect. Cisco propose des shields Live Protect pour les cinq failles — un mécanisme de protection destiné aux switches qui ne peuvent pas encore être mis à jour et redémarrés. C’est une parade temporaire, pas une destination : un switch sous Live Protect reste vulnérable sur le papier et doit finir par être patché.
Enfin, la mise à jour. Cisco renvoie vers son outil Software Checker pour identifier la version corrigée de NX-OS de chaque branche. C’est la seule sortie durable, et elle impose un redémarrage de l’équipement — d’où l’intérêt du Live Protect pour les fenêtres de maintenance lointaines.
L’origine des failles rassure et inquiète à la fois. Elles ont toutes été découvertes lors des tests de sécurité internes de Cisco, et l’éditeur affirme n’avoir connaissance d’aucune annonce publique ni exploitation au moment de la publication. C’est la bonne nouvelle : pas de zero-day actif à ce stade. Mais l’histoire récente de Cisco enseigne qu’un avis sans exploitation connue peut se transformer en urgence en quelques jours.
Cisco License : quatre failles de plus, dont un CVSS 10.0
Dans le même lot d’avis, Cisco durcit Cisco License, l’ex-Smart Software Manager, avec quatre vulnérabilités qui méritent d’être traitées à part.
- CVE-2026-76480 — une absence d’authentification sur des fonctions critiques, notée CVSS 9.8.
- CVE-2026-76482 — une vérification de signature cryptographique incorrecte, notée CVSS 10.0, le maximum de l’échelle.
- CVE-2026-76483 — des identifiants insuffisamment protégés, notée CVSS 9.1.
- CVE-2026-76484 — une injection de code, notée CVSS 8.8.
Le point dur est là : ces quatre failles affectent les versions quel que soit leur réglage, et Cisco demande de migrer vers la version 10-202609. Les anciennes versions commercialisées sous le nom Smart Software Manager ne recevront pas de correctif — l’éditeur recommande de migrer vers une version supportée. Pour les équipes qui exploitent encore un Smart Software Manager historique, c’est une échéance ferme, pas un simple rappel.
Verdict
Si vos Nexus 3000 ou 9000 tournent en mode NX-OS autonome avec NX-API, NGOAM ou MPLS OAM activé, traitez ces cinq correctifs comme une priorité de la semaine : une requête forgée peut donner la racine sur un équipement qui porte votre trafic, et désactiver les fonctions inutiles neutralise le risque dès aujourd’hui, avant même la mise à jour. Si vous gérez votre parc en mode ACI ou sur Nexus 7000, vous n’êtes pas concerné par ces failles précises, mais profitez-en pour vérifier l’état des avis Cisco qui touchent vos gammes. Dans tous les cas, si vous exploitez encore un Smart Software Manager historique, planifiez la migration vers 10-202609 — il n’y aura pas de correctif pour les anciennes versions, et un CVSS 10.0 sans patch est une bombe à retardement, pas un risque théorique.