Une faille CVSS 9.8 ouvre un shell root à distance sur dix commutateurs Cisco Nexus 9000
Cisco a divulgué le 2 septembre 2026 une vulnérabilité CVSS 9.8 (CVE-2026-20212) qui expose les ports TCP 43210 et 43211 de dix commutateurs Nexus 9000 à une exécution de code à distance en root, sans authentification. Appliquez sans attendre un iACL sur ces deux ports et le shield Live Protect lp00031, puis vérifiez votre version dans le Software Checker.
2 septembre 2026. Cisco divulgue CVE-2026-20212, une vulnérabilité CVSS 9.8 qui touche dix commutateurs Nexus 9000 à base de Silicon One. Ports TCP 43210 et 43211. Un attaquant non authentifié qui atteint l’un de ces deux ports exécute du code en root sur le commutateur. Pourquoi c’est important : ces ports sont joignables par défaut dans le VRF de couche 3, et Cisco ne publie pas de tableau de versions corrigées — la parade passe par un iACL, un shield provisoire et le Software Checker.
Deux ports ouverts par défaut dans le VRF de couche 3
La cause racine tient en une phrase : le service incriminé se lie à une adresse IP non restreinte. Résultat, les ports TCP 43210 et 43211 restent joignables dans l’instance VRF de couche 3 par défaut du commutateur. Un attaquant capable d’atteindre l’adresse du switch sur l’un de ces ports se connecte directement au service ; une entrée spécialement forgée est alors exécutée comme du code avec les privilèges root.
La portée est double. Au-delà de l’exécution de code, une tentative d’exploitation peut faire planter le processus S1HAL et recharger l’équipement — autrement dit, même un exploit mal calibré se transforme en déni de service sur un plan de données en production. Cisco précise n’avoir connaissance d’aucune exploitation à la date de la divulgation, le 2 septembre 2026.
La liste des produits concernés est précise, et vérifiable via la commande show module. Sont touchés les Nexus Smart Switch N9324C-SE1U et N9348Y2C6D-SE1U, les boîtiers N9364E-SG2-O, N9364E-SG2-Q, N9396T12C-SE1, N9348Y12C-SE1, N9396Y12C-SE1, N9336C-SE1, ainsi que les chassis N9K-C9804 et N9K-C9808. Les autres modèles Nexus 9000, les fabrics en mode ACI, et les gammes Nexus 3000 et 7000 ne sont pas affectés.
Le périmètre logiciel est large. The Hacker News a confirmé le 3 septembre via le registre du programme CVE que Cisco liste 45 versions NX-OS comme affectées, de 10.3(1) à 10.6(3s) — une plage que l’avis renvoie elle-même au Software Checker.
Comment savoir si vous êtes exposé
Le premier réflexe est d’identifier les équipements concernés. La commande show module donne le PID de chaque carte et permet de croiser immédiatement avec la liste des dix identifiants affectés — les Smart Switches, les boîtiers N9364E/N9396, et les chassis 9804/9808.
La seconde question est la plus dérangeante : vos ports 43210 et 43211 sont-ils joignables ? Ils le sont par défaut dans le VRF de couche 3, ce qui veut dire qu’un plan de gestion correctement segmenté peut ne pas suffire. Si le trafic vers l’adresse du switch sur ces ports n’est pas filtré en amont, l’équipement est exposé à tout ce qui route vers lui — y compris, dans les déploiements mal segmentés, des réseaux invités ou des sous-réseaux tiers.
La vérification est simple et mérite d’être scriptée : un scan ciblé des deux ports sur chaque commutateur concerné, ou une revue des ACL de bordure. Mieux vaut un faux positif qu’un switch de production qui répond sur un port qu’on croyait fermé.
Un correctif sans tableau de versions : iACL et shield en attendant
Le point qui complique la réponse est là : Cisco n’a pas publié de tableau de versions corrigées. Les équipes réseau doivent donc vérifier leur release dans le Software Checker, et, en attendant, appliquer les deux parades documentées.
La première est un iACL (infrastructure access control list) qui n’autorise que le trafic de gestion et de contrôle, ou qui refuse explicitement les paquets TCP à destination des ports 43210 et 43211. Cisco insiste : la règle doit être validée en environnement de test avant d’atterrir en production — un iACL mal écrit sur le plan de contrôle d’un switch de datacenter coupe la gestion à distance.
# Exemple minimal d'iACL à valider en laboratoire : ne laisser passer
# que la gestion/contrôle, puis refuser les deux ports vulnérables.
ip access-list extended BLOCK-VULN-PORTS
permit tcp any any established
deny tcp any any eq 43210
deny tcp any any eq 43211La seconde est le shield Live Protect lp00031, un correctif de contournement temporaire. Il n’est supporté que sur NX-OS 10.6(3) et, via un second paquet, sur 10.6(3s) pour les deux Smart Switches — mais pas sur les Nexus 9804 et 9808. Son déploiement exige un accès SSH, Telnet ou NX-API. À noter : le passage à NX-OS 10.6(4) ou plus récent fait passer le shield en mode N/A, signe qu’un correctif définitif est attendu dans ces trains.
Le même jour, un hardening IOS XR qui culmine à deux 9.8
La publication du 2 septembre ne s’arrête pas au Nexus 9000. Cisco a livré en parallèle une release de durcissement IOS XR qui regroupe sept CVE « parapluie », dont deux au plafond de 9.8.
Le modèle de divulgation est désormais assumé : chaque CWE (catégorie de faiblesse) reçoit une CVE, notée au défaut le plus sévère du lot. CVE-2026-20274 couvre les bugs de sécurité mémoire et de durée de vie des ressources ; CVE-2026-20279 couvre le contrôle d’accès, dont l’absence d’authentification sur des fonctions critiques et une validation de certificat incorrecte. Les cinq autres plafonnent entre 8.2 et 8.8. Les failles touchent toutes les versions, quelle que soit la configuration.
La remédiation passe par des SMU (software maintenance updates) plutôt que par une montée de version complète. Cisco évoque « environ 16 SMU par release », et annonce que 26.2.2 et 26.3.1 seront les premières releases corrigées sans SMU. Les plateformes XR7 (LNT) — Cisco 8000, NCS 1010, NCS 540L, NCS 5700 — disposent d’un SMU dédié. Sur les 111 releases IOS XR listées comme affectées, 14 ont un SMU disponible immédiatement, 4 l’attendent, et 93 doivent d’abord être upgradées.
Le contexte rend ce lot plus lourd à porter. Six jours plus tôt, Sygnia documentait Fire Ant, un acteur lié à la Chine qui faisait tourner des implants sur des routeurs IOS XR : suppression des envois syslog, filtrage des sorties show, et un tunnel GRE caché pour exfiltrer le trafic. L’enquête avait démarré sur un détail — une interface tunnel active sans configuration ni historique de commit pour l’expliquer.
La même journée de publication comportait encore deux avis mineurs, à connaître sans urgence. Cisco a corrigé une paire de failles de déchiffrement S/MIME dans Secure Email — CVE-2026-20354 et CVE-2026-20355 (CVSS 5.9) — qui permettent à un attaquant en position machine-in-the-middle de récupérer le texte clair entre des passerelles tournant sous AsyncOS 16.5.0 ou antérieur. Un troisième avis corrige un déni de service téléphonique, CVE-2026-20281 (CVSS 7.5), sur les Desk Phone 9800, IP Phone 7800/8800 et Video Phone 8875 enregistrés sur Unified Communications Manager avec l’accès web activé — désactivé par défaut. Ces deux rappels confirment que la publication bimensuelle de Cisco brasse désormais des volumes que les équipes doivent trier par priorité réelle, pas par ordre d’arrivée.
Verdict
Si vous exploitez des Nexus 9000 Silicon One — Smart Switch, 9804 ou 9808 — appliquez dès maintenant l’iACL sur les ports 43210/43211, déployez le shield lp00031 là où il est supporté, et vérifiez votre train NX-OS dans le Software Checker. Le risque est réel : un RCE root non authentifié sur le plan de contrôle d’un commutateur de datacenter, c’est la porte d’entrée d’un pivot vers tout le réseau.
Si vous êtes sur IOS XR, le travail est plus ingrat : recensez vos releases, croisez-les avec les SMU disponibles, et priorisez CVE-2026-20274 et CVE-2026-20279 (9.8) avant les cinq autres. N’attendez pas la release corrigée si un SMU existe.
Dans les deux cas, traitez le plan de gestion comme une surface d’attaque à part entière : l’affaire Fire Ant rappelle qu’un routeur dont l’état opérationnel ne correspond plus à sa configuration ne peut plus être audité de confiance.