Une injection SQL dans VeloCloud Orchestrator transforme un compte en lecture seule en super-utilisateur
Le 22 octobre 2026, Arista révèle que l’orchestrateur SD-WAN VeloCloud (VCO) on-prem est victime d’une injection SQL activement exploitée : n’importe quel utilisateur authentifié, jusqu’au rôle Enterprise Read Only, devient le super-utilisateur operator. Si vous hébergez un VCO, montez immédiatement vers les versions corrigées et partez du principe que chaque compte, y compris en lecture seule, a pu être abusé.
27 juillet 2026. Arista corrige une injection de commandes non authentifiée dans VeloCloud Orchestrator, CVE-2026-16812, notée CVSS 10.0. 22 septembre 2026. Deuxième zero-day, CVE-2026-93952, encore CVSS 10.0. 22 octobre 2026. Troisième alerte en quatre mois : l’avis SA-0199 documente CVE-2026-114625, une injection SQL cette fois activement exploitée, qui élève un compte en lecture seule au rang de super-utilisateur operator. Le point clé : ce n’est plus une faille qu’on comble faute de mieux, c’est la troisième fois que le plan de gestion du SD-WAN est pris pour cible — et la troisième fois qu’il n’existe aucun contournement par configuration.
Une élévation de privilèges sans condition exotique
VeloCloud Orchestrator (VCO) est le plan de gestion du SD-WAN VeloCloud. Il concentre la configuration de chaque Edge et de chaque Gateway du parc, ainsi que les comptes tenant par lesquels clients, partenaires et MSP lisent ou modifient cette configuration. C’est exactement la pièce qu’un attaquant veut tenir : de là, il touche la connectivité de toutes les succursales d’un coup.
La faille est une CWE-89, une injection SQL suivie en interne sous le numéro BUG2043622. D’après l’avis SA-0199, révision 1.0, « tout utilisateur authentifié peut obtenir des privilèges operator et se faire passer pour l’utilisateur local superuser operator ». La fonctionnalité atteinte est « destinée à un usage interne uniquement » et n’est pas censée être accessible à distance.
Les prérequis tiennent en deux lignes. Il faut un accès réseau à l’interface web du VCO et une session authentifiée sur le portail. Le rôle minimal requis est Enterprise Read Only — celui qu’Arista décrit comme « le rôle locataire intégré le plus bas ». Autrement dit, le compte le plus faible du produit suffit à prendre le contrôle du produit entier.
Le vecteur CVSS v3.1 est sans ambiguïté : AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, soit 9.9 en 3.1 et 9.4 en 4.0. Le PR:L traduit la seule barrière : il faut être connecté. La portée changée (S:C) dit le reste — l’impact déborde du composant vulnérable vers l’hôte VCO et les données qu’il gère.
« Exposé par défaut », et aucun réglage ne l’empêche
La phrase la plus lourde de l’avis est à lire deux fois. Arista écrit que VCO est « exposé par défaut » et qu’« il n’existe aucune configuration qui puisse empêcher l’exposition ». Il n’y a pas d’interrupteur à basculer pour neutraliser la faille. Seule la montée de version la corrige.
Les correctifs sont publiés dans les trois branches supportées :
- 5.2.x avant 5.2.3.18 → corriger en 5.2.3.18 ou plus récent de la branche 5.2.
- 6.1.x avant 6.1.3.10 → corriger en 6.1.3.10 ou plus récent de la branche 6.1.
- 6.4.x avant 6.4.2.12 → corriger en 6.4.2.12 ou plus récent de la branche 6.4.
Les instances Hosted et Dedicated ont été « impactées et déjà patchées » par Arista : le travail restant incombe aux organisations qui hébergent leur propre orchestrateur. VeloCloud Gateway et VeloCloud Edge ne sont pas affectés.
Deux points de vigilance que l’avis laisse ouverts. D’abord, un VCO patché en septembre pour la faille précédente peut très bien se retrouver vulnérable à nouveau aujourd’hui, car les correctifs de juillet et de septembre ne couvrent pas forcément les mêmes branches que celui d’octobre. Ensuite, Arista n’indique ni quand l’exploitation a commencé, ni combien d’orchestrateurs ont été touchés, ni ce que les attaquants ont fait une fois operator — un silence que The Hacker News et BleepingComputer relèvent aussi.
Le troisième zero-day d’une série qui dit quelque chose
Cette faille n’est pas un accident isolé. Elle est la troisième zero-day activement exploitée sur VCO depuis fin juillet 2026 :
- CVE-2026-16812 (27 juillet) : injection de commandes OS non authentifiée, CVSS 10.0, ajoutée au catalogue KEV de la CISA le jour même.
- CVE-2026-93952 (22 septembre) : encore CVSS 10.0, « connue pour être activement exploitée », elle aussi entrée au KEV.
- CVE-2026-114625 (22 octobre) : injection SQL, CVSS 9.9, activement exploitée — mais absente du KEV au 23 octobre.
Ce dernier écart est instructif. Le 23 octobre 2026, l’enrichissement CISA ADP sur l’enregistrement CVE marque l’exploitation à « none », alors que l’avis Arista du 22 octobre affirme le contraire. En attendant la normalisation, l’avis constructeur est le signal le plus fort — et il dit clairement « exploité ».
Pour un RSSI ou un SRE, la série raconte une histoire cohérente : le plan de gestion du SD-WAN est devenu une cible de premier ordre parce qu’un seul orchestrateur commande souvent des dizaines de sites, et qu’il traîne chez des MSP qui gèrent le réseau de nombreux clients. Compromettre un VCO, c’est potentiellement compromettre la connectivité de tout un portefeuille.
Ce qu’il faut faire, dans l’ordre
Si vous hébergez un VCO on-prem, traitez cette alerte comme un changement d’urgence, pas comme un patch de routine.
- Monter de version vers 5.2.3.18, 6.1.3.10 ou 6.4.2.12 (ou plus récent dans la même branche). C’est la seule mesure qui supprime réellement la faille.
- Restreindre l’accès de l’interface web du VCO aux réseaux d’administration de confiance, et surveiller les accès depuis les adresses publiées par Arista comme indicateurs : 74.82.197.86 et 38.54.50.151.
- Auditer les comptes. Puisque n’importe quel utilisateur — y compris lecture seule, partenaire ou client — peut exploiter la faille, la surface d’attaque est chaque compte VCO, pas seulement les administrateurs. Supprimez les comptes périmés ou partagés, faites tourner les credentials et imposez MFA ou SSO là où le déploiement le permet.
- Chercher des signes de compromission avant de corriger : webshells, daemons de backdoor, activité sortante inhabituelle, modifications récentes de l’administration. Arista recommande de préserver les journaux d’accès web, applicatifs, système et base de données avant remédiation.
Si vous passez par un MSP ou un fournisseur qui exploite VeloCloud pour vous, la question utile n’est pas « utilisez-vous VeloCloud ? » mais « hébergez-vous un VCO on-prem, à quelle version, et avez-vous audité qui pouvait se connecter ? ». Un VCO Hosted est déjà patché : le risque se concentre sur les instances auto-hébergées.
Verdict
Si vous gérez un VCO on-prem, montez dès maintenant vers les versions corrigées et supposez que la faille a déjà été tentée contre vous — les deux adresses IP publiées suffisent à justifier une chasse dans vos journaux. Si vous êtes client d’un MSP, exigez en retour écrit la version exacte de son orchestrateur et la preuve qu’il a revu ses comptes, car c’est votre connectivité qui est en jeu. La leçon durable n’est pas technique : un plan de gestion réseau « exposé par défaut » est une promesse de compromission, et le troisième zero-day en quatre mois confirme que ce n’est pas un hasard.
Références
- Arista — Security Advisory 0199, révision 1.0 (22 octobre 2026)
- Rescana — Arista VeloCloud Orchestrator CVE-2026-114625 (23 octobre 2026)
- Safeguard — CVE-2026-114625 (23 octobre 2026)
- BleepingComputer — Arista patches new VeloCloud Orchestrator zero-day exploited in attacks
- The Hacker News — Arista warns of critical VeloCloud SQL injection zero-day exploited in attacks