CVSS 9.6 : faille frappe les load balancers 792 fois

Cinq semaines d'attaques avant l'alerte

La société de sécurité watchTowr a publié une analyse technique et un code de preuve de concept pour CVE-2026-8037 le 29 juin 2026, moins d'un mois après que Progress Software a révélé la faille le 4 juin. Dès le lendemain, l'équipe de réponse aux menaces d'eSentire enregistrait déjà des tentatives d'exploitation contre les boîtiers Progress Kemp LoadMaster, une faille d'injection de commandes non authentifiée notée CVSS 9.6.

Lorsque l'agence américaine de cybersécurité CISA a ajouté la faille à son catalogue des vulnérabilités activement exploitées le 7 août 2026, la télémétrie compilée par eSentire et KEVIntel faisait déjà état de 792 tentatives d'exploitation en 41 jours, provenant de 65 adresses IP distinctes dans 18 pays, dont l'Australie, la Chine, l'Indonésie, le Japon, la Pologne et les États-Unis. La CISA a laissé aux agences civiles fédérales américaines jusqu'au 10 août 2026, seulement trois jours, pour corriger conformément à la directive opérationnelle contraignante 26-04. Mais l'écart le plus significatif n'a pas été ce délai de trois jours : il s'agit des cinq semaines et demie environ entre la première attaque réelle et le moment où l'inscription au KEV a imposé le sujet à l'agenda de la plupart des équipes de sécurité.

Pourquoi un répartiteur de charge est une cible peu surveillée

Un répartiteur de charge n'est pas un système périphérique. Il termine ou relaie généralement le trafic de chaque application exposée au public qu'une organisation exploite, ce qui lui confère une visibilité réseau et un contrôle du routage que peu d'autres équipements possèdent. Le compromettre donne à l'attaquant un point d'appui avec une vue sur tout ce qui se trouve derrière, bien au-delà de la simple mise hors service d'un site web.

Malgré cette exposition, les répartiteurs de charge et équipements réseau similaires sont couramment corrigés à un rythme plus lent que les applications web qu'ils protègent. Les équipes réseau et infrastructure les traitent souvent comme de la plomberie qui, une fois configurée, ne doit pas être touchée en dehors d'une fenêtre de maintenance planifiée. C'est précisément cette habitude qui rend une faille d'exécution de code à distance non authentifiée comme CVE-2026-8037 aussi dangereuse : l'équipement le plus exposé à internet est souvent celui qui a le moins de chances d'être corrigé en urgence.

La faille en détail : une fonction de nettoyage qui ne nettoie pas

CVE-2026-8037 réside dans une fonction nommée escape_quotes, dont le rôle est de retirer les caractères dangereux des entrées utilisateur avant qu'elles n'atteignent une commande shell. La fonction ne le fait pas complètement, et la faille est accessible via le point d'API /accessv2 dès lors que l'API de LoadMaster est activée. L'attaquant n'a besoin d'aucun identifiant : une requête spécialement construite suffit à faire exécuter des commandes arbitraires par le boîtier.

Sont concernées la version GA de LoadMaster 7.2.63.1 et antérieures, ainsi que la version LTSF 7.2.54.17 et antérieures. Progress Software a également confirmé le même défaut sous-jacent dans les versions de MOVEit WAF antérieures à GA 7.2.63.2. Des versions corrigées sont disponibles : LoadMaster GA 7.2.63.2 et LoadMaster LTSF 7.2.54.18. Il n'existe pas d'alternative à l'application de ces correctifs ; désactiver l'API lorsqu'elle n'est pas nécessaire réduit l'exposition mais ne referme pas la faille pour les déploiements qui en dépendent.

Pourquoi c'est un déclencheur NIS2, pas un simple ticket de correctif

Pour les organisations classées entités essentielles ou importantes au titre de la directive NIS2 de l'UE, une vulnérabilité d'exécution de code à distance non authentifiée sur un équipement d'infrastructure exposé sur internet est presque un cas d'école de ce pour quoi les règles de notification d'incidents de la directive ont été écrites. Un répartiteur de charge situé en bordure de réseau, accessible sans identifiants et dont l'exploitation active est confirmée, remplit pratiquement tous les critères que des régulateurs comme l'ANSSI utilisent pour définir un incident important : une atteinte à la confidentialité, à l'intégrité ou à la disponibilité susceptible de causer un dommage opérationnel ou financier considérable.

Cela a une conséquence pratique au-delà du simple correctif. Si un boîtier LoadMaster relevant du champ de NIS2 était exposé sur internet et exécutait une version vulnérable pendant la fenêtre d'exploitation, le délai de notification court peut-être déjà, indépendamment du fait qu'une compromission ait été confirmée ou non. Attendre une certitude médico-légale avant d'évaluer les obligations de notification est une erreur fréquente et coûteuse.

Ce que les propriétaires doivent faire cette semaine

Toute organisation exploitant un boîtier Kemp LoadMaster en GA 7.2.63.1 ou antérieure, ou en LTSF 7.2.54.17 ou antérieure, doit corriger immédiatement et prioriser les instances exposées sur internet. Il ne faut pas attendre une fenêtre de maintenance planifiée : la télémétrie d'exploitation montre que les attaquants scannent déjà largement et sans distinction, si bien que les boîtiers non corrigés sont trouvés par des balayages automatisés.

Au-delà de ce correctif ponctuel, l'écart de cinq semaines entre la première exploitation et l'inscription au KEV mérite de servir de déclencheur pour revoir la façon dont l'organisation suit les alertes éditeurs spécifiquement pour les équipements réseau et infrastructure, une catégorie que les programmes de gestion des correctifs centrés sur les logiciels applicatifs négligent souvent. Un programme de gestion des correctifs qui n'escalade que lorsqu'un élément apparaît sur une liste gouvernementale de vulnérabilités exploitées est, par définition, toujours en retard sur les attaquants qui ont trouvé la faille en premier.

À lire ensuite: 45 601 failles, 171 sont vraiment exploitées  |  Un bâtiment inutilisable coûte plus qu'une rançon