On a vu un paquet de trous critiques dans les produits de sécurité ces dernières années, mais certains sortent du lot parce qu’ils touchent des outils que beaucoup d’organisations tiennent pour… inviolables. C’est le cas de ce correctif sorti début février 2026 chez Fortinet, qui bouche une faille d’injection SQL dans FortiClientEMS, un composant central dans la gestion des endpoints.
Et non, ce n’est pas juste une citation alarmiste pour faire du clic, l’impact possible de ce type de vulnérabilité reste concret même si, pour l’instant, je n’ai pas (encore) vu de signaux d’attaques massives dans la nature.
SQL Injection : ça sonne vieux… mais ça fait toujours très mal
Quand on parle de SQL, on pense souvent à des failles qu’on croyait avoir enterrées dans les années 2000. Mais le diable n’est pas dans la datation, il est dans l’accès qu’une injection donne. Et dans ce cas précis, le bug touche FortiClientEMS 7.4.4, via son interface web d’administration.
Voici le schéma classique :
- Une API ou une page web prend une entrée
- Elle la passe sans la nettoyer dans une requête SQL
- Un attaquant injecte des caractères et des commandes
- La base de données exécute quelque chose qu’elle ne devrait jamais exécuter
Simple, banal ? Oui, mais dans le contexte d’un EMS qui pilote des dizaines, centaines ou milliers de clients… c’est tout sauf anodin. A savoir aussi, la faille est classé comme forte avec le score de 9,8 sur la CVE. Si vous ne savez plus ce que CVE ou CVSS veut dire, vous pouvez retrouver mon petit article ici. Bon pour en revenir à cette attaque, effectivement rien d’anodin car pas besoin d’authentification… et ouais, l’attaquant n’a pas à se connecter ni à être à l’intérieur du réseau. Il lui suffit d’atteindre l’interface HTTP(S). Oups 👌! En plus, l’injection n’est pas limitée à consulter des données, elle ouvre la porte à l’exécution de commande et donc à des problématiques plus graves.
Bref : une simple requête HTTP peut, en théorie, suffire à faire basculer un serveur de gestion de sécurité dans un état compromis.
Fortinet a publié un correctif fin 6 février 2026 pour ce bug donc je vous conseille de patcher. Si tu gères une infrastructure avec ce logiciel : patch immédiat. Pas dans une semaine. Pas après les tests. Immédiat. Rien ne t’empêche de tester avant production, mais en attendant, s’assurer que tu n’es pas exposé à une requête non authentifiée qui exécute du code… c’est littéralement ça, la définition d’un incident évité 😉 !!
Et le contexte plus large chez Fortinet
Ce n’est pas la première fois que des failles graves touchent des composants Fortinet. L’année passée, un scénario similaire avait concerné FortiWeb, leur WAF, avec une injection SQL menée à des rces pré-authentifiés (CVE-2025-25257).
La leçon ? Je vous vois venir… mais non, ce n’est pas « Fortinet est mauvais ». C’est que les plateformes de sécurité sont par définition des cibles de choix : elles sont exposées, puissantes et, si elles chutent, l’impact est maximal. Les attaquants ne lâchent jamais un os aussi juteux.
Cette vulnérabilité SQL corrigée ici rappelle que même les technologies de sécurité sont faillibles et que leur exposition doit être traitée avec attention. C’est pas parceque c’est un outil de sécurité que c’est sécurisé ! Et surtout, n’attends pas d’entendre “il y a eu exploitation dans la nature”. Parce qu’à ce stade-là, c’est déjà trop tard.
Si l’article vous a plu et si vous aimez mon travail, vous pouvez faire un don en suivant ce lien :
