# Kit de détection pour CVE-2026-35616 Kit de détection pour CVE-2026-35616, un contournement d'API pré-authentification dans FortiClient EMS. Comprend un scanner Python et un script Nmap NSE pour identifier les versions vulnérables et fournir des recommandations de remédiation.
Un contournement d'authentification critique dans Fortinet FortiClient EMS 7.4.5 et 7.4.6 permet à un attaquant distant totalement non authentifié de contourner l'authentification API en usurpant un seul en-tête HTTP (X-SSL-CLIENT-VERIFY). La faille existe parce que le middleware Django fait confiance aux métadonnées de certificat client provenant d'en-têtes contrôlés par l'utilisateur, et pas uniquement au proxy inverse de confiance. Cela donne aux attaquants un accès API administratif complet - et à partir de là, une exécution de code arbitraire sur les points de terminaison gérés à travers l'entreprise.
Exploité activement depuis le 31 mars 2026. Ajouté au catalogue KEV de la CISA le 6 avril 2026.
| Champ | Détail |
|---|---|
| ID CVE | CVE-2026-35616 |
| Fournisseur | Fortinet |
| Produit | FortiClient Enterprise Management Server (EMS) |
| Versions affectées | 7.4.5, 7.4.6 |
| Non affecté | Branche 7.2.x, 7.4.4 et antérieures |
| CVSS v3.1 | 9.1 (Critique) |
| CWE | CWE-284 - Contrôle d'accès inapproprié |
| Vecteur d'attaque | Réseau |
| Authentification | Aucune requise |
| Interaction utilisateur | Aucune |
| Maturité de l'exploit | Exploité dans la nature |
| CISA KEV | Ajouté le 6 avril 2026 (échéance : 9 avril 2026) |
| Correctif | Correctif d'urgence disponible ; correctif complet dans 7.4.7 |
| Crédité à | Simo Kohonen (Defused Cyber), Nguyen Duc Anh |
FortiClient Enterprise Management Server (EMS) est la plateforme centralisée de gestion des points de terminaison de Fortinet. Elle sert de couche de commande et de contrôle pour déployer, configurer et surveiller les agents FortiClient dans une organisation. Considérez-la comme le cerveau qui gouverne chaque point de terminaison dans un environnement géré par Fortinet :
Lorsqu'un attaquant obtient un accès administratif à EMS, il détient essentiellement les clés de chaque point de terminaison géré dans l'organisation.
FortiClient EMS utilise une pile d'applications web assez standard en arrière-plan :
+----------------+ +----------------+ +----------------+
| Navigateur / | HTTPS | Apache | WSGI | Django |
| Client API | -------> | (mod_ssl) | -------> | Backend |
+----------------+ +----------------+ +----------------+
Lorsque le TLS mutuel (mTLS) est configuré, le mod_ssl d'Apache gère la vérification du certificat client. Après avoir validé le certificat, Apache transmet le résultat de la vérification à Django via des variables d'environnement WSGI de confiance :
SSL_CLIENT_VERIFY - Le statut de vérification (SUCCESS, NONE, FAILED)SSL_CLIENT_S_DN - Le nom distinctif du sujet du certificatSSL_CLIENT_SERIAL - Le numéro de série du certificatC'est le modèle standard et sécurisé. Le problème réside dans la façon dont le middleware Django lit ces données.
Dans FortiClient EMS 7.4.5 et 7.4.6, le middleware d'authentification Django a été modifié pour également accepter ces mêmes informations à partir des en-têtes de requête HTTP :
X-SSL-CLIENT-VERIFYX-SSL-CLIENT-S-DNX-SSL-CLIENT-SERIALCela a probablement été ajouté pour prendre en charge les déploiements de proxy inverse où Apache n'est pas le point de terminaison TLS. Cependant, le middleware ne fait pas la distinction entre ces deux sources. Il vérifie d'abord les variables WSGI, mais si elles sont absentes (pas de mTLS configuré, ou connexion directe), il retombe sur les en-têtes HTTP - que n'importe quel client peut définir.
Voici la répartition conceptuelle :
CHEMIN SÉCURISÉ (prévu) :
Apache mod_ssl valide le certificat --> définit les variables d'env WSGI --> Django lit les variables d'env [OK]
CHEMIN NON SÉCURISÉ (la vulnérabilité) :
L'attaquant définit directement les en-têtes HTTP --> Django lit les en-têtes --> Leur fait confiance [ÉCHEC]
Le middleware fait effectivement confiance au client pour auto-attester son propre statut de vérification de certificat. C'est comme si un videur demandait à quelqu'un « Hé, est-ce que l'autre videur a déjà vérifié ta pièce d'identité ? » et le laissait entrer quand il répond « oui ».
Étape 1 : L'attaquant envoie une requête POST à un point de terminaison API EMS
avec ces en-têtes :
X-SSL-CLIENT-VERIFY: SUCCESS
X-SSL-CLIENT-S-DN: CN=admin
X-SSL-CLIENT-SERIAL: 0000000000000001
Étape 2 : Le middleware Django vérifie les variables d'env WSGI → absentes
Retombe sur les en-têtes HTTP → trouve X-SSL-CLIENT-VERIFY: SUCCESS
Étape 3 : Le middleware traite la requête comme authentifiée avec l'identité admin
Étape 4 : L'attaquant a un accès API administratif complet
Étape 5 : Depuis l'API admin, l'attaquant peut :
- Pousser des politiques malveillantes vers tous les points de terminaison gérés
- Extraire les identifiants et certificats stockés
- Déployer des charges utiles via la distribution logicielle
- Modifier les configurations ZTNA
- Pivoter vers le réseau plus large
L'attaque entière nécessite une seule requête HTTP. Pas de force brute, pas de bourrage d'identifiants, pas d'ingénierie sociale. Juste un en-tête falsifié.
La gravité ici va au-delà du serveur lui-même. FortiClient EMS est un multiplicateur de force - le compromettre donne à un attaquant un levier sur chaque point de terminaison géré :
Impact immédiat :