Arista corrige un CVSS 10 activement exploité dans VeloCloud Orchestrator
Le 22 septembre 2026, CISA a inscrit au catalogue KEV une faille d’input validation notée CVSS 10 dans l’orchestrateur VeloCloud on-prem d’Arista, exploitable sans identifiant. Restreignez l’accès réseau à l’interface web du VCO et appliquez le correctif avant le 25 septembre.
22 septembre 2026. CISA inscrit CVE-2026-93952 à son catalogue KEV — la liste des failles exploitées dans la nature — avec une échéance fédérale fixée au 25 septembre 2026. 22 septembre 2026. Arista publie l’avis de sécurité SA-0183 : une faille d’input validation dans VeloCloud Orchestrator (VCO) on-prem permet à un attaquant distant d’accéder à des fonctionnalités internes privilégiées « sans identifiant ni compte opérateur ». 22 septembre 2026. Le NVD note la vulnérabilité CVSS 10.0, le score maximal. Pourquoi c’est important : le VCO est le plan de contrôle du SD-WAN — celui qui orchestre les tunnels de tous les routeurs de bordure d’une entreprise. Le compromettre, c’est compromettre la matrice de routage d’un réseau distribué entier.
La faille : un input validation sans authentification
CVE-2026-93952 est classée CWE-20 (Improper Input Validation). Concrètement, le VCO accepte une entrée qu’il ne valide pas correctement, ce qui permet à un attaquant distant d’atteindre des fonctionnalités internes privilégiées et d’agir sur l’hôte de l’orchestrateur. L’impact est total : l’avis Arista précise qu’une exploitation réussie « peut compromettre la confidentialité, l’intégrité et la disponibilité de l’orchestrateur et des données qu’il gère ».
Le score CVSS 10.0 tient à la combinaison du vecteur réseau (AV:N), de la complexité faible (AC:L), de l’absence de privilège requis (PR:N), de l’absence d’interaction utilisateur (UI:N) et du changement de portée (S:C). Traduit : pas d’identifiant, pas de clic, un impact qui déborde du seul composant vulnérable.
Arista est explicite sur l’état de l’exploitation : la faille a été « découverte de l’extérieur et est connue comme activement exploitée ». Ce n’est pas une vulnérabilité théorique en attente d’un proof of concept — c’est une faille que des attaquants utilisent déjà.
Le VCO, c’est le cerveau du SD-WAN
Pour mesurer le risque, il faut comprendre ce qu’est un orchestrateur VeloCloud. Dans une architecture SD-WAN, le VCO est le composant central qui configure et supervise les Edges (les routeurs de bordure déployés dans les sites) et les Gateways (les concentrateurs de trafic). Il distribue les politiques de routage, négocie les tunnels, gère les certificats d’authentification entre Edge et Orchestrateur.
Compromettre le VCO, ce n’est donc pas compromettre un équipement isolé : c’est prendre la main sur la matrice de contrôle qui décide du chemin de tout le trafic d’entreprise. Un attaquant qui contrôle l’orchestrateur peut, en principe, reconfigurer les tunnels, intercepter ou dérouter des flux, et lire les données que l’orchestrateur manipule. C’est la raison pour laquelle le score 10.0 et le passage au KEV ne sont pas disproportionnés.
Le produit est l’héritier direct de VeloCloud by Broadcom — l’avis Arista désigne d’ailleurs l’appliance affectée comme « VeloCloud Orchestrator On-Prem (anciennement VeloCloud Orchestrator by Broadcom) ». Le périmètre touché est le VCO on-prem : les instances hébergées et dédiées ont, elles, « déjà été corrigées », selon l’avis.
Ce qu’exige l’exploitation, et pourquoi ça ne rassure pas
L’avis Arista détaille les conditions requises pour l’exploitation. Trois éléments doivent être réunis : l’authentification par certificat entre le VeloCloud Edge et le VCO doit être configurée ; l’attaquant doit disposer de l’accès à la partie publique du certificat d’authentification de l’Edge ; et il lui faut un accès réseau à l’interface web du VCO. Aucun identifiant de locataire ni d’opérateur n’est exigé.
À première vue, ces prérequis rétrécissent la surface. En réalité, ils décrivent l’état par défaut de nombreux déploiements. L’authentification par certificat Edge→VCO est précisément le mécanisme standard par lequel les Edges s’enregistrent auprès de l’orchestrateur. La « partie publique » d’un certificat est, par définition, destinée à circuler. Et une interface web de gestion exposée — directement sur Internet ou sur un VLAN de gestion trop large — est une configuration que l’on rencontre encore fréquemment sur les appliances d’orchestration.
La leçon est double. D’abord, une input validation triviale sur un plan de contrôle suffit à produire un CVSS 10.0 quand la cible est aussi centrale. Ensuite, le correctif de premier niveau n’est pas technique mais réseau : Arista recommande de restreindre l’accès à l’interface web du VCO aux seuls réseaux d’administration de confiance.
Versions concernées et correctif
Le tableau des versions affectées est net : toute la plage antérieure aux correctifs dans quatre trains de versions est vulnérable.
| Train | Versions vulnérables |
|---|---|
| 5.2.x | 5.2.3.15 et inférieures |
| 6.1.x | 6.1.3.7 et inférieures |
| 6.4.x | 6.4.2.7 et inférieures |
| 7.0.x | 7.0.0.2 et inférieures |
La faille est suivie en interne sous les références BUG1907167 et BUG1937417. La correction passe par la mise à niveau vers une version postérieure à ces seuils, en commençant par les instances qui pilotent les Edges en production. Les équipes qui exploitent un VCO on-prem doivent traiter le 25 septembre 2026 — l’échéance KEV — comme une date ferme, et pas seulement parce qu’elle contraint les agences fédérales américaines sous la directive BOD 26-04.
Avant même la mise à jour, la parade immédiate est une restriction d’accès au niveau du pare-feu qui précède l’orchestrateur :
# Restreindre l'interface web de gestion du VCO aux seuls réseaux d'administration.
# À adapter au port réel de l'interface (443 par défaut) et à votre plan d'adressage.
iptables -A INPUT -p tcp --dport 443 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROPSi la commande de rejet n’est pas positionnée, l’interface reste joignable depuis tout réseau qui la route — exactement la condition d’exploitation décrite par l’avis.
Détecter une compromission du VCO
L’avis Arista prévient qu’il n’existe « pas d’indicateur de compromission unique et définitif ». La détection doit donc s’appuyer sur un faisceau de signaux plutôt que sur une signature unique. Trois familles d’observables méritent une attention particulière.
D’abord, l’accès réseau. Puisque l’exploitation exige un accès à l’interface web du VCO, toute connexion depuis une adresse IP inhabituelle — un sous-réseau qui n’appartient pas au périmètre d’administration — est un signal de premier ordre. Les journaux d’accès de l’orchestrateur doivent être centralisés et corrélés avec la liste des réseaux autorisés.
Ensuite, la configuration. Le VCO distribue les politiques de routage et gère les certificats des Edges. Une compromission se manifestera souvent par des changements inattendus : modification d’une politique de tunnel, émission d’un nouveau certificat d’authentification, apparition d’un Edge inconnu dans l’inventaire. Comparer régulièrement l’état de l’orchestrateur à une référence connue est plus fiable que d’attendre une alerte.
Enfin, l’hôte. L’attaquant accède à des « fonctionnalités internes privilégiées » : un processus inattendu, une connexion sortante vers une infrastructure inhabituelle ou une élévation de privilèges sur la machine de l’orchestrateur sont autant d’indices à traiter comme une compromission potentielle, pas comme un incident de performance.
La parade la plus efficace reste la réduction de la surface : si l’interface web du VCO n’est joignable que depuis un bastion ou un VLAN d’administration dédié, l’exploitation décrite par l’avis devient impraticable, quelle que soit la version du logiciel.
Verdict
CVE-2026-93952 appartient à la catégorie la plus dangereuse : un zero-day exploité sur un plan de contrôle réseau, avec un score maximal et une exploitation sans identifiant. Si vous exploitez un VCO on-prem, appliquez le correctif de votre train de version avant le 25 septembre, et en attendant, restreignez l’interface web aux seuls réseaux d’administration — c’est la mitigation que l’avis Arista place en premier. Si vous êtes en instance hébergée ou dédiée, vérifiez auprès de votre fournisseur que la correction est bien déployée, mais ne considérez pas le risque comme nul pour autant : un plan de contrôle SD-WAN reste une cible de choix, comme l’a montré la série récente de failles sur les équipements de bordure que nous suivons de près, du F5 BIG-IP au MikroTik RouterOS.