Cisco corrige un zero-day d’authentification dans Catalyst SD-WAN Manager déjà exploité
La faille CVE-2026-76504 laisse un attaquant non authentifié contourner l’authentification du Catalyst SD-WAN Manager via un encodage d’URI et obtenir les droits admin. Aucune parade n’existe : patcher immédiatement et inspecter les journaux j_security_check.
30 septembre 2026. Cisco publie un correctif pour une faille critique du Catalyst SD-WAN Manager, l’ex-SD-WAN vManage, et confirme qu’elle est déjà exploitée dans la nature. 30 septembre 2026. La CISA ajoute la CVE-2026-76504 à son catalogue KEV avec une échéance fédérale au 3 octobre. 30 septembre 2026. L’éditeur précise que les attaquants utilisent le caractère %6a dans leurs requêtes malveillantes. Pourquoi c’est important : c’est la cinquième faille SD-WAN exploitée en zero-day depuis janvier, et celle-ci ne connaît aucune parade — seul le patch compte.
Une authentification contournée par un encodage d’URI
La mécanique tient en une phrase. La CVE-2026-76504 est due à une mauvaise gestion de l’encodage d’URI dans une requête HTTP : en encodant un caractère, un attaquant fait passer sa requête à travers une règle d’authentification censée protéger un point d’accès API précis.
Le résultat est brutal. Cisco décrit une faille d’authentification par contournement de la gestion des sessions d’API, exploitée sans aucune authentification préalable : une seule requête HTTP forgée suffit à accéder au système à distance avec les privilèges des comptes admin ou netadmin. Le score CVSS 9.8 reflète la combinaison de l’accès réseau, de l’absence de prérequis et de l’impact complet sur la confidentialité, l’intégrité et la disponibilité.
Le marqueur fourni par Cisco confirme le mécanisme. Le point d’accès visé est j_security_check, le chemin d’authentification de la couche applicative : en encodant le « j » en %6a, la requête ne correspond plus à la chaîne que la règle surveille, et passe comme un utilisateur déjà authentifié. C’est le même principe qu’un filtre qui compare une chaîne littérale sans décoder l’URI au préalable — une classe d’erreur qui revient régulièrement dans les consoles web exposées.
Le produit touché n’est pas un routeur périphérique mais la console qui le pilote. Le Catalyst SD-WAN Manager permet d’administrer jusqu’à 6 000 équipements SD-WAN depuis un tableau de bord unique. Compromettre le gestionnaire, c’est hériter de la confiance de tout le parc qu’il supervise — un point de bascule plus dangereux qu’un routeur isolé.
La cinquième faille SD-WAN exploitée en 2026
Ce zero-day n’est pas un accident isolé, c’est une tendance. Cisco a déjà corrigé quatre failles SD-WAN exploitées dans la nature depuis le début de l’année.
- Février. La CVE-2026-20127, une divulgation d’informations dans SD-WAN Manager, exploitée en zero-day depuis au moins 2023.
- Mai. La CVE-2026-20182, un contournement d’authentification de sévérité maximale sur le Catalyst SD-WAN Controller, exploité pour obtenir les droits admin.
- Juin. La CVE-2026-20245 et la CVE-2026-20262, deux autres zero-days exploités pour passer root sur les systèmes vulnérables.
L’arithmétique de la CISA enfonce le clou : depuis novembre 2021, l’agence a inscrit 90 vulnérabilités Cisco comme exploitées, dont quatre dans le seul Catalyst SD-WAN Manager et sept détournées par des opérations de ransomware.
Le message est simple. Les équipements de bordure et leurs consoles d’administration sont devenues la cible de choix des acteurs malveillants, parce qu’ils sont exposés à Internet, qu’ils patchent lentement et qu’ils ouvrent sur tout un réseau. Une console SD-WAN Manager joignable depuis Internet est un mot de passe en soi : ne pas la patcher revient à laisser la clé sur la porte.
Pourquoi les consoles de gestion sont le maillon faible
Le Catalyst SD-WAN Manager illustre un problème plus large que ce seul produit. Les consoles d’administration des équipements réseau cumulent trois faiblesses structurelles : elles sont exposées à Internet par nécessité opérationnelle, elles patchent lentement parce qu’un arrêt de maintenance touche toute la flotte qu’elles supervisent, et elles concentrent des privilèges élevés qui en font une cible à fort rendement.
La conséquence se lit dans les chiffres de la CISA. Sur les 90 vulnérabilités Cisco inscrites au KEV depuis novembre 2021, une part disproportionnée touche précisément ces appareils de bordure et leurs consoles — routeurs, firewalls, contrôleurs SD-WAN. Ce ne sont pas les produits les plus nombreux qui sont visés, mais ceux qui ouvrent la porte la plus large.
La leçon opérationnelle est ancienne mais rarement appliquée : une console de gestion n’a pas vocation à être joignable depuis Internet. Quand elle doit l’être, elle exige la même discipline qu’un actif critique — authentification forte, segmentation, supervision des journaux et correctifs sous 24 à 48 heures pour les failles exploitées.
Détecter une compromission déjà en cours
Le correctif ne suffit pas : il faut déterminer si le système a déjà été visité. Cisco fournit des indicateurs de compromission précis, ce qui est rare et précieux.
D’abord, le marqueur technique. Les attaquants utilisent %6a — le caractère « j » encodé en URI — dans leurs requêtes malveillantes. Toute requête contenant ce motif vers le point d’accès d’authentification mérite un examen immédiat.
Ensuite, les journaux à fouiller. Deux fichiers concentrent l’activité suspecte :
# Requêtes vers le proxy de service (chercher les j_security_check anormaux)
grep 'j_security_check' /var/log/nms/containers/service-proxy/serviceproxy-access.log
# Journal principal du manager
grep 'j_security_check' /var/log/nms/vmanage-server.logLa consigne opérationnelle tient en une phrase : chercher les entrées j_security_check provenant d’adresses IP inconnues ou non autorisées. Une entrée de ce type est un signal de compromission, pas un faux positif à ignorer. Pour les cas douteux, Cisco invite à collecter les fichiers admin-tech et à ouvrir un dossier auprès du TAC.
Le tableau des versions corrigées est sans ambiguïté. 20.9 passe à 20.9.10.1, 20.12 à 20.12.8.2, 20.15 à 20.15.6.1, 20.18 à 20.18.4.1, 26.1 à 26.1.2.1 et 26.2 à 26.2.1. Les déploiements antérieurs à 20.9 doivent migrer vers une version corrigée — il n’existe aucun contournement documenté.
Le plan de remédiation se décline en quatre étapes, dans cet ordre.
- 1. Couper l’exposition. Retirer la console de l’accès Internet direct, ou la placer derrière un VPN et une segmentation stricte, le temps d’appliquer le correctif.
- 2. Appliquer le correctif. Monter vers la version corrigée de la branche concernée — 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 ou 26.2.1.
- 3. Chercher les traces. Greper les journaux
j_security_checket le motif%6apour toute adresse inconnue. - 4. Si compromis, pivoter. Rotation des identifiants, inventaire des équipements supervisés et examen des modifications de configuration récentes.
Verdict
Si votre Catalyst SD-WAN Manager est exposé à Internet, le patch est une urgence de même rang qu’une compromission avérée : sans parade, chaque heure d’exposition est une heure de risque, et la CISA attend la correction pour le 3 octobre. Si l’exposition est interne mais que la console supervise un parc sensible, traitez le correctif comme prioritaire tout de même, car un mouvement latéral depuis un poste compromis aboutirait au même point. Dans tous les cas, avant de patcher, grepez les journaux j_security_check : une console déjà visitée impose une rotation des identifiants et un inventaire des équipements supervisés, pas seulement une mise à jour.