Le présent document décrit les étapes à suivre pour identifier et corriger les vulnérabilités de sécurité critiques dans le SD-WAN en fonction des avis émis par le PSIRT les 4 et 15 juin 2026.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour obtenir des informations détaillées et les dernières mises à jour, reportez-vous à la page d'avis officielle du PSIRT.
Ces conseils sont disponibles à l'adresse suivante :
Ces défauts sont corrigés par les avis suivants du PSIRT :
Ces avis décrivent deux vulnérabilités du SD-WAN de Cisco Catalyst. La première (CVE-2026-20245) est une vulnérabilité d'escalade de privilèges dans les composants de contrôle SD-WAN qui nécessite des privilèges d'administrateur réseau pour être exploitée. La deuxième (CVE-2026-20262) est une vulnérabilité d'écriture de fichier arbitraire dans SD-WAN Manager (vManage) qui permet à un utilisateur authentifié de créer ou d'écraser n'importe quel fichier sur le système de fichiers d'un système affecté.
Pour CVE-2026-20245 et CVE-2026-20262, les chemins connus d'un attaquant distant non authentifié pour obtenir les informations d'identification requises sont l'exploitation de CVE-2026-20182 (cisco-sa-sdwan-rpa2-v69WY2SW) ou CVE-2026-20127 (cisco-sa-sdwan-rpa-EHchtZk). CVE-2026-20245 nécessite des privilèges d'administrateur réseau pour l'exploitation, tandis que CVE-2026-20262 nécessite au moins un compte d'utilisateur à tâche unique avec des privilèges inférieurs.
Si vos composants de contrôle ont été mis à niveau vers une version fixe pour ces deux avis et que Cisco n'a pas identifié d'indicateurs de compromission (IoC) potentiels dans les fichiers admin-tech que vous avez fournis pour les événements précédents, alors les chemins d'exploitation non authentifiés connus pour CVE-2026-20245 et CVE-2026-20262 sont atténués sur ces périphériques spécifiques, en fonction des fichiers examinés. Cela n'élimine pas l'exposition lorsqu'un pirate détient des informations d'identification valides. Cisco vous recommande d'effectuer une mise à niveau vers une version fixe pour les deux avis.
Action requise : ouvrez un dossier Cisco TAC pour répondre à ces conseils de sécurité.
Le TAC est disponible pour :
required : Collectez les fichiers admin-tech de tous les composants de contrôle avant toute mise à niveau ou modification de configuration afin de préserver les données de diagnostic et les indicateurs de compromission (IoC) potentiels. Ces fichiers sont utilisés par le TAC à l'étape 3 pour analyser votre environnement.
Collection : pour la génération admin-tech, sélectionnez les options Log et Tech. Core n'est pas requis.
Collecte d'un Admin-Tech dans un environnement SD-WAN et téléchargement vers un dossier TAC
Remarque : Le TAC analyse ces fichiers afin d'évaluer votre environnement à la recherche d'indicateurs de compromission liés aux deux avis. Pour l'avis d'escalade de privilèges, l'analyse se concentre sur une entrée de journal spécifique dans /var/log/scripts.log qui ne fait pas de distinction entre une utilisation légitime et une utilisation malveillante ; un examen manuel par le TAC est nécessaire. Pour l'avis d'écriture de fichier arbitraire, l'analyse se concentre sur les entrées dans /var/log/nms/vmanage-server.log ; ces entrées peuvent également se produire pendant les opérations standard et doivent être évaluées par rapport à la position opérationnelle normale pour éviter les faux positifs.
Si vous ne pouvez pas partager de fichiers admin-tech, une étape de vérification manuelle est disponible. Cette étape fournit un indicateur préliminaire qui doit être documenté et partagé avec le TAC.
Reportez-vous à la section Étapes de vérification manuelles à la fin de ce document pour une procédure détaillée. Documentez toutes les conclusions et fournissez-les au TAC dans votre dossier d'assistance.
Après avoir collecté les fichiers admin-tech à l'étape 1, ouvrez un dossier d'assistance TAC Cisco et téléchargez les fichiers admin-tech collectés. Le TAC analyse les admin-techs à la recherche d'indicateurs de compromission associés aux deux avis (CVE-2026-20245 et CVE-2026-20262).
Actions requises :
cisco-sa-sdwan-privesc-4uxFrdzx et cisco-sa-sdwan-arbfw-c2rZvQ dans le titre pour lancer l'analyse.
Remarque : Cisco a publié des correctifs logiciels pour ces vulnérabilités dans toutes les catégories de versions à l'heure actuelle, mais aucune solution de contournement n'est disponible. L'analyse du centre d'assistance technique à l'étape 3 permet de déterminer si des indicateurs de compromission sont présents dans les fichiers admin-tech que vous avez fournis. Effectuez une mise à niveau vers une version logicielle fixe et respectez les directives du TAC concernant toute autre étape suivante nécessaire.
Le TAC effectue une analyse préliminaire des fichiers admin-tech que vous avez téléchargés à l'étape 2 et les évalue pour les indicateurs de compromission associés aux deux avis (CVE-2026-20245 et CVE-2026-20262).
Pour l'avis CVE-2026-20245, l'analyse se concentre sur une entrée de journal spécifique dans /var/log/scripts.log sur chaque composant de contrôle (vManage, vSmart et vBond). Étant donné que la commande sous-jacente est légitime et que le journal ne fait pas de distinction entre une utilisation légitime et une utilisation malveillante, toute entrée correspondante doit être examinée manuellement par le TAC par rapport à votre position opérationnelle normale avant d'être traitée comme un indicateur confirmé.
Pour l'avis CVE-2026-20262, l'analyse porte sur plusieurs fichiers du répertoire /var/log/nms de chaque manager (vManage). Dans certains cas, ces indicateurs de compromission peuvent se produire lors d'opérations standard.
Ces journaux ne font pas de distinction entre une utilisation légitime et une utilisation malveillante ; par conséquent, toute entrée correspondante doit être examinée manuellement par le TAC par rapport à votre position opérationnelle normale avant d'être traitée comme un indicateur confirmé.
Résultats possibles de l'analyse du TAC :
Remarque : Selon l'avis CVE-2026-20245, l'exploitation nécessite des privilèges netadmin, tandis que CVE-2026-20262 nécessite au moins un compte d'utilisateur à tâche unique avec des privilèges inférieurs. Un pirate non authentifié peut obtenir ces informations d'identification par le biais d'informations d'identification valides ou de l'exploitation de CVE-2026-20182 ou CVE-2026-20127. Si vos composants de contrôle ont été mis à niveau vers une version fixe pour ces deux conseils et qu'aucun indicateur de compromission n'a été identifié pour les événements précédents, les chemins d'exploitation non authentifiés connus pour CVE-2026-20245 et CVE-2026-20262 sont atténués sur ces périphériques spécifiques, en fonction des fichiers examinés.
Si le TAC identifie des indicateurs de compromission associés à ces avis dans votre environnement, il vous contacte en vous fournissant des conseils spécifiques. Suivez toutes les instructions fournies par le TAC.
Si aucun indicateur de compromission n'est identifié pour l'un ou l'autre avis, aucune autre action spécifique à l'évaluation de la compromission n'est requise pour le moment, sur la base des fichiers admin-tech examinés. La mise à niveau vers une version fixe pour les deux avis est toujours fortement recommandée.
Ces versions logicielles contiennent des correctifs pour les vulnérabilités identifiées :
| S'applique aux versions actuelles | Version fixe | Logiciels disponibles |
|---|---|---|
| 20.9.9.1 et versions antérieures | 20.9.9.2 | 20.9.9.2 images de mise à niveau pour vManage, vSmart et vBond |
| 20.12.7.1 et versions antérieures | 20.12.7.2 | Images de mise à niveau 20.12.7.2 pour vManage, vSmart et vBond |
| 20.15.4.4 et versions antérieures | 20.15.4.5 | Images de mise à niveau 20.15.4.5 pour vManage, vSmart et vBond |
| 20.15.5.2 et versions antérieures | 20.15.5.3 | Images de mise à niveau 20.15.5.3 pour vManage, vSmart et vBond |
| 20.16, 20.17, 20.18.x | 20.18.3.1 | Images de mise à niveau 20.18.3.1 pour vManage, vSmart et vBond |
| 26.1 | 26.1.1.2 | 26.1.1.2 images de mise à niveau pour vManage, vSmart et vBond |
Références importantes :
À l'issue d'une correction réussie et en fonction de vos exigences spécifiques en matière d'assurance de la sécurité, Cisco vous recommande d'évaluer et de mettre en oeuvre les activités d'hygiène répertoriées ici. Ces activités s'appliquent quelle que soit l'option de correction sélectionnée. Ils sont gérés par l'utilisateur ; Cisco ne les dirige pas et ne les exécute pas en votre nom.
Cisco ne recommande pas de chemin de résolution particulier ; la sélection d'une option de correction incombe à chaque client.
Remarque : En cas de suspicion de compromission d'un périphérique de périphérie, la réinitialisation et la réintégration en usine du ou des périphériques de périphérie affectés constituent une action gérée par le client à prendre en compte lors de votre sélection. C'est à chaque client qu'il appartient de décider s'il doit poursuivre cette approche et de choisir l'option à sélectionner.
La commande appropriée pour effectuer une réinitialisation d'usine sécurisée est la suivante :
factory-reset all secure
Remarque : La collecte Admin-tech est la méthode privilégiée. Utilisez uniquement l'étape de vérification manuelle indiquée ici si les fichiers admin-tech ne peuvent pas être collectés et partagés avec le TAC. Le résultat de cette étape manuelle est préliminaire ; documenter les résultats et les partager avec le TAC, qui effectue l'évaluation officielle.
Remarque : Pour les deux avis, la vérification manuelle consiste en des vérifications ciblées des journaux. Les entrées de journal ciblées par ces vérifications sont générées par des commandes et des activités légitimes, et les journaux à eux seuls ne font pas la distinction entre une utilisation légitime et malveillante. Toute entrée correspondante doit être comparée à votre position opérationnelle normale avant d'être traitée comme un indicateur potentiel. Si une entrée correspondante ne peut pas être rapprochée des opérations normales, documentez la conclusion et partagez-la avec le TAC.
scripts.log sur chaque composant de contrôle les entrées de téléchargement de fichierConformément à l'avis du PSIRT, les utilisateurs sont encouragés à vérifier les fichiers journaux à la recherche d'entrées similaires à cet exemple. Dans les versions 20.9 et ultérieures, cette entrée se trouve dans scripts.log à l'adresse /var/log/. Sur les versions antérieures à 20.9, les données équivalentes se trouvent dans les journaux de vdebug à l'adresse /var/log/tmplog/ :
Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0
Étape 1: Accédez à vshell sur chaque composant de contrôle et recherchez les indicateurs CVE-2026-20245 dans les fichiers journaux appropriés
L'emplacement du fichier journal dépend de la version du logiciel exécutée sur le composant de contrôle. Déterminez ce qui s'applique à votre environnement avant d'exécuter la recherche.
Version 20.9 et ultérieure — Rechercher scripts.log dans le fichier /var/log/tmplog/ :
À partir de l'interface de ligne de commande vManage, accédez à vshell et exécutez :
vs
zgrep "vconfd_script_upload_tenant_list.sh" /var/log/scripts.log*
Versions antérieures à la version 20.9 — Recherche dans les journaux vdebug dans /var/log/tmplog/:
Sur les versions antérieures à 20.9, scripts.log n'est pas présent. Les données de journal équivalentes sont écrites dans /var/log/tmplog/vdebug. Jusqu'à cinq fichiers numérotés sont conservés (vdebug, vdebug.1 à vdebug.5). Rechercher tous les fichiers actifs avec :
vs
zgrep "vconfd_script_upload_tenant_list.sh" /var/log/tmplog/vdebug*
En plus des fichiers actifs, les journaux plus anciens sont archivés en tant que fichiers tar compressés dans /var/log/ en utilisant le modèle d'attribution de noms vdebug_<timestamp>.tar.gz, avec les données de journal stockées dans l'archive dans var/log/tmplog. Rechercher toutes les archives avec :
for f in /var/log/vdebug_*.tar.gz; do echo "=== $f ==="; tar -xOf "$f" var/log/tmplog 2>/dev/null | grep "vconfd_script_upload_tenant_list.sh"; done
Répétez toutes les vérifications applicables sur chaque composant de contrôle dans le déploiement (y compris tous les membres du cluster et tout vManage associé à un routeur désigné).
Étape 2: Interpréter les résultats et le document pour le TAC
Si AUCUNE entrée correspondante n'est renvoyée :
Si des entrées correspondantes sont renvoyées :
chemin d'accès à l'interface de ligne de commande.Conformément à l'avis du PSIRT, les utilisateurs sont encouragés à vérifier ces fichiers journaux sur chaque gestionnaire (vManage) pour les entrées similaires à ces exemples :
Exemple d'entrée suspecte dans vmanage-server.log (situé dans /var/log/nms/)
11-June-2026 03:53:37,310 EDT INFO [a66cdc5f-807d-4c23-944e-5c809a2ece6b] [server] [SdraAnyConnectFileUploadHandler] (default task-40704) |default| uploaded Remote Access Anyconnect profile file: ../../../../var/lib/wildfly/standalone/deployments/suspicious.war to vManage.
Exemple d'entrée suspecte dans vmanage-appserver.log (situé dans /var/log/nms/)
11-June-2026 07:52:55,275 UTC INFO [server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "suspicious.war" (runtime-name : "suspicious.war")
Exemple d'entrée suspecte dans serviceproxy-access.log (situé dans /var/log/nms/containers/service-proxy/)
POST /suspicious/index.jsp HTTP/1.1
Remarque : Dans les versions antérieures à la version 20.9, serviceproxy-access.log se trouve à l'adresse /var/log/nms/ plutôt qu'à l'adresse /var/log/nms/containers/service-proxy/.
Étape 1: Accédez à vshell sur chaque Manager (vManage) et recherchez les fichiers journaux
À partir de l'interface de ligne de commande vManage, accédez à vshell et exécutez :
vs
zgrep "SdraAnyConnectFileUploadHandler" /var/log/nms/vmanage-server.log*
zgrep "WFLYSRV0010" /var/log/nms/vmanage-appserver.log*
Dans certaines versions, le journal service-proxy est accessible directement depuis vshell. Dans les versions où l'accès au shell racine est requis, téléchargez le admin-tech et recherchez les fichiers serviceproxy-access.log dans celui-ci de la même manière en utilisant une commande similaire à :
Versions 20.9 et ultérieures :
tar -xOf .tar.gz var/log/nms/containers/service-proxy/serviceproxy-access.log 2>/dev/null | grep "suspicious"
Versions antérieures à la version 20.9 :
tar -xOf .tar.gz var/log/nms/serverproxy-access.log 2>/dev/null | grep "suspicious"
Si vous accédez directement à partir de vshell, utilisez le nom de fichier .war identifié à partir des résultats des deux commandes précédentes (sans l'extension) à la place de suspect :
Versions 20.9 et ultérieures :
zgrep "POST" /var/log/nms/containers/service-proxy/serviceproxy-access.log* | grep "suspicious"
Versions antérieures à la version 20.9 :
zgrep "POST" /var/log/nms/serverproxy-access.log* | grep "suspicious"
Répétez la vérification sur chaque vManage du déploiement (y compris tous les membres du cluster et tout vManage associé à un DR).
Étape 2: Interpréter les résultats et le document pour le TAC
Si AUCUNE entrée correspondante n'est renvoyée :
Si des entrées correspondantes sont renvoyées :
vmanage-server.log, capturez l'horodatage, la ligne de journal complète et le chemin d'accès au fichier référencé dans le gestionnaire de téléchargement.Q : Quelle est la première étape pour répondre à ces avis de sécurité ?
A : Collecter les fichiers admin-tech de tous les composants de contrôle (vSmart, vManage, vBond) avant toute mise à niveau ou modification de configuration afin de préserver les données de diagnostic et les indicateurs potentiels de compromission. Ouvrez ensuite un dossier Cisco TAC et téléchargez les admin-techs afin que le TAC puisse les analyser.
Q : Cisco a-t-il publié un correctif logiciel pour ces vulnérabilités ?
A : Oui, les versions fixes sont disponibles pour les deux avis, comme indiqué dans la section Versions logicielles fixes. Il n'y a pas de solution.
Q : Pourquoi Cisco recommande-t-il d'agir au-delà de la mise à niveau ?
A : L'exploitation de ces vulnérabilités nécessite un utilisateur authentifié. Un pirate non authentifié ne peut obtenir ces informations d'identification que par le biais d'informations d'identification valides ou de l'exploitation de CVE-2026-20182 ou CVE-2026-20127. La mise à niveau des composants de contrôle vers les versions fixes de ces avis antérieurs permet d'identifier les chemins non authentifiés connus permettant d'obtenir les privilèges requis pour exploiter ces vulnérabilités. L'analyse admin-tech de l'étape 3 permet de déterminer si des indicateurs de compromission sont présents dans les fichiers examinés.
Q : Dois-je collecter des admin-techs à partir de tous les composants de contrôle ?
A : Oui. Le centre d'assistance technique nécessite des fichiers admin-tech de tous les contrôleurs (vSmart, collectés un par un), de tous les gestionnaires (vManage) et de tous les validateurs (vBond) pour effectuer l'analyse.
Q : Comment le TAC détermine-t-il si mon système comporte des indicateurs de compromission associés à ces avis ?
A : Le TAC examine les fichiers admin-tech pour y trouver des indicateurs de compromission propres à chaque avis. Pour l'avis d'escalade des privilèges (CVE-2026-20245), le TAC recherche des entrées de journal spécifiques dans /var/log/scripts.log sur chaque composant de contrôle. Pour l'avis d'écriture de fichier arbitraire (CVE-2026-20262), le TAC recherche des entrées de journal spécifiques dans trois fichiers journaux sur chaque Manager : /var/log/nms/vmanage-server.log, /var/log/nms/vmanage-appserver.log et /var/log/nms/containers/service-proxy/serviceproxy-access.log. Dans les deux cas, l'activité sous-jacente peut avoir lieu au cours d'opérations standard ; toutes les entrées correspondantes sont examinées par le TAC par rapport à votre position opérationnelle normale avant d'être traitées comme un indicateur confirmé.
Q : Que se passe-t-il si des indicateurs de compromission sont identifiés ?
A : Le TAC vous contacte pour vous donner des conseils spécifiques. La mise à niveau seule ne résout pas une compromission confirmée. Les conseils du TAC sont basés sur le flux documenté dans les articles TechZone relatifs aux avis de mai 2026 et de février 2026.
Q : Les routeurs de périphérie (Cisco IOS XE) sont-ils concernés par ces avis ?
A : Ces conseils concernent principalement les composants de contrôle SD-WAN de Cisco Catalyst. Pour l'avis d'escalade des privilèges (CVE-2026-20245), tous les composants de contrôle (vManage, vSmart, vBond) sont affectés, et Cisco a observé des cas limités où l'exploitation a entraîné une modification de configuration poussée vers les périphériques de périphérie ; les utilisateurs sont invités à vérifier la configuration de leurs périphériques de périphérie. Pour l'avis d'écriture de fichier arbitraire (CVE-2026-20262), la vulnérabilité est confinée au système de fichiers du gestionnaire SD-WAN et n'affecte pas directement les périphériques de périphérie.
Q : Quels types de déploiement sont concernés ?
A : Conformément à ces avis, ces vulnérabilités affectent tous les types de déploiement SD-WAN de Cisco Catalyst, quelle que soit la configuration des périphériques, notamment le déploiement sur site, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud (géré par Cisco) et Cisco SD-WAN for Government (FedRAMP).
Q : J'ai déjà effectué une mise à niveau pour les avis de mai 2026 et de février 2026 et aucun indicateur de compromission n'a été identifié pour ces événements. Suis-je exposé à ces nouvelles vulnérabilités ?
A : Si vos composants de contrôle exécutent une version fixe pour CVE-2026-20182 et CVE-2026-20127 et qu'aucun indicateur de compromission n'a été identifié pour ces événements précédents dans les fichiers admin-tech examinés, les chemins d'exploitation non authentifiés connus pour CVE-2026-20245 et CVE-2026-20262 sont atténués sur ces périphériques spécifiques, en fonction des fichiers examinés. Cela n'élimine pas l'exposition lorsqu'un pirate détient des informations d'identification valides. Cisco vous recommande d'effectuer une mise à niveau vers une version fixe pour ces conseils.
Q : Puis-je effectuer la vérification moi-même au lieu d'attendre le TAC ?
A : Les utilisateurs qui ne peuvent pas partager admin-techs peuvent effectuer l'étape de vérification manuelle décrite dans l'annexe. Le résultat est préliminaire ; documenter les résultats et les partager avec le TAC, qui effectue l'évaluation officielle.
Q : Quelles sont les meilleures pratiques générales pour renforcer ma superposition SD-WAN ?
A : Reportez-vous au Guide de durcissement SD-WAN de Cisco Catalyst pour connaître les meilleures pratiques.
Q : Le TAC Cisco fournit-il des services d'analyse ou d'investigation pour ces vulnérabilités ?
A : Le TAC Cisco peut aider les utilisateurs en examinant les fichiers admin-tech pour les indicateurs de compromission documentés dans les deux avis PSIRT. Le TAC de Cisco n'effectue pas d'analyse approfondie ni d'enquête sur les incidents. Pour effectuer un travail d'investigation complet ou des enquêtes de sécurité détaillées, les utilisateurs sont encouragés à faire appel à leur société de réponse aux incidents (IR) tierce préférée.
| Révision | Date de publication | Commentaires |
|---|---|---|
8.0 |
22-Jun-2026
|
Étapes de vérification mises à jour pour une version antérieure à 20.9 |
7.0 |
16-Jun-2026
|
Mise à jour des annexes pour inclure des informations supplémentaires |
6.0 |
16-Jun-2026
|
Information ajoutée pour CVE-2026-20262 |
5.0 |
12-Jun-2026
|
Versions logicielles corrigées ajoutées. |
4.0 |
11-Jun-2026
|
image 26.1.1.2 publiée |
3.0 |
10-Jun-2026
|
Ajout de la version fixe 20.18.3.1 |
2.0 |
05-Jun-2026
|
Mise à jour de documentation |
1.0 |
05-Jun-2026
|
Première publication |