Une faille d’authentification de Cisco SD-WAN donne aux attaquants à distance un accès administratif complet

Cisco a révélé une vulnérabilité de contournement de l’authentification, actuellement exploitée, dans Cisco Catalyst SD-WAN Manager. Elle permet à un attaquant distant non authentifié d’obtenir les privilèges du compte administrateur de la plateforme.

Référencée sous le numéro CVE-2026-76504, la vulnérabilité affiche un score CVSS 3.1 de 9,8. Cisco a publié son avis le 30 septembre 2026 à 13 h 00 GMT, après avoir découvert le problème alors que son centre d’assistance technique traitait une demande d’assistance client.

L’équipe de réponse aux incidents de sécurité des produits de Cisco a eu connaissance de l’exploitation au cours du mois de septembre 2026. L’entreprise n’a pas précisé quand les attaques avaient commencé, combien de clients avaient été touchés, qui en était à l’origine ni ce que les intrus avaient fait après avoir obtenu un accès.

L’encodage URI contourne une règle d’authentification de l’API

CVE-2026-76504 affecte l’authentification par session de l’API de Cisco Catalyst SD-WAN Manager. Le traitement incorrect des caractères encodés dans l’URI permet à une requête HTTP spécialement conçue de contourner une règle d’authentification qui devrait restreindre l’accès à un point de terminaison précis.

L’attaquant n’a besoin ni d’identifiants, ni d’une session existante, ni d’une interaction de l’utilisateur. Une exploitation réussie lui confère les privilèges attribués à l’utilisateur admin.

Par défaut, ce compte possède le rôle netadmin, qui autorise toutes les opérations sur l’appareil. La vulnérabilité compromet donc la confidentialité, l’intégrité et la disponibilité, comme le reflète le vecteur CVSS complet de Cisco :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:X/RL:X/RC:X

Cisco classe la faiblesse sous-jacente comme CWE-177 et la suit en interne sous l’identifiant de bogue CSCww79570.

Le chemin d’authentification j_security_check est au cœur de l’exploitation. L’exemple de Cisco utilise le chemin de requête suivant :

/%6a_security_check

Ici, %6a est la représentation encodée dans l’URI de la lettre j. Les défenseurs ne doivent toutefois pas rechercher uniquement cette chaîne exacte. Cisco avertit qu’un attaquant peut encoder n’importe quel caractère de la requête, ce qui permet de créer plusieurs représentations d’un même point de terminaison.

Il s’agit d’une défaillance de la frontière d’authentification, et non d’une attaque reposant sur le vol de mots de passe. Le simple changement des identifiants ne corrige pas le comportement vulnérable de traitement des requêtes.

Toutes les configurations sont concernées, mais des versions corrigées sont disponibles

Le produit concerné est Cisco Catalyst SD-WAN Manager, anciennement appelé SD-WAN vManage. Selon Cisco, le produit est vulnérable quelle que soit sa configuration, et aucun autre produit n’est concerné.

La plateforme de gestion peut contrôler jusqu’à 6 000 appareils SD-WAN depuis un seul tableau de bord. La compromission de Manager peut donc offrir à un attaquant une position privilégiée dans un déploiement réseau de grande ampleur.

Cisco a publié les correctifs suivants :

Branche de version de Cisco Catalyst SD-WAN	Première version corrigée
Antérieure à 20.9	Migrer vers une version corrigée
20.9	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
26.2	26.2.1

Aucune solution de contournement ne corrige la faille. Cisco recommande vivement d’installer une version corrigée.

L’avis ne mentionne pas les branches de versions 20.10, 20.11, 20.13, 20.14 ou 20.16. Leur absence ne signifie pas pour autant qu’elles sont épargnées. Les administrateurs qui utilisent une branche non répertoriée doivent consulter la matrice de mise à niveau de Cisco et confirmer la procédure de migration appropriée.

Cisco SD-WAN Cloud (Cisco Managed) a été corrigé dans la version 20.15.605 et ne nécessite aucune intervention de la part des clients. Ceux-ci peuvent vérifier leur version ou l’état de la remédiation à l’aide de la fonction d’aide de l’interface du service.

Cisco indique également qu’une mesure d’atténuation a déjà été déployée dans les environnements Cisco Catalyst SD-WAN Cloud Hosted. Ce modèle de déploiement est distinct de la version cloud Cisco Managed corrigée en 20.15.605. L’avis actuel ne mentionne pas Cisco SD-WAN Cloud-Pro ni Cisco SD-WAN for Government (FedRAMP) ; leur statut ne peut donc pas être déduit de cette omission.

Éléments à rechercher dans les journaux

Les instances de Manager exposées à Internet présentent le risque le plus évident. Les administrateurs doivent rechercher, dans les fichiers suivants, les requêtes comportant j_security_check et provenant d’adresses inconnues ou non autorisées :

/var/log/nms/containers/service-proxy/serviceproxy-access.log
/var/log/nms/vmanage-server.log

Dans vmanage-server.log, les défenseurs doivent notamment examiner les activités associées aux noms d’utilisateur commençant par :

viptela-reserved-

Ces noms appartiennent à des comptes de service système réservés. Leur apparition n’est pas nécessairement malveillante, car des activités légitimes de la plateforme peuvent produire des entrées similaires. Chaque occurrence doit être évaluée au regard des opérations attendues, des adresses d’origine, de l’exposition et des événements environnants.

L’exemple de journal d’accès de Cisco, daté du 29 septembre 2026, contient une réponse HTTP réussie à la requête suivante :

POST /%6a_security_check HTTP/1.1

L’exemple correspondant dans le journal vManage consigne le chemin encodé pour un utilisateur affiché comme viptela-reserved-... Il s’agit d’indicateurs fournis à titre d’exemple, et non d’une règle de détection exhaustive.

Les défenseurs doivent normaliser l’encodage URI avant de rechercher des chemins de requête. Une recherche limitée à %6a_security_check risque de ne pas détecter les variantes qui encodent un autre caractère.

Les organisations qui soupçonnent une compromission doivent ouvrir un dossier de sévérité 3 auprès du Cisco TAC et inclure CVE-2026-76504 dans le titre. Avant d’ouvrir le dossier, Cisco demande aux clients d’exécuter la commande suivante :

request admin-tech

Le fichier admin-tech obtenu doit être transmis au TAC pour analyse. Cisco n’a pas indiqué qu’une mise à niveau supprimerait l’accès d’un attaquant qui serait déjà parvenu à s’introduire dans le système. Tout incident suspect doit donc faire l’objet d’une enquête en plus de l’installation du correctif.

Réduire l’exposition en attendant les mises à niveau

Dans l’attente de la mise à niveau d’une instance de Manager installée sur site, il convient de restreindre les accès depuis Internet et les autres réseaux non fiables. Si une connectivité externe est nécessaire au fonctionnement, Cisco recommande de n’autoriser que les hôtes connus, sur les ports et protocoles requis par sa documentation de déploiement.

Les composants de contrôle SD-WAN doivent être placés derrière un dispositif de filtrage, avec des communications entrantes et sortantes limitées aux systèmes de confiance. Cisco indique également qu’une architecture à deux couches de pare-feu peut empêcher les utilisateurs finaux d’accéder directement à la zone démilitarisée externe.

Les services d’administration sur les ports 443, 22 et 830 ne doivent pas être directement exposés à Internet. L’accès d’administration HTTPS doit plutôt être limité à un hôte bastion ou à un sous-réseau de gestion dédié.

Cisco indique que ces restrictions réseau ont fonctionné dans son environnement de test, mais les clients doivent évaluer leurs effets éventuels sur les fonctionnalités et les performances. Elles ne remplacent pas la mise à jour logicielle.

Parmi les autres mesures de défense figurent le transfert des journaux vers un serveur externe, leur conservation pendant une durée suffisante pour permettre l’analyse d’incidents, le changement du mot de passe administrateur par défaut et la limitation des privilèges d’administration aux besoins opérationnels. Les organisations doivent créer des comptes opérateur pour l’administration courante et utiliser un certificat SSL émis par une autorité de certification pour les déploiements SSL/TLS.

Les correctifs précédents ne couvrent pas cette vulnérabilité

CVE-2026-76504 est distincte de trois autres vulnérabilités Cisco SD-WAN corrigées auparavant : CVE-2026-20182, CVE-2026-20245 et CVE-2026-20262.

Les versions corrigées pour ces failles sont antérieures à celles qui corrigent CVE-2026-76504. Une instance de Manager corrigée uniquement contre les vulnérabilités précédentes reste donc exposée au nouveau contournement de l’authentification.

La CISA a ajouté CVE-2026-20182 à son catalogue des vulnérabilités exploitées connues (KEV) le 14 mai 2026, avec une échéance de remédiation fixée au 17 mai pour les agences fédérales. CVE-2026-20245 a été ajoutée au catalogue le 9 juin, avec une échéance au 23 juin, tandis que CVE-2026-20262 y a été inscrite le 15 juin, avec une échéance de remédiation au 29 juin.

Une vulnérabilité distincte de divulgation d’informations, CVE-2026-20127, a été ajoutée au catalogue KEV le 25 février, avec une échéance fixée au 27 février.

Aucune inscription au catalogue KEV ni aucune échéance de remédiation fédérale n’ont été signalées pour CVE-2026-76504. Son exploitation confirmée montre néanmoins que le risque est concret et non hypothétique.

Le contexte plus large chez Cisco reste également marqué par plusieurs menaces : CVE-2026-76460, CVE-2026-76461, CVE-2026-20079, CVE-2026-20349, CVE-2026-20316 et CVE-2008-4128 ont été ajoutées au catalogue KEV au cours des 90 jours précédents. CVE-2026-20316 est signalée comme utilisée dans des attaques par rançongiciel.

Pour les responsables de Cisco Catalyst SD-WAN Manager, les priorités sont claires : installer la version corrigée appropriée, supprimer toute exposition directe à Internet, conserver les journaux pertinents et signaler au Cisco TAC toute activité d’authentification suspecte.