Cisco a publié des correctifs pour une vulnérabilité critique classée comme zero-day sur sa plateforme Catalyst SD-WAN, identifiée sous le numéro CVE-2026-20127 et évaluée à un score CVSS 10,0. Cette faille concerne le plan de gestion et de contrôle — le « cerveau » d’un maillage SD-WAN — et, d’après les informations communiquées par Cisco Talos et d’autres organismes de cybersécurité, aurait été exploité activement depuis 2023. La conséquence pratique est grave : un attaquant à distance, sans besoin de crédentiels, pourrait contourner l’authentification et prendre le contrôle avec des privilèges administratifs sur des composants clés du déploiement.

Ce qui accentue le risque est double. D’une part, il ne s’agit pas d’un équipement périphérique, mais de composants qui orchestrent politiques, routes et comportement global du réseau. D’autre part, Cisco et les organismes d’interventions en sécurité signalent qu’il n’existe pas de mitigation alternative (« workaround») permettant de temporiser une fois la vulnérabilité identifiée. La solution prioritaire est une mise à jour immédiate.

Quels produits sont affectés et pourquoi ce risque est si sérieux

La vulnérabilité concerne Cisco Catalyst SD-WAN Controller (anciennement vSmart) et Cisco Catalyst SD-WAN Manager (ex vManage), les éléments qui pilotent la topologie et le contrôle du SD-WAN. La description technique fournie par le NVD est claire : le problème réside dans la gestion de l’authentification de peering, ce qui permet à un acteur distant non authentifié de la contourner et d’obtenir des privilèges administratifs.

Concrètement, cela peut mener à un scénario particulièrement dangereux : accès au plan de contrôle et de gestion, avec la possibilité de modifier les configurations impactant tout le maillage (politiques, routes, ajout ou suppression de nœuds, paramètres de connectivité). Des analyses et rapports techniques mentionnent la possibilité d’interagir avec des interfaces de gestion comme NETCONF (habituellement sur le port 830) pour manipuler l’infrastructure depuis l’intérieur, une fois la première barrière franchie.

Une exploitation « silencieuse » attribuée à UAT-8616

Les équipes de Cisco Talos indiquent suivre cette activité complication, baptisée campagne UAT-8616, en affirmant avoir détecté des preuves que cette exploitation remonte au moins trois ans, dès 2023. L’analyse décrit un modus operandi classique de compromission d’infrastructure réseau : après l’accès initial, le cybercriminel cherche à assurer sa persistance, à faire du mouvement latéral et à cacher ses traces, en tentant de se faire passer pour un acteur légitime du système.

Parmi les signaux et tactiques décrits dans des guides d’enquête ou d’analyse d’incidents, certains doivent alerter tout SOC ou équipe réseau :

• Événements de peering suspects (connexions de contrôle qui paraissent légitimes mais ont lieu à des horaires inhabituels, depuis des IP inconnues ou avec des relations de peering anormales).
• Création de comptes locaux imitant des noms officiels ou habituels.
• Insertion de clés SSH (notamment dans authorized_keys) pour des comptes privilégiés.
• Modification de scripts de démarrage ou autres ajustements visant à maintenir la persistance.
• Nettoyage ou modification des logs, avec fichiers anormalement petits ou logs incomplets.

L’objectif de l’attaquant est clair : dans un contexte SD-WAN, le plan central est la pièce maîtresse. En le compromettant, il obtient une visibilité et un contrôle étendus, avec un impact potentiel sur tout le réseau, sans avoir besoin de cibler chaque périphérique individuellement.

Union avec CVE-2022-20775 : une escalade privilégiée via downgrade

Une des préoccupations majeures est la possibilité de coupler cette faille avec une vulnérabilité plus ancienne : CVE-2022-20775, qui touche la Ligne de commande (CLI) du logiciel Cisco SD-WAN et autorise l’exécution de commandes avec des privilèges élevés dans certaines conditions. Selon Talos et les guides d’exploitation, l’attaquant pourrait avoir utilisé le mécanisme de mise à jour intégré pour faire un downgrade vers une version vulnérable, exploiter cette vulnérabilité pour escalader ses privilèges (y compris obtenir un accès root dans certains cas) puis restaurer la version d’origine, rendant très difficile la détection et l’analyse post-incident.

Ce type de méthode n’est pas seulement innovant, c’est une illustration d’une opération mûrie : l’objectif n’est pas uniquement de pénétrer, mais d’étendre son contrôle tout en minimisant sa trace.

Actions immédiates : priorité à l’actualisation et à la segmentation

Les alertes publiques indiquent clairement que la meilleure réaction consiste à mettre à jour ou migrer vers des versions corrigées. Selon l’avis d’INCIBE-CERT, publié le 26/02/2026, l’accent doit être mis sur certaines branches et versions :

• Pour la branche 20.9, la mise à jour vers 20.9.8.2 (sortie prévue le 27/02/2026).
• Pour 20.11, migration vers 20.12.6.1.
• Pour 20.12.5 et 20.12.6, passage à 20.12.5.3 et 20.12.6.1.
• Pour 20.13 / 20.14 / 20.15, migration vers 20.15.4.2.
• Pour 20.16 / 20.18, mise à jour à 20.18.2.1.
• Pour les versions antérieures à 20.9, il est conseillé de migrer vers une version supportée et corrigée.

Par ailleurs, Talos insiste particulièrement sur la nécessité d’auditer tout accès administratif ou de peering exposé à Internet, notamment pour les contrôleurs et gestionnaires directement en ligne.

Reconnaissance précoce : que vérifier avant qu’il ne soit trop tard

Face à ce type d’incident, la question clé n’est pas seulement « suis-je à jour ? », mais « est-ce que je suis déjà touché ? ». Les guides techniques conseillent de commencer par examiner ce que tout attaquant cherche en priorité : l’accès initial.

• Analyser les logs de connexions de peering / contrôle pour repérer tout événement anormal, provenant d’IP inconnues ou à des heures non programmées.
• Surveiller toute activité SSH suspecte, notamment la présence de clés non autorisées pour des comptes critiques.
• Vérifier les signes d’un downgrade ou d’un upgrade non autorisé, accompagnés de redémarrages inattendus.
• Se montrer extrêmement prudent face à toute preuve de borrage de traces (logs tronqués, fichiers absents ou modifiés).

Ce scénario réitère une tendance observée en 2026 : les dispositifs en périphérie et en contrôle (SD-WAN, VPN, pare-feu, gateways) sont devenus des cibles prioritaires. Non pour « casser » le réseau, mais pour y rester infiltré durablement.

Questions fréquemment posées

Qu’est-ce que le CVE-2026-20127 et pourquoi est-il critique pour Cisco Catalyst SD-WAN ?
Il s’agit d’une vulnérabilité zero-day avec un score CVSS 10,0 qui permet à un attaquant distant, sans authentification, de contourner la procédure de peering et d’obtenir des privilèges administratifs sur des composants clés comme le Controller ou le Manager.

Comment vérifier si un Cisco vManage/vSmart a été compromis par cette faille ?
En examinant les logs de peering / contrôle de connexion inhabituels, les accès SSH suspectés (incluant l’ajout de clés dans authorized_keys), la présence de logs tronqués ou toute indication d’un downgrade/upgrade non autorisé.

Quelles versions corrigent la vulnérabilité CVE-2026-20127 dans Catalyst SD-WAN ?
Les versions à appliquer dépendent de la branche concernée. INCIBE-CERT recommande notamment 20.12.6.1, 20.15.4.2, ou 20.18.2.1. En cas de versions plus anciennes, il faut envisager une migration vers une version maintenue et corrigée.

Pourquoi mentionne-t-on NETCONF (port 830) dans ce contexte ?
Parce qu’après contour du mécanisme d’authentification, un attaquant pourrait utiliser l’interface de gestion NETCONF pour modifier la configuration critique du maillage SD-WAN.

Sources : The Hacker News et Cisco