Deux failles critiques non authentifiées – CVE-2026-21643 (injection SQL) et CVE-2026-35616 (contournement d’accès API) – ont été découvertes dans FortiClient EMS en l’espace de quelques semaines début 2026. Toutes deux ont été exploitées en conditions réelles avant même la publication d’un correctif officiel, et la CISA a ajouté CVE-2026-35616 à son catalogue Known Exploited Vulnerabilities (KEV) le 6 avril 2026, avec une date limite de remédiation fixée au 9 avril pour les agences fédérales américaines. Score CVSS : 9.1 pour les deux.
Si vous gérez des instances FortiClient EMS exposées sur Internet, l’article qui suit n’est pas de la lecture de veille, c’est une liste de priorités opérationnelles.
Pourquoi FortiClient EMS concentre l’attention des attaquants
FortiClient EMS (Endpoint Management Server) n’est pas un produit anecdotique dans l’écosystème Fortinet. C’est la pièce centrale qui permet aux équipes IT de gérer, surveiller, provisionner, patcher et mettre en quarantaine l’ensemble des endpoints d’une organisation. Concrètement : celui qui contrôle l’EMS contrôle les postes de travail.
C’est précisément ce qui en fait une cible de premier choix. Un accès initial sur l’EMS ne se limite pas à compromettre un serveur, il ouvre une porte latérale vers tous les endpoints. Les attaquants le savent (et ouais ils sont malins), les acteurs étatiques aussi (encore plus malin 😉). Pour rappel, la faille CVE-2023-48788 (injection SQL sur FortiClient EMS, mars 2024) avait déjà été liée à des campagnes ransomware et attribuée, au moins partiellement, au groupe Salt Typhoon, un acteur aligné avec les intérêts chinois ayant ciblé des opérateurs télécoms américains.
À ce jour, Fortinet totalise 24 entrées dans le catalogue KEV de la CISA, dont plus de la moitié impliquées dans des attaques ransomware. La barre de confiance est donc posée : les vulnérabilités Fortinet ne restent pas théoriques longtemps.
CVE-2026-21643 : injection SQL non authentifiée via l’en-tête HTTP
Divulguée en février 2026, CVE-2026-21643 affecte FortiClient EMS 7.4.4 exclusivement (les branches 7.2.x et 8.0.x ne sont pas touchées). Il s’agit d’une injection SQL classique, mais le vecteur est particulier : l’injection passe par l’en-tête Site d’une requête HTTP adressée à l’interface d’administration web. Aucune authentification requise, complexité d’attaque faible.
En pratique, un attaquant peut injecter des commandes SQL, via les capacités natives du backend Microsoft SQL Server (la procédure stockée xp_cmdshell), se transforment en exécution de commandes OS avec les privilèges SYSTEM. C’est exactement le chemin qu’avait documenté Horizon3.ai pour la CVE-2023-48788 et la mécanique est identique ici.
Defused Cyber a détecté les premières exploitations de cette faille le 24 mars 2026, soit plusieurs jours avant que la vulnérabilité n’apparaisse dans le catalogue KEV officiel. C’est un pattern qu’on observe de plus en plus fréquemment : la fenêtre entre divulgation et exploitation active se rétrécit, et les listes officielles prennent du retard sur le terrain.
À ce moment-là, Shadowserver recensait plus de 2 000 instances FortiClient EMS directement exposées sur Internet, avec une concentration aux États-Unis et en Europe.
CVE-2026-35616 : bypass d’authentification API en zero-day
La CVE-2026-35616 est d’un autre ordre. Il ne s’agit pas d’injection SQL mais d’un contrôle d’accès inadéquat (CWE-284) au niveau de l’API de FortiClient EMS. La faille permet à un attaquant non authentifié de contourner entièrement les mécanismes d’authentification et d’autorisation de l’API en forgeant un en-tête d’accès spécifique. Résultat : exécution de code ou de commandes arbitraires sur le serveur sous-jacent.
Ce qui change par rapport à CVE-2026-21643 : cette fois, c’est un zero-day exploité avant tout correctif disponible. Les honeypots de watchTowr ont enregistré les premières tentatives d’exploitation le 31 mars 2026. Fortinet a publié son advisory le 5 avril, les correctifs d’urgence le 6 avril et la CISA a ajouté la faille au catalogue KEV le même jour, avec un délai de patch de 72 heures pour les agences fédérales.
Les versions affectées sont FortiClient EMS 7.4.5 et 7.4.6. La branche 7.2.x n’est pas touchée.
Benjamin Harris, CEO de watchTowr, a été direct dans ses déclarations : l’intensification de l’exploitation autour du weekend de Pâques n’est probablement pas une coïncidence. Les équipes de sécurité tournent en effectif réduit, les ingénieurs d’astreinte sont moins disponibles, et la fenêtre entre compromission et détection peut s’étirer de quelques heures à plusieurs jours. C’est un pattern documenté, pas une théorie.
Surface d’attaque : ce qui rend ces deux CVE particulièrement dangereuses
Les deux failles ne nécessitent aucune authentification préalable. N’importe quel système capable d’envoyer des requêtes HTTP vers le port d’administration de l’EMS peut déclencher l’exploitation. Les 2 000+ instances exposées recensées par Shadowserver représentent autant de points d’entrée potentiels, beaucoup gérés par des équipes qui n’ont pas encore eu le temps de patcher.
En France et dans les pays francophones, la situation n’est pas anodine. Lors des analyses liées à CVE-2023-48788, Shodan avait identifié 13 instances exposées en France et au Canada. Il est raisonnable d’estimer une exposition similaire pour les failles 2026.
Le lien formel entre CVE-2026-21643 et CVE-2026-35616 n’a pas été confirmé par Fortinet ou watchTowr. Mais les deux failles partagent le même produit, la même fenêtre temporelle, et le même profil d’attaquant (non authentifié, distant). Il est techniquement plausible d’envisager un enchaînement :
- CVE-2026-21643 : injection SQL via l’en-tête HTTP → exécution de commandes OS avec privilèges SYSTEM → implantation d’un premier accès persistant (backdoor, webshell).
- CVE-2026-35616 : si la cible a patché la première faille mais tourne encore sur 7.4.5 ou 7.4.6, le bypass API offre un vecteur alternatif pour retrouver cet accès ou en établir un nouveau.
Ce n’est pas de la spéculation : watchTowr a explicitement dit ne pas pouvoir exclure que les deux vulnérabilités soient utilisé conjointement.
Priorités de patch : ce que vous devez faire maintenant
Tableau des versions affectées et correctifs
| CVE | Versions affectées | Correctif disponible |
|---|---|---|
| CVE-2026-21643 | FortiClient EMS 7.4.4 | Mettre à jour vers 7.4.5 ou supérieur |
| CVE-2026-35616 | FortiClient EMS 7.4.5, 7.4.6 | Hotfix d’urgence disponible ; version 7.4.7 à venir |
Important : si vous avez patché CVE-2026-21643 en montant vers 7.4.5, vous êtes maintenant dans la fenêtre affectée par CVE-2026-35616. Le hotfix d’urgence publié le 6 avril doit être appliqué en complément. La branche 7.2.x n’est affectée ni par l’une ni par l’autre.
Après application du hotfix ou de la mise à jour, vérifiez :
# Vérifier la version installée
diagnose sys versionFortinet a publié des instructions détaillées pour vérifier que les hotfixes ont bien été appliqués sur les versions 7.4.5 et 7.4.6, ne pas sauter cette étape.
Ce qui se passe avec FortiClient EMS début 2026 illustre un pattern bien rodé : un produit à haute valeur cible (accès à tous les endpoints de l’organisation), deux vulnérabilités non authentifiées critiques découvertes en succession rapide, une exploitation en zero-day pendant un weekend férié, et des milliers d’instances encore exposées.
Les prochaines semaines diront si des campagnes ransomware structurées s’appuient sur ces accès initiaux, comme ce fut le cas après CVE-2023-48788. Les indicateurs sont là. Il faut patcher maintenant.
FAQ sur FortiClient EMS & les CVE KEV 2026
Le lien formel entre CVE-2026-21643 et CVE-2026-35616 n’a pas été confirmé par Fortinet ni par watchTowr. Mais les deux failles partagent le même produit, la même fenêtre temporelle, et le même profil d’attaquant : non authentifié, distant, sans interaction utilisateur.
Un scénario d’enchaînement reste techniquement plausible : exploitation de CVE-2026-21643 pour obtenir un accès SYSTEM initial sur une instance en 7.4.4, puis utilisation de CVE-2026-35616 comme vecteur alternatif si la cible a patché la première faille en montant vers 7.4.5 ou 7.4.6 sans appliquer le hotfix d’urgence.
CVE-2026-21643 affecte uniquement FortiClient EMS 7.4.4. Il s’agit d’une injection SQL via l’en-tête HTTP Site, exploitable sans authentification. Le correctif est la mise à jour vers 7.4.5 ou supérieur.
CVE-2026-35616 affecte FortiClient EMS 7.4.5 et 7.4.6. C’est un bypass d’authentification API (CWE-284). Un hotfix d’urgence est disponible pour ces deux versions en attendant la release 7.4.7.
La branche 7.2.x n’est affectée ni par l’une ni par l’autre.
Moins qu’une instance directement accessible depuis Internet, mais pas immunisé. Les deux failles ne nécessitent aucune authentification préalable – seule la capacité à envoyer des requêtes HTTP vers le port d’administration de l’EMS est requise.
Si un poste interne est compromis et peut communiquer avec l’EMS – ce qui est le cas dans la grande majorité des architectures réseau d’entreprise – les failles restent exploitables depuis l’intérieur du réseau. La priorité de patch est moindre que pour une instance publique, mais le risque existe.
Plusieurs signaux à rechercher activement dans vos logs :
– Erreurs HTTP 500 répétées sur l’endpoint /api/v1/init_consts – pattern typique lors de tentatives d’injection SQL liées à CVE-2026-21643.
– Messages d’erreur PostgreSQL ou MSSQL inhabituels dans les logs de base de données.
– Présence d’outils RMM non autorisés sur le serveur EMS (TeamViewer, AnyDesk, ScreenConnect).
– Requêtes API anormales : volumes inhabituels, User-Agents inconnus, en-têtes forgés.
Formellement, les obligations du catalogue KEV s’appliquent uniquement aux agences fédérales américaines (FCEB). Mais en pratique, il s’est imposé comme référence mondiale pour les équipes sécurité.
Une entrée KEV signifie une seule chose : exploitation confirmée dans la nature. Ce n’est pas une alerte théorique, c’est un constat factuel. Pour CVE-2026-35616, la CISA a fixé un délai de patch de 72h – une fenêtre qui traduit le niveau d’urgence réel, quelle que soit la juridiction de votre organisation.
Si l’analyse des logs révèle des indicateurs de compromission sur la fenêtre zero-day (31 mars – 6 avril), oui – une réinstallation propre est la recommandation standard. Appliquer le hotfix sur une instance potentiellement compromise ne suffit pas : il bloque la faille mais ne nettoie pas ce qui aurait pu être déposé avant.
Une instance EMS compromise peut avoir été modifiée de façon persistante : webshells dans le répertoire web, backdoors dans les scripts de gestion, modification de policies endpoint, ajout d’administrateurs fantômes.
Ce n’est probablement pas une coïncidence. Benjamin Harris, CEO de watchTowr, a été direct : les attaquants ont montré à maintes reprises que les weekends fériés sont le moment idéal pour agir. Les équipes de sécurité tournent en effectif réduit, les ingénieurs d’astreinte sont moins disponibles, et la fenêtre entre compromission et détection peut s’étirer de quelques heures à plusieurs jours.
C’est un pattern documenté, pas une théorie. On l’observe systématiquement sur les incidents majeurs : Noël, 4 juillet, ponts de mai. La détection tardive laisse aux attaquants le temps d’établir une persistance solide avant que les équipes ne réintègrent.