Arista VeloCloud Orchestrator CVE-2026-16812 : RCE 10.0 exploitée sur le SD-WAN

CVE-2026-16812 (CVSS 10.0) affecte VeloCloud Orchestrator (VCO) on-premises — la console d'orchestration du SD-WAN anciennement commercialisée par VMware, aujourd'hui dans le portefeuille Arista après acquisition. Une fonctionnalité interne, jamais destinée à être accessible depuis le réseau, est joignable à distance et permet une injection de commandes OS sur l'hôte VCO.

Le point le plus lourd de l'advisory est cette phrase de l'éditeur :

This issue was discovered externally and is known to be actively exploited.

Ajout au catalogue CISA KEV le 27 juillet 2026, avec une échéance de remédiation à trois jours.

Détails techniques

Le bug

L'advisory Arista décrit une fonctionnalité privilégiée exposée par erreur :

VeloCloud Orchestrator (VCO) on-prem has a security issue where this issue may allow a remote attacker to access privileged internal functionality and impact the VCO host. Successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.

This functionality was intended to be for internal use only and is not intended to be remotely accessible.

Le catalogue CISA précise la nature : injection de commandes OS. Autrement dit, un endpoint interne — probablement destiné à la communication entre composants du VCO ou à des opérations de maintenance — accepte des requêtes distantes et transmet des paramètres à un appel système.

C'est un défaut d'architecture plus que de code : de la fonctionnalité de confiance exposée sur une frontière non fiable. Le vecteur en découle mécaniquement — pas d'authentification, complexité faible, et un scope changé (S:C) parce que la compromission dépasse largement le processus VCO.

Pourquoi le 10.0 est justifié ici

Le score maximal n'est pas un artefact de calcul. Un VCO compromis, c'est le plan de contrôle de tout ton WAN :

• Il pousse la configuration vers l'ensemble des edges (les boîtiers en agence, en usine, en filiale)
• Il définit les politiques de routage, de QoS, et de sécurité appliquées au trafic inter-sites
• Il détient les credentials et les certificats d'appairage des edges
• Il a une visibilité totale sur les flux de l'organisation

Produits et versions affectés

Ces valeurs correspondent aux bornes exposées par NVD et ressemblent aux versions correctives par branche. Consulte l'advisory Arista officiel pour identifier la version exacte à installer selon ta branche.

Ce qui n'est pas affecté

Hosted and Dedicated versions of VCO have already been patched in advance of this notice going out.

Si ton VCO est hébergé par Arista (Hosted ou Dedicated), l'éditeur a corrigé en amont de la divulgation : tu n'as rien à faire. Le risque porte exclusivement sur les déploiements on-premises, que tu opères toi-même.

C'est une distinction à vérifier avant de déclencher une cellule de crise : beaucoup d'organisations ne savent pas immédiatement dans quel mode leur VCO tourne.

Exploitation et impact

Ce qu'un attaquant obtient

Une exécution de commandes sur l'hôte VCO ouvre plusieurs voies, par ordre de gravité croissante :

1. Reconnaissance complète du WAN — inventaire de tous les sites, plans d'adressage, topologie, volumétrie des flux. Une cartographie que même un audit interne met des semaines à produire.
2. Vol des secrets d'appairage — les certificats et clés qui autorisent un edge à rejoindre l'overlay. Avec eux, un attaquant peut introduire son propre edge malveillant dans le réseau de l'entreprise.
3. Modification des politiques — rerouter le trafic d'un site vers une infrastructure sous son contrôle (donc l'intercepter), désactiver le chiffrement de l'overlay, ou ouvrir des flux normalement interdits entre segments.
4. Déni de service à l'échelle du WAN — pousser une configuration invalide sur tous les edges simultanément coupe la connectivité inter-sites de l'organisation entière. Pour un industriel ou un réseau d'agences, l'impact est immédiat et chiffrable à l'heure.
5. Pivot — le VCO est sur le réseau de management, généralement le segment le mieux connecté et le moins filtré.

Le point de bascule : « exploitée activement »

La formulation de l'éditeur ne laisse pas de place au doute. Combinée à l'échéance CISA de trois jours, elle signifie que des instances VCO exposées sont actuellement scannées et compromises. Il n'y a pas de fenêtre d'observation confortable ici.

Détection et IOC

Journaux VCO

Recherche les traces d'accès aux endpoints internes depuis des sources externes :

• Requêtes HTTP vers des chemins non documentés dans l'API publique du VCO
• Réponses 200 sur des endpoints qui ne devraient recevoir que du trafic inter-composants
• Requêtes contenant des métacaractères shell (;, |, `, $() dans leurs paramètres

Sur l'hôte VCO

# Processus enfants inattendus du service VCO
ps -ef --forest | grep -A5 -i velocloud

# Fichiers récents dans les répertoires temporaires
find /tmp /var/tmp /dev/shm -type f -mtime -45 -ls 2>/dev/null

# Persistance
crontab -l
ls -la /etc/cron.d/
systemctl list-unit-files --state=enabled | grep -vE "^(sshd|network|velocloud)"

Trafic réseau

Le signal le plus fiable : le VCO a un profil de communication très prévisible (les edges, l'IdP, les dépôts de mise à jour). Toute connexion sortante vers une destination hors de cette liste mérite investigation.

Intégrité de la configuration

Compare la configuration poussée aux edges avec ta dernière sauvegarde de référence. Une modification de politique non corrélée à un changement documenté est un indicateur de compromission majeur — et c'est précisément l'action qu'un attaquant cherche à réaliser.

Mitigation et patch

1. Identifier ton mode de déploiement

Avant toute chose : Hosted/Dedicated (rien à faire) ou on-prem (action urgente) ?

2. Patcher — en urgence

Récupère la version corrigée de ta branche sur le portail support Arista et applique-la. Vu l'exploitation active et l'échéance CISA du 30 juillet, ceci ne relève pas de la fenêtre de maintenance mensuelle.

3. Isoler l'interface d'administration immédiatement

C'est la mitigation la plus efficace à court terme, applicable avant même le patch. Le VCO ne doit pas être joignable depuis Internet ni depuis les VLAN utilisateurs :

# Exemple iptables — restreindre l'admin aux IP de management
iptables -A INPUT -p tcp --dport 443 -s <cidr-management> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Attention à conserver la joignabilité depuis les edges, qui doivent continuer à dialoguer avec l'orchestrateur — filtre sur les IP sources connues plutôt que de tout couper.

4. Après le patch : traiter l'hypothèse de compromission

Si ton VCO on-prem était exposé, le patch ne clôt pas le sujet :

1. Fais tourner les credentials d'administration du VCO
2. Régénère les certificats et secrets d'appairage des edges si ton architecture le permet
3. Vérifie l'intégrité de la configuration poussée à chaque edge par comparaison avec une référence
4. Audite la liste des edges enregistrés — un edge inconnu est un accès permanent au réseau
5. Chasse la persistance sur l'hôte (cron, systemd, binaires modifiés)

5. Durcissement durable

• VCO sur un VLAN de management strict, accessible uniquement via bastion
• Journaux exportés vers un SIEM externe en temps réel — un attaquant root effacera les logs locaux
• Sauvegarde régulière et hors-ligne de la configuration, pour pouvoir détecter les dérives et restaurer

Pourquoi surveiller en continu vos plans de contrôle

Il existe une catégorie d'équipements dont la compromission ne touche pas un service mais toute l'infrastructure : orchestrateurs SD-WAN, contrôleurs Wi-Fi, hyperviseurs, consoles de firewall, gestionnaires de certificats. Ces systèmes partagent trois traits : peu nombreux (donc oubliés des inventaires), sans agent (donc invisibles aux scans classiques), et opérés par une petite équipe spécialisée qui ne suit pas forcément les advisories au quotidien.

C'est exactement le profil dans lequel une CVE 10.0 exploitée activement peut rester non patchée plusieurs semaines.

Avec cveo.tech, inventorie tes plans de contrôle réseau au même titre que tes serveurs et reçois une alerte automatique dès qu'une CVE critique cible une de tes versions exactes — avec le statut CISA KEV mis en avant, pour distinguer immédiatement ce qui est théorique de ce qui est déjà exploité.