Cisco SD-WAN Manager activement attaqué : qui applique le correctif, vous ou votre prestataire ?

Le 30 septembre 2026, à 16 h, heure de Riyad, Cisco a publié un avis de sécurité concernant la CVE-2026-76504 dans Cisco Catalyst SD-WAN Manager, le système qu'utilisent les entreprises multi-sites pour piloter tout leur réseau d'agences depuis un seul écran. Le score de gravité est de 9,8 sur 10, l'exploitation ne nécessite ni compte ni mot de passe, Cisco indique avoir eu connaissance d'une exploitation active au cours du mois de septembre, et il n'existe aucun contournement. Le même jour, l'Autorité nationale de cybersécurité (NCA) d'Arabie saoudite a émis l'alerte 2026-7889 de gravité critique, demandant aux organisations d'examiner l'avis et d'appliquer la mise à jour.

La question clé n'est pas technique : qui applique le correctif ?

Il y a deux semaines, nous avons écrit sur une faille exploitée dans un autre équipement Cisco, celui qui gère les identités et les accès, et nous y avons couvert les bases de la gestion des vulnérabilités. Cette fois, la question la plus importante n'est pas technique. Il se peut que vous ne gériez pas du tout votre réseau d'agences : un opérateur télécom ou une société informatique peut le gérer pour vous dans le cadre d'un contrat de service géré. Dans ce cas, qui met le système à niveau ce soir, qui vérifie si quelqu'un est entré avant la mise à niveau, et que dit votre contrat si ni l'un ni l'autre n'est fait ?

Ce que Cisco a réellement publié

L'information date de quelques heures ; ces faits proviennent donc directement de l'avis de Cisco et de l'alerte de la NCA, et non des comptes rendus de presse :

• Produit : Cisco Catalyst SD-WAN Manager, anciennement appelé vManage. L'avis précise qu'il est concerné quelle que soit sa configuration.
• Cause : une mauvaise gestion de l'encodage URI dans les requêtes HTTP permet à une requête forgée de contourner une règle d'authentification censée protéger un point de terminaison d'API précis ; l'attaquant atteint ainsi l'API avec les privilèges de l'utilisateur admin.
• Prérequis : aucun. Un attaquant distant et non authentifié, et un score de base CVSS de 9,8.
• Statut : activement exploitée. Le PSIRT de Cisco indique avoir eu connaissance de l'exploitation en septembre 2026, et que la faille a été découverte lors de la résolution d'un dossier d'assistance du Cisco Technical Assistance Center.
• Contournement : aucun. Le correctif consiste à passer à une version corrigée.
• Alerte locale : l'alerte 2026-7889 de la NCA, datée du 30 septembre 2026. Elle cite 14 secteurs ciblés, soit pratiquement tous, du commerce et de l'investissement, de la finance et de l'économie et de la santé jusqu'à l'éducation, aux transports et à l'industrie.

Les versions corrigées, selon l'avis :

Notez la première ligne. Quiconque utilise une version antérieure à 20.9 n'est pas face à une petite mise à jour, mais à un passage vers une autre branche de version. Cela demande une planification, et cela ne peut pas attendre.

Pourquoi ce système en particulier

Un réseau SD-WAN relie les agences, les entrepôts et le siège via toutes les connexions disponibles, et l'ensemble est géré depuis un système central. C'est là que s'écrivent les politiques : quel trafic passe par quel lien, quelle agence peut atteindre quel système, et quels paramètres sont envoyés au routeur de chaque site. Une modification au centre atteint toutes les agences. C'est tout l'intérêt.

Cette même caractéristique fait le danger. Quiconque atteint l'API de ce système avec des privilèges d'administrateur n'a pas affaire à un seul appareil, mais à la console qui gère la configuration de tout le réseau. Le point de vente d'une agence, la liaison avec l'entrepôt et l'accès au système comptable depuis l'extérieur du siège peuvent tous passer par un réseau que ce système contrôle. Il a sa place en tête de la liste des actifs critiques, aussi éloigné qu'il paraisse de la gestion quotidienne.

Le cloud de Cisco ou votre centre de données ? C'est ce qui décide qui agit

L'avis distingue deux façons d'exploiter le système, et la différence est très concrète :

• Dans le cloud de Cisco : l'avis indique que la faille touche SD-WAN Manager quelle que soit la configuration, et il décrit deux cas de cloud. Dans les environnements Cisco Catalyst SD-WAN Cloud Hosted, Cisco a déjà déployé la mesure d'atténuation par restriction d'accès, mais une atténuation n'est pas un correctif : la mise à niveau vers une version corrigée du tableau ci-dessus reste donc nécessaire, et vous devez demander qui s'en charge. Dans Cisco SD-WAN Cloud (Cisco Managed), la version 20.15.605 corrige la faille, Cisco indique qu'aucune action de l'utilisateur n'est requise, et la version peut être vérifiée via la fonction Help de l'interface du service. Ce n'est que dans ce dernier cas que la mise à niveau relève du fournisseur. Votre rôle reste d'obtenir une confirmation écrite et de demander l'examen des journaux pour la période qui précède.
• Sur site, chez vous ou dans le centre de données de votre prestataire : ici, personne ne mettra le système à niveau à votre place si le contrat ne le prévoit pas. Jusqu'à la mise à niveau, la mesure d'atténuation décrite par Cisco consiste à restreindre l'accès au système depuis des réseaux non sécurisés comme Internet, et à protéger les composants de contrôle SD-WAN derrière un dispositif de filtrage tel qu'un pare-feu.

La première question n'est donc pas de savoir si vous utilisez Cisco. C'est de savoir où tourne votre système de gestion du réseau et à qui revient sa mise à niveau. Si seul le prestataire connaît la réponse, c'est la première lacune à combler, et elle n'est pas technique.

Une mise à niveau ne vous dit pas si quelqu'un est entré avant

Cisco a eu connaissance de l'exploitation en septembre et a publié le correctif le dernier jour du mois. Autrement dit, la faille était exploitée avant qu'il n'existe la moindre mise à jour à appliquer. Mettre à niveau ce soir ferme la porte. Cela ne vous dit pas si quelqu'un l'a déjà franchie en laissant derrière lui un compte ou une modification de configuration.

C'est pourquoi Cisco a publié des indicateurs que votre équipe informatique ou votre prestataire peut rechercher dans deux journaux précis du système, serviceproxy-access.log et vmanage-server.log :

• Des requêtes vers j_security_check provenant d'adresses IP inconnues ou non autorisées.
• Tout caractère encodé en URI dans le chemin de la requête, comme %6a_security_check, où %6a est la lettre j encodée. C'est ainsi que l'exploit passe outre la règle d'authentification. Cisco souligne que %6a n'est qu'un exemple : l'encodage de n'importe quel caractère de la requête peut être utilisé ; l'équipe doit donc rechercher toutes les variantes encodées de j_security_check, et pas seulement %6a.
• Dans vmanage-server.log en particulier : des requêtes j_security_check provenant d'adresses inconnues pour des noms d'utilisateur commençant par viptela-reserved-. Il s'agit de comptes de service intégrés au système ; l'apparition du nom dans le journal n'est donc pas en soi un signe de compromission. Ce qui compte, c'est la source inconnue.

Cisco avertit également que ces indicateurs peuvent parfois apparaître lors du fonctionnement normal ; ils doivent donc être comparés à l'activité habituelle du réseau avant d'en tirer des conclusions.

La même leçon est apparue cette semaine avec deux failles critiques de Citrix NetScaler que l'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajoutées à son catalogue des vulnérabilités exploitées connues le 27 septembre. La CISA a indiqué que des acteurs malveillants les exploitent activement dans le monde entier, a encouragé les organisations à rechercher des signes de compromission avant d'appliquer les correctifs lorsque c'est possible, et a précisé que toute organisation soupçonnant une compromission doit préserver les preuves forensiques avant d'appliquer les mises à jour, car celles-ci peuvent effacer les traces de ce qui s'est passé. La règle vaut ici aussi : vérifiez, conservez une copie des journaux, puis mettez à niveau, sans laisser la vérification devenir une raison de retarder la mise à niveau de plusieurs jours.

Si votre réseau est un service géré : que dit votre contrat ?

Les contrôles essentiels de cybersécurité de la NCA, édition 2024, sont obligatoires pour les entités gouvernementales et leurs sociétés affiliées, ainsi que pour les entités du secteur privé qui possèdent, exploitent ou hébergent des infrastructures nationales critiques. La NCA encourage vivement toutes les autres organisations du Royaume à les utiliser. Même si votre entreprise n'y est pas tenue, ils constituent la référence locale la plus claire sur ce qui doit figurer dans le contrat de tout prestataire qui gère une partie de votre technologie :

• Dans les contrats avec des tiers dont la défaillance pourrait affecter vos données ou vos services, y compris les accords de niveau de service : la non-divulgation et la suppression sécurisée de vos données à la fin du service, les procédures de communication en cas d'incident de cybersécurité, et l'obligation pour le tiers d'appliquer vos exigences et politiques de cybersécurité (contrôle 4-1-2).
• Dans les contrats avec les prestataires d'externalisation informatique et de services gérés en particulier : une évaluation des risques de cybersécurité, avec confirmation des contrôles d'atténuation, avant la signature ; et les centres de services gérés de cybersécurité pour la surveillance et l'exploitation qui utilisent un accès à distance doivent être situés entièrement dans le Royaume (contrôle 4-1-3).
• Dans la gestion des vulnérabilités : classer les vulnérabilités par gravité et y remédier selon ce classement, s'abonner à des sources fiables pour être informé des nouvelles vulnérabilités, et vérifier les mises à jour dans un environnement hors production avant de les appliquer (contrôle 2-10-3).

Remarquez ce que les contrôles de gestion des vulnérabilités ne disent pas : ils ne fixent aucun délai pour appliquer une mise à jour critique. Ce chiffre doit être inscrit dans votre propre contrat. Sinon, le prestataire applique le correctif quand il le peut, et non quand vous en avez besoin.

Un message à envoyer à votre prestataire aujourd'hui

Il n'est pas nécessaire d'être technicien pour poser ces questions, ni d'attendre une réunion. Demandez les réponses par écrit :

• Notre réseau fonctionne-t-il sur Cisco Catalyst SD-WAN Manager ? Et où tourne-t-il : dans le cloud de Cisco, sur notre site ou dans votre centre de données ?
• Sur quelle version est-il, et quand sera-t-il mis à niveau vers la version corrigée, avec la date et l'heure ?
• L'interface de gestion est-elle accessible depuis Internet en ce moment ? Si oui, avez-vous restreint l'accès jusqu'à la mise à niveau ?
• Avez-vous vérifié les deux journaux cités par Cisco pour les indicateurs publiés, et en avez-vous conservé une copie avant la mise à niveau ? Qu'avez-vous trouvé ?
• Qui nous a informés de cette alerte en premier : vous, ou un article que nous avons lu ? Et quelle est la procédure convenue pour nous prévenir la prochaine fois ?

La dernière question est la plus importante. Si vous avez appris l'existence de l'alerte par un article plutôt que par votre prestataire, le problème dépasse cette seule faille.

Le regard d'Origami

Nous construisons des systèmes de gestion. Nous ne vendons ni n'exploitons d'équipements réseau. Mais chaque système que nous construisons pour un client multi-sites repose sur un réseau que nous n'avons pas conçu : le point de vente de l'agence envoie au serveur, l'entrepôt met à jour les stocks, la facture électronique part vers la plateforme. Et la réponse habituelle à la question de savoir qui applique les correctifs au réseau est : le prestataire s'occupe de tout. C'est une réponse rassurante, et ce n'est pas une réponse.

Pour un chef d'entreprise saoudien, nous lisons cette faille comme un rappel : l'externalisation déplace le travail, mais pas la responsabilité. Un service géré est le bon choix pour de nombreuses entreprises, à condition que le contrat contienne trois éléments mesurables : un délai défini pour appliquer les mises à jour critiques, une notification écrite de chaque alerte touchant vos systèmes, et un rapport après chaque incident indiquant ce qui a été vérifié et ce qui a été trouvé. Ces clauses ne coûtent rien à un bon prestataire, et elles révèlent un prestataire faible avant qu'une vulnérabilité ne le fasse.

L'essentiel

• Si vous exploitez Cisco Catalyst SD-WAN Manager sur votre site ou chez votre prestataire, la mise à niveau vers la version corrigée est une urgence, pas une tâche planifiée, et les versions antérieures à 20.9 nécessitent un passage vers une branche corrigée.
• Jusqu'à la mise à niveau : bloquez l'accès au système depuis Internet et placez les composants de contrôle derrière un pare-feu, comme le décrit l'avis.
• Vérifiez les deux journaux et conservez-en une copie avant la mise à niveau, car l'exploitation a commencé avant la publication du correctif.
• Si le réseau est un service géré, envoyez dès aujourd'hui les questions ci-dessus, puis ajoutez au contrat, lors du prochain renouvellement, un délai pour les mises à jour critiques et une procédure de notification.

Sources

• Cisco : avis de sécurité cisco-sa-sdwan-webauth-xr8beuuU concernant la CVE-2026-76504 (30 septembre 2026)
• Autorité nationale de cybersécurité : alerte Cisco 2026-7889 (30 septembre 2026)
• Autorité nationale de cybersécurité : contrôles essentiels de cybersécurité, édition 2024
• CISA : Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway (septembre 2026)