KEV ajoute Arista VeloCloud et FortiOS : pourquoi le CVSS est le mauvais critère de tri

Le 27 juillet 2026, la CISA a ajouté deux vulnérabilités au catalogue des vulnérabilités activement exploitées (KEV). La première est une injection de commandes non authentifiée, de sévérité maximale, dans un orchestrateur SD-WAN. La seconde est une divulgation d'information de sévérité moyenne dans un système d'exploitation de pare-feu. Si votre file de correctifs est triée par CVSS, la première passe en tête de liste et la seconde atterrit quelque part au milieu du sprint suivant.

Cet ordonnancement se défend sur le papier et se révèle faux en pratique. Le rapprochement de ces deux entrées illustre bien pourquoi.

CVE-2026-16812 : un CVSS 10.0 dans le plan de contrôle SD-WAN

CVE-2026-16812 est une injection de commandes système (CWE-78) dans VeloCloud Orchestrator On-Prem d'Arista, scorée 10.0 en CVSS v3.1 comme en v4.0. La cause racine est architecturale : des fonctions internes privilégiées, destinées uniquement à être accessibles par des composants internes de confiance, sont exposées via l'interface web. Un attaquant disposant d'un accès réseau à cette interface n'a besoin d'aucun identifiant, d'aucune interaction utilisateur, et affronte une complexité d'attaque faible pour exécuter des commandes système arbitraires sur l'hôte de l'orchestrateur.

Ce qui fait de l'orchestrateur une cible lourde de conséquences, c'est ce qu'il contrôle. Une exploitation réussie affecte la confidentialité, l'intégrité et la disponibilité du VCO lui-même ainsi que des données réseau qu'il gère, y compris les équipements VeloCloud Edge connectés. Un attaquant qui maîtrise l'orchestrateur n'a pas besoin d'attaquer chaque équipement d'agence séparément : d'une seule position, il peut modifier des configurations, lire des informations sensibles et perturber la gestion du SD-WAN.

Arista a confirmé que la faille avait été découverte en externe et qu'elle était activement exploitée, sans préciser la date du signalement ni le nombre de clients touchés. Les versions on-prem concernées sont celles antérieures à 5.2.3.14, 6.1.3.4, 6.4.2.4 et 7.0.0.1 ; les offres Hosted et Dedicated VCO ont été corrigées avant la divulgation publique.

Le détail à traiter immédiatement : Arista a publié trois adresses IP liées aux attaques observées — 8.19.75.217, 206.72.242.124 et 206.72.242.162 — en conseillant de les bloquer et de contrôler les journaux à la recherche de signes de compromission.

CVE-2025-68686 : le contournement de correctif que personne ne place en tête

Le second ajout est plus discret et, pour certaines organisations, plus immédiatement dangereux. CVE-2025-68686 est une faille de divulgation d'information sensible (CWE-200) dans Fortinet FortiOS, scorée CVSS 5,3. Elle affecte FortiOS 7.6.0 à 7.6.1, 7.4.0 à 7.4.6 et toutes les versions 7.2, 7.0 et 6.4, avec des correctifs disponibles en 7.6.2 et 7.4.7.

Son importance ne tient pas au score. Il s'agit d'un contournement de correctif qui rétablit une technique de persistance par lien symbolique employée par des attaquants à la suite d'une compromission FortiOS antérieure. Autrement dit : une organisation qui a été compromise, a appliqué le correctif initial et a clôturé l'incident peut continuer à laisser à l'attaquant d'origine un accès en lecture à des fichiers sensibles de l'équipement.

Cette situation — corrigée sur le papier, persistante dans les faits — n'apparaît pas dans un score de sévérité. Elle apparaît dans l'écart entre « nous avons corrigé » et « nous avons vérifié que l'attaquant est parti ».

Pourquoi ce couple plaide contre les files triées par sévérité

Placez les deux côte à côte et le classement s'inverse selon votre environnement plutôt que selon les CVE :

• Si vous n'exploitez pas VeloCloud Orchestrator On-Prem, le CVSS 10.0 n'est pas votre problème. Il vous coûte une requête dans votre inventaire et rien de plus.
• Si vous exploitez FortiOS et qu'une compromission figure dans votre historique d'incidents, le CVSS 5,3 est une question de persistance active qui mérite de l'attention cette semaine, pas au trimestre suivant.
• Si vous exploitez les deux, l'orchestrateur l'emporte en urgence parce qu'il est non authentifié et joignable à distance — mais la vérification FortiOS est peu coûteuse et répond à une question portant sur vos dossiers d'incidents existants plutôt que sur un risque futur.

Le principe général : la sévérité décrit la vulnérabilité, l'exposition vous décrit. L'appartenance à KEV vous dit que l'exploitation est réelle, ce qui supprime l'incertitude sur la vraisemblance, mais elle ne vous dit pas si le produit concerné se trouve sur votre périmètre. Seul votre inventaire le fait.

C'est aussi pourquoi le cadrage par le risque retenu par la CISA compte davantage que le score brut. L'agence a fixé des échéances de remédiation pour ces entrées — la faille FortiOS au 10 août 2026 — et l'instruction sous-jacente est de prioriser les mises à jour de sécurité selon le risque, non selon le seul classement par sévérité.

Le schéma de juillet 2026 : équipements de périphérie et infrastructure d'identité

Ces deux ajouts ne sont pas arrivés isolément. Sur l'ensemble de juillet 2026, les entrées KEV se sont regroupées autour de la même catégorie d'actifs :

• Arista VeloCloud Orchestrator On-Prem — plan de contrôle SD-WAN, injection de commandes non authentifiée.
• Fortinet FortiOS — système du pare-feu et du VPN SSL, contournement de persistance.
• Équipements SonicWall SMA1000 — CVE-2026-15409, une falsification de requête côté serveur non authentifiée scorée CVSS 10.0, et CVE-2026-15410, une injection de code post-authentification scorée 7,2, toutes deux confirmées exploitées en zero-day par le PSIRT de SonicWall.
• Microsoft Active Directory Federation Services — CVE-2026-56155, granularité insuffisante du contrôle d'accès.
• Microsoft SharePoint Server — CVE-2026-56164, absence d'authentification sur une fonction critique.

Les équipements d'accès distant, les orchestrateurs SD-WAN et les services de fédération ont une propriété commune : ils sont joignables depuis Internet par conception et ils arbitrent l'accès à tout ce qui se trouve derrière eux. Ce sont aussi les actifs les plus susceptibles d'être exclus de l'outillage de détection sur les terminaux, ce qui explique précisément pourquoi une compromission y passe inaperçue.

À noter en parallèle : le Patch Tuesday de juillet 2026 de Microsoft a traité un nombre record de 621 CVE, dont deux exploitées en zero-day. Un mois qui produit 621 correctifs est un mois où les files triées par sévérité garantissent qu'une faille exploitée finira enterrée. La preuve d'exploitation est le seul critère de tri qui résiste à ce volume.

Quoi faire cette semaine

La réponse se divise nettement en un volet correctifs et un volet recherche.

1. Établissez d'abord l'exposition. Interrogez votre inventaire sur VeloCloud Orchestrator On-Prem, FortiOS dans les plages de versions concernées, SonicWall SMA1000, ainsi que sur les instances ADFS ou SharePoint exposées sur Internet. L'exposition détermine tout le reste.
2. Corrigez vers les versions correctives précises, et non vers « une version plus récente ». Faites passer le VCO sur une build corrigée 5.2, 6.1, 6.4 ou 7.0 ; faites passer FortiOS en 7.6.2 ou 7.4.7 et migrez les branches non supportées vers une branche supportée.
3. Bloquez et recherchez les indicateurs publiés. Les trois adresses IP d'Arista ont leur place dans vos contrôles en entrée comme en sortie, et dans une requête rétrospective sur les journaux remontant plus loin que vous ne le jugez nécessaire.
4. Rouvrez les incidents FortiOS clôturés. Si un équipement a déjà été compromis, vérifiez spécifiquement le chemin de persistance par lien symbolique au lieu de supposer que le correctif antérieur l'a résolu.
5. Présumez une compromission antérieure au correctif sur tout actif listé dans KEV et exposé sur Internet. Une entrée KEV signifie que l'exploitation a précédé votre fenêtre de correction : corriger fixe la fin de la fenêtre d'exposition, pas son début.

Transformer KEV en alerte plutôt qu'en tâche de lecture

Le mode de défaillance opérationnel de KEV n'est pas un désaccord sur son intérêt, mais la latence. Une mise à jour du catalogue n'est utile que si quelqu'un la remarque, la confronte au parc et repriorise avant que la fenêtre d'exploitation ne se referme. Fait à la main, c'est un rituel hebdomadaire au mieux.

CVE Watch existe pour supprimer cette étape : les produits déclarés sont rapprochés des enregistrements CVE avec leur statut KEV et EPSS attaché, si bien qu'une nouvelle entrée exploitée touchant un produit que vous utilisez remonte comme un finding et non comme un titre d'actualité lu par hasard. Les équipes qui associent cela à une priorisation fondée sur EPSS obtiennent un ordonnancement qui reflète la probabilité d'exploitation plutôt que l'impact théorique.

Côté recherche, les indicateurs publiés par l'éditeur constituent le point de départ le plus utile disponible, et la liste est généralement courte. Passez les trois adresses d'Arista par une recherche de réputation IP pour obtenir le contexte d'hébergement et d'ASN aux côtés de tout historique malveillant antérieur, et contrôlez le reste de ce qui apparaît dans les journaux d'équipements via une recherche en masse plutôt qu'onglet par onglet. Brancher cet enrichissement sur votre SIEM au moyen de l'API fait arriver l'alerte suivante avec le contexte déjà attaché, ce qui distingue une habitude d'une chasse ponctuelle.