VeloCloud Orchestrator : du compte ordinaire au superuser par injection SQL

Avis Arista du 22 octobre 2026. Arista déclare CVE-2026-114625 activement exploitée. La faille est une injection SQL dans VeloCloud Orchestrator. Elle permet à n’importe quel utilisateur authentifié, même de faible privilège, de prendre les droits d’un opérateur local superuser et d’atteindre des fonctions internes normalement non exposées à distance. Le mot « authentifié » est décisif : l’avis ne décrit pas une prise de contrôle par un visiteur sans compte.

Pourquoi l’injection SQL franchit aussi une frontière d’identité

Une injection SQL apparaît lorsqu’une application assemble une commande de base de données avec une valeur non fiable, au lieu de transmettre cette valeur comme paramètre séparé. La base peut alors interpréter une partie de l’entrée comme structure de requête. Le résultat dépend de la requête vulnérable et des droits de son compte SQL : lecture de lignes, modification de valeurs ou contournement d’un filtre. Pour VeloCloud, Arista publie le résultat de sécurité : un compte ordinaire peut se faire passer pour un superuser operator. Elle ne publie pas la requête SQL, le champ injecté ou un PoC ; nous ne pouvons donc pas prétendre connaître la charge exacte qui produit l’usurpation.

Le saut de privilège est critique parce que l’orchestrateur porte le plan de contrôle d’un réseau SD-WAN. Les droits d’opérateur couvrent des fonctions qui n’étaient pas destinées à l’utilisateur distant ordinaire. Arista affirme que la confidentialité, l’intégrité et la disponibilité de l’orchestrateur et des données qu’il gère peuvent être compromises. Le contenu précis de chaque déploiement et les actions effectuées par les acteurs observés restent hors du bulletin.

Comment établir le défaut sans inventer de PoC

Dans un audit autorisé, il faut créer au moins deux rôles : un utilisateur de faible privilège et un superuser de référence. On inventorie les appels que le premier peut atteindre, puis on suit leurs requêtes SQL et les décisions d’autorisation résultantes. Une entrée qui modifie la structure de la requête, l’identité retournée ou les fonctions accessibles est un signal. Le correctif doit être évalué à deux niveaux : paramétrage des requêtes et contrôle d’autorisation indépendant du résultat d’une recherche en base.

Cette méthode décrit une famille de tests, pas la découverte réelle de la CVE. Le bulletin Arista indique que la faille a été détectée par l’entreprise et qu’elle est exploitée, mais ne fournit pas de démonstration publique assez détaillée pour attribuer un endpoint ou une technique d’encodage. Publier un exemple de SQL présenté comme « l’exploit VeloCloud » serait donc une invention.

Périmètre et réponse

Le bulletin distingue VCO on-premise des instances hébergées, y compris dédiées, qu’Arista dit avoir déjà corrigées. Pour l’on-premise, il faut comparer la version réellement installée au tableau de versions affectées de l’avis Arista, puis examiner les comptes ordinaires, les activités d’opérateur, les changements de configuration et les journaux d’accès aux fonctions internes. La correction ferme le chemin d’injection ; elle ne supprime pas une identité privilégiée ou une configuration modifiée pendant l’exploitation.

Le cas montre qu’une SQL injection ne se résume pas à « lire une table ». Si l’application utilise la base pour déterminer l’identité et les privilèges, une requête falsifiée peut déplacer l’attaquant d’un rôle limité vers le plan de contrôle entier.

Source principale : Arista Security Advisory 0199.