L'équipement dont le métier est de faire détoner le malware
Une sandbox existe pour être attaquée. Vous achetez FortiSandbox pour que les fichiers suspects soient ouverts ailleurs que sur votre réseau, observés pendant qu'ils se conduisent mal, puis jugés. Elle se tient par conception exactement là où arrive ce qui n'est pas digne de confiance. C'est ce qui fait d'une injection de commandes non authentifiée dans son interface web un problème d'une autre catégorie que le même défaut sur un serveur ordinaire.
CVE-2026-25089 est exactement cela. La faille touche l'interface web de FortiSandbox, FortiSandbox Cloud et FortiSandbox PaaS et permet à un attaquant non authentifié d'exécuter des commandes non autorisées au moyen de requêtes HTTP spécialement forgées. Elle porte un score CVSS de 9.1. Fortinet l'a publiée et corrigée le 9 juin 2026.
Mi-juin l'exploitation a commencé, mi-juillet le catalogue s'en est aperçu
L'exploitation de trois failles FortiSandbox a été observée dans la nature le week-end du 14 au 16 juin environ, et un suivi indépendant a relevé l'exploitation de CVE-2026-39808 dès le 12 juin. La presse spécialisée en a rendu compte à l'époque : Help Net Security le 16 juin, Qualys le lendemain, aux côtés de The Hacker News et de SecurityWeek. Deux des trois, CVE-2026-39808 et CVE-2026-39813, avaient déjà été divulguées par Fortinet en avril. La troisième, CVE-2026-25089, avait été corrigée le 9 juin, quelques jours avant le début des attaques.
Le 16 juillet 2026, la CISA a publié la version 2026.07.16 du catalogue et y a ajouté trois entrées. Deux sont les failles FortiSandbox, CVE-2026-25089 et CVE-2026-39808. La troisième est une faille de désérialisation de Microsoft SharePoint, CVE-2026-58644.
Comptez les jours. Exploitation confirmée, rapportée publiquement, bien réelle, à la mi-juin. Entrée au catalogue fédéral le 16 juillet. Une trentaine de jours séparent les deux, sur un équipement joignable depuis internet portant une faille d'exécution de code à distance sans authentification, et pendant ces trente jours l'information n'était pas secrète. Elle figurait dans les avis du constructeur et dans la presse spécialisée.
La troisième manque toujours
Trois CVE FortiSandbox ont été signalées comme exploitées dans cette vague de juin. Deux ont été cataloguées le 16 juillet. CVE-2026-39813, une faille de traversée de répertoire dans l'API JRPC de FortiSandbox qui permet de contourner l'authentification, n'est pas au catalogue.
C'est la partie qui devrait changer la manière dont le catalogue est utilisé, et pas seulement la vitesse. Une entrée au KEV est un signal positif fort : ce qui s'y trouve est exploité et vous devez agir. L'absence d'entrée est un signal bien plus faible que ne le supposent la plupart des programmes de correctifs. CVE-2026-39813 a été signalée comme exploitée aux côtés des deux qui ont été listées, dans la même vague, sur la même famille de produits, et elle n'est pas entrée au catalogue. Une organisation qui corrige ce que la CISA liste et diffère ce que la CISA ne liste pas vient de différer une faille dont les attaquants se sont servis en juin.
Un compte à rebours de trois jours sur une machine sous contrôle des changements
Les trois entrées ajoutées le 16 juillet portent une échéance de remédiation au 19 juillet 2026. Trois jours.
Pour un opérateur européen, l'échéance fédérale n'est pas contraignante en elle-même, et il est tentant de la classer comme un détail administratif américain. Elle est plus utile lue comme une mesure de gravité. Une échéance à trois jours est la façon qu'a le catalogue de dire qu'il n'attend pas de vous que vous patientiez jusqu'à la prochaine fenêtre. Le point gênant, c'est la collision avec la réalité : un équipement de sandbox est placé sous contrôle des changements précisément parce qu'il inspecte du trafic de production, et trois jours ne constituent pas une fenêtre de changement dans la plupart des organisations. Cette tension est le vrai problème opérationnel, et elle ne se dissout pas en relisant l'échéance de plus près.
Sous NIS2, l'exposition ne tient pas à l'échéance américaine mais au devoir de diligence ordinaire, et une faille d'exécution de code à distance sans authentification sur un équipement de sécurité, exploitée dans la nature pendant un mois alors qu'un correctif constructeur existait, est difficile à défendre comme un risque accepté.
Recâblez le déclencheur
La consigne est courte et précise. Si votre processus de gestion des vulnérabilités démarre quand une chose apparaît au KEV, il démarre avec environ un mois de retard et il en laisse passer entièrement. Ce n'est pas une critique du catalogue, qui fait ce qu'il annonce : il consigne ce que l'on sait exploité, quand les preuves atteignent le seuil. C'est une critique de l'usage d'un flux de confirmation comme système d'alerte précoce.
Faites trois choses. Abonnez-vous directement aux flux d'avis PSIRT de chaque constructeur dont les équipements terminent du trafic non fiable, car Fortinet a publié en juin quand le catalogue a parlé en juillet. Donnez aux équipements de sécurité exposés à internet leur propre couloir de correctifs, avec une horloge plus courte que l'infrastructure générale, puisqu'ils sont à la fois les actifs les plus exposés et les plus verrouillés par le contrôle des changements que vous possédez. Et vérifiez votre parc FortiSandbox face aux trois CVE de juin, pas aux deux cataloguées.
À lire ensuite: 430 000 pare-feu, une chaîne d'approvisionnement pour rançongiciel | Un jeton falsifié ouvre chaque PC géré par l'outil
