Quatre incidents. Quatre produits différents. Quatre équipes d'attaquants sans lien apparent entre elles. Si l'on devait résumer ce que révèle la série d'événements touchant Fortinet en 2026, ce serait probablement cela : la concentration du risque fournisseur n'est pas un concept abstrait de gouvernance, c'est une surface d'attaque réelle, mesurable, et aujourd'hui activement exploitée.
Ce qui rend cette séquence particulièrement instructive, c'est précisément qu'elle n'est pas une séquence. Les quatre incidents ne se nourrissent pas l'un de l'autre. Ils ne partagent ni le même vecteur initial, ni le même acteur, ni la même logique d'exploitation. Chacun a été découvert et armé indépendamment.
FortiGate sous exploitation automatisée par IA
Le premier incident concerne FortiGate, le produit phare de la gamme. Des chercheurs en sécurité offensive ont documenté l'utilisation de pipelines d'automatisation assistés par IA pour identifier et exploiter des instances FortiGate vulnérables à grande échelle. Le principe n'est pas nouveau — les scanners automatisés existent depuis longtemps — mais la capacité à qualifier rapidement les cibles exploitables, à adapter les payloads selon la version firmware détectée, et à enchaîner les étapes post-exploitation sans intervention humaine représente un saut qualitatif réel. Ce qui prenait des jours à une équipe de pentesters peut désormais se produire en heures sur des dizaines de milliers d'équipements exposés.
Pour une organisation qui s'appuie sur FortiGate comme seul point de filtrage périmétrique, cette accélération du cycle d'exploitation change le rapport entre la date de publication d'un patch et la fenêtre d'exposition effective.
FortiClient EMS et la prise de contrôle silencieuse
Le deuxième incident touche FortiClient EMS, le serveur de gestion des endpoints. Une vulnérabilité permettant une injection SQL non authentifiée a été exploitée pour obtenir une exécution de code à distance sur le serveur EMS lui-même. Ce type de compromission est particulièrement grave : EMS est précisément la composante qui orchestre les politiques de sécurité sur l'ensemble du parc de terminaux. Un attaquant qui contrôle EMS peut modifier les politiques, désactiver des contrôles, et potentiellement pivoter vers chaque poste géré.
Ce n'est pas un vecteur latéral dans l'infrastructure — c'est un vecteur central. Et la chaîne d'exploitation documentée était suffisamment simple pour être reproductible sans expertise avancée.
FortiSandbox : quand l'outil d'analyse devient la cible
Le troisième vecteur est conceptuellement le plus ironique. FortiSandbox, la solution d'analyse dynamique censée détecter les menaces inconnues, a été ciblée par une vulnérabilité permettant à un attaquant d'échapper au bac à sable et d'exécuter du code sur le système hôte. L'exploitation de FortiSandbox illustre un principe que les équipes Red Team connaissent bien : les outils de sécurité eux-mêmes sont des cibles de choix, précisément parce qu'ils traitent des contenus hostiles par conception et qu'ils bénéficient souvent de privilèges élevés sur le système qui les héberge.
Une sandbox compromise ne détecte plus rien — et pire, elle peut devenir un point de persistance dans un environnement où elle est censée faire autorité sur la classification des menaces.
FortiBleed : la campagne de collecte d'identifiants
Le quatrième incident, surnommé FortiBleed dans les cercles de threat intelligence, ne repose pas sur une exécution de code mais sur une fuite de mémoire permettant d'extraire des fragments de sessions actives, dont des identifiants en clair ou des tokens d'authentification. La technique rappelle dans son principe Heartbleed, mais appliquée à l'interface d'administration de certains équipements Fortinet. Des campagnes organisées ont exploité cette faille pour constituer des bases d'identifiants valides, revendues ou utilisées directement pour des accès VPN légitimes en apparence.
C'est le type d'attaque qui ne génère aucune alerte dans un SIEM classique : pas d'exploit bruyant, pas de payload, juste une connexion qui ressemble à celle d'un administrateur légitime. Pour comprendre pourquoi ce vecteur est si difficile à détecter, il est utile d'explorer les scénarios de labs dédiés à la détection de mouvements latéraux furtifs dans un environnement de simulation.
Ce que quatre incidents séparés disent d'un seul fournisseur
Il serait confortable d'interpréter ces quatre incidents comme une mauvaise passe temporaire pour Fortinet. Ce serait passer à côté de l'essentiel.
Ces quatre événements ont été produits par des équipes de recherche et des acteurs malveillants indépendants, sans coordination entre eux, attaquant des surfaces complètement différentes du portfolio produit. Cela signifie que la probabilité de découvrir une nouvelle vulnérabilité exploitable dans un produit Fortinet n'est pas un événement exceptionnel — c'est une distribution statistique normale pour un éditeur dont le code base est vaste, mature et donc ancien sur certaines composantes.
Le vrai problème n'est pas Fortinet spécifiquement. C'est l'architecture de confiance que les organisations ont construite autour d'un fournisseur unique. FortiGate comme unique pare-feu, FortiClient pour l'ensemble des endpoints, FortiSandbox comme unique outil d'analyse de fichiers, FortiAuthenticator pour l'authentification : chaque couche de cet empilement uniforme devient un point de défaillance systémique dès lors qu'une vulnérabilité touchant n'importe lequel de ces produits peut être pivotée vers les autres.
Les RSSI qui gèrent ce type d'architecture homogène méritent une analyse honnête de leur niveau d'exposition réel. Évaluer sa dépendance critique à un fournisseur d'infrastructure réseau fait partie des diagnostics que les équipes de sécurité devraient conduire régulièrement, pas seulement après un incident.
Trois principes pour réduire le risque de concentration
La réponse opérationnelle à ce type de risque systémique ne passe pas par l'abandon immédiat de l'écosystème en place — la complexité et les coûts de migration sont réels. Elle passe par trois principes qui peuvent être appliqués progressivement.
- Segmenter les plans de gestion : les interfaces d'administration de FortiGate, EMS et FortiSandbox ne devraient jamais partager le même réseau d'administration ni les mêmes comptes de service. Une compromission d'un produit ne doit pas offrir de pivot immédiat vers les autres.
- Maintenir une capacité de détection indépendante du fournisseur : si votre SIEM et votre sandbox proviennent du même éditeur que votre pare-feu, une compromission coordonnée peut aveugler votre capacité de détection en même temps qu'elle exploite votre infrastructure.
- Accélérer le cycle de patch sur les composantes à privilèges étendus : les interfaces d'administration exposées et les serveurs de gestion d'endpoints doivent faire l'objet d'une priorité de patch absolue, avec une tolérance à zéro pour les exceptions liées à la disponibilité opérationnelle.
Questions fréquentes
Les quatre incidents Fortinet de 2026 sont-ils liés entre eux ?
Non. Chaque incident implique un produit distinct, un vecteur d'exploitation différent et des acteurs sans lien apparent entre eux. C'est précisément ce qui rend la situation significative : plusieurs équipes indépendantes ont trouvé simultanément des façons différentes de compromettre des produits différents du même éditeur.
Qu'est-ce que la concentration du risque fournisseur en cybersécurité ?
C'est le fait de dépendre d'un seul fournisseur pour plusieurs couches critiques de l'infrastructure de sécurité. Si ce fournisseur présente une vulnérabilité, l'ensemble des couches peut être exposé simultanément, et les produits peuvent se servir de passerelles de pivot les uns vers les autres.
FortiBleed est-il comparable à Heartbleed ?
Le mécanisme de fuite mémoire est conceptuellement similaire, mais le contexte est différent. FortiBleed cible des interfaces d'administration réseau plutôt que des serveurs web publics. L'impact reste grave car il permet d'extraire des identifiants valides sans déclencher d'alertes dans la plupart des configurations de monitoring classiques.
Comment un RSSI doit-il prioriser la réponse à ce type de risque systémique ?
La première priorité est la segmentation des plans d'administration pour empêcher le pivot entre produits. Ensuite, une revue de la dépendance à un seul fournisseur sur les couches critiques (périmètre, endpoint, analyse, authentification) permet d'identifier les points de défaillance unique. Le patching accéléré sur les composantes à privilèges étendus complète cette approche.