Fortinet a corrigé une vulnérabilité critique dans FortiClient Enterprise Management Server (EMS), suivie sous l’identifiant CVE-2026-35616, déjà observée en exploitation pour déployer un voleur d’informations sur des environnements d’entreprise. Selon les éléments rapportés publiquement par BleepingComputer et les informations de l’éditeur, le défaut permet un contournement d’authentification sur des consoles EMS exposées à Internet. Le risque est particulièrement élevé car EMS n’est pas un composant périphérique : il s’agit d’un point central de gestion des postes, des politiques de sécurité et des déploiements clients. Une compromission de cette console peut donc se transformer en point d’entrée serveur critique avec diffusion de charges malveillantes, collecte d’identifiants, et pivot vers le système d’information.

Le scénario d’attaque est concret : un attaquant repère une instance EMS accessible depuis Internet, contourne le mécanisme d’authentification, prend le contrôle de la console et pousse un infostealer ou une charge secondaire vers des terminaux administrés. À partir de là, les conséquences peuvent dépasser largement le périmètre de l’outil lui-même : vol d’identifiants Windows, secrets navigateurs, cookies de session, accès VPN, voire prise d’appui pour des mouvements latéraux. Dans un contexte où des hébergeurs et infrastructures françaises comme OVHcloud, Scaleway ou o2switch hébergent parfois des composants d’administration exposés, la suppression de l’exposition Internet des consoles de gestion doit être considérée comme une mesure prioritaire.

Au moment de la rédaction, la vulnérabilité est présentée comme activement exploitée. Le score CVSS exact doit être vérifié dans l’avis officiel Fortinet au moment de l’évaluation interne, mais la nature du défaut, son exploitation sans authentification et l’impact métier justifient une priorisation maximale. La source originale à citer côté éditeur reste l’advisory Fortinet dédié à CVE-2026-35616, à compléter par le suivi des CERT nationaux si une note CERT-FR est publiée ou relayée.

Versions affectées

Les versions exactes vulnérables et corrigées doivent être validées à partir de l’avis de sécurité officiel Fortinet associé à CVE-2026-35616. Dans ce type de dossier, l’éditeur publie généralement une matrice par branche de maintenance avec les versions touchées, les versions de remédiation et parfois des contournements temporaires. La priorité opérationnelle consiste à identifier immédiatement :

  • les serveurs exécutant FortiClient EMS sur des branches non corrigées ;
  • les instances accessibles directement depuis Internet ;
  • les consoles disposant de droits d’administration sur un parc important de postes ;
  • les environnements où EMS peut pousser des packages, scripts, mises à jour ou politiques vers les endpoints.

En pratique, il faut inventorier toutes les instances EMS, y compris celles oubliées en préproduction, chez un infogérant, ou déployées dans une filiale. Les équipes doivent ensuite rapprocher la version installée de la version corrigée publiée par Fortinet. Les points suivants sont à vérifier systématiquement :

  • version exacte du serveur EMS dans l’interface d’administration et dans les fichiers de version locaux ;
  • branche de maintenance utilisée ;
  • date du dernier correctif appliqué ;
  • présence éventuelle d’un canal de mise à jour différé ;
  • historique des accès administratifs récents.

Sur un hôte Windows hébergeant EMS, la vérification peut passer par l’interface graphique, mais aussi par l’inventaire logiciel système ou PowerShell. Exemple de recensement local :

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" | Where-Object { $_.DisplayName -match "FortiClient EMS" } | Select-Object DisplayName, DisplayVersion, Publisher

Si EMS est installé comme service applicatif avec des composants web, il faut également vérifier les répertoires d’installation, les journaux applicatifs et la date des binaires. Une recherche simple peut aider à confirmer l’emplacement :

Get-ChildItem "C:\Program Files" -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.FullName -match "FortiClient|EMS" }

Lorsque l’organisation exploite plusieurs consoles, il est utile de constituer un tableau de suivi minimal :

  • nom du serveur ;
  • adresse IP ;
  • exposition Internet oui/non ;
  • version EMS ;
  • version cible corrigée ;
  • fenêtre de maintenance ;
  • statut de revue des journaux ;
  • statut de chasse aux compromissions sur les endpoints rattachés.

En attendant une consolidation interne, toute version EMS explicitement listée comme vulnérable dans l’avis Fortinet doit être considérée comme à risque immédiat. Toute version antérieure à la version de correction publiée par l’éditeur doit être sortie d’exposition ou corrigée sans délai. Si l’éditeur a publié plusieurs versions de remédiation selon les branches, il faut viser la version corrigée la plus récente supportée et éviter de rester sur une branche en fin de vie.

Vecteur d'attaque

Le cœur du problème est un contournement d’authentification sur une console de gestion centralisée. Sur le plan technique, ce type de faille signifie qu’un service web censé réserver certaines actions à des administrateurs authentifiés accepte, dans certaines conditions, des requêtes non authentifiées ou mal validées. Les causes possibles sont variées : validation insuffisante d’un jeton de session, route exposée sans garde d’accès, défaut de normalisation d’URL, logique de confiance cassée entre frontal et backend, ou erreur dans le traitement d’un en-tête HTTP. Le détail exact doit être confirmé par l’avis officiel Fortinet, mais l’impact opérationnel est déjà clair : un serveur de pilotage endpoint peut être pris en main à distance.

Dans l’écosystème EMS, cette réalité est particulièrement sensible car la plateforme dispose souvent de fonctions à fort pouvoir :

  • distribution de clients ou modules de sécurité ;
  • déploiement de configurations ;
  • gestion de groupes de machines ;
  • orchestration de mises à jour ;
  • collecte d’inventaire et d’informations de parc ;
  • intégration avec des annuaires ou mécanismes d’authentification ;
  • interaction avec des accès distants et des profils de sécurité.

Autrement dit, même si la faille n’est “que” un contournement d’authentification côté serveur, la chaîne d’impact peut être bien plus large qu’une simple compromission de l’interface web. Si un attaquant obtient la capacité de créer ou modifier une politique de déploiement, il peut pousser un exécutable malveillant, un package piégé, un script, ou rediriger les postes vers un contenu contrôlé. C’est précisément ce qui rend crédible le scénario rapporté : déploiement d’un infostealer via EMS.

Chaîne d’attaque plausible

Un scénario réaliste en environnement exposé se déroule en plusieurs étapes :

  • reconnaissance Internet et identification d’une interface EMS exposée sur un domaine ou une adresse IP ;
  • fingerprinting de la version via bannières, titres de pages, ressources statiques, certificats TLS, ou comportement de routes web ;
  • exploitation de CVE-2026-35616 pour contourner l’authentification ;
  • prise de contrôle de la console ou accès à des fonctions d’administration ;
  • création ou modification d’un package de déploiement ;
  • distribution d’un voleur d’informations sur les postes rattachés ;
  • exfiltration d’identifiants, cookies, secrets applicatifs ou accès VPN ;
  • mouvement latéral vers d’autres serveurs, annuaires, outils de téléadministration ou consoles de sécurité.

Le point le plus critique pour les équipes IT est le passage du serveur de gestion au poste administré. Une console EMS compromise n’est pas seulement un serveur touché ; elle peut devenir un multiplicateur d’impact. Dans des environnements où l’outil administre plusieurs centaines ou milliers de machines, le temps de réaction est déterminant.

Exemple de surface d’exposition

Les consoles EMS exposées sont souvent accessibles via HTTPS. Les indicateurs de surface publique peuvent inclure :

  • certificat TLS avec un nom explicite lié à EMS ;
  • pages de connexion reconnaissables ;
  • réponses HTTP spécifiques ;
  • favicon ou ressources statiques identifiables ;
  • ports d’administration ouverts sur Internet ;
  • reverse proxy publiant l’interface sans filtrage IP ou MFA en amont.

Une vérification simple depuis l’extérieur permet d’identifier l’exposition, sans chercher à reproduire l’exploit :

curl -k -I https://ems.exemple.fr/

Ou avec plus de détails sur les en-têtes :

curl -k -s -D - https://ems.exemple.fr/ -o /dev/null

L’objectif n’est pas de tester la vulnérabilité en production sans cadre, mais de confirmer que l’interface est bien visible depuis Internet. Si c’est le cas, l’urgence est immédiate.

Pourquoi l’infostealer change la gravité opérationnelle

Le déploiement d’un voleur d’informations transforme une compromission serveur en incident potentiellement transversal. Un infostealer moderne vise généralement :

  • identifiants enregistrés dans les navigateurs ;
  • cookies de session ;
  • jetons d’authentification ;
  • fichiers de configuration de clients VPN ;
  • historique de navigation ;
  • portefeuilles numériques dans certains cas ;
  • captures de données système utiles au profilage de la victime.

Pour une entreprise, cela signifie qu’un simple poste administré compromis peut fournir à l’attaquant :

  • des accès à des consoles SaaS ;
  • des sessions d’administration cloud ;
  • des comptes de support ;
  • des accès RDP, VPN ou bastion ;
  • des identifiants réutilisés sur d’autres systèmes ;
  • des secrets stockés localement par des outils DevOps ou d’administration.

Le risque de pivot vers l’Active Directory, les outils EDR, les solutions ITSM ou les dépôts de code n’est donc pas théorique. Une console EMS exposée et compromise peut devenir la première étape d’une chaîne d’intrusion plus vaste.

Comparaison avec des failles antérieures

L’écosystème sécurité et administration a déjà connu plusieurs cas où une console centrale exposée à Internet a servi de point d’entrée majeur : appliances VPN, consoles de MDM, outils de RMM, orchestrateurs de correctifs ou portails SSO. Le schéma est récurrent :

  • une interface d’administration est publiée pour des raisons de commodité ;
  • une faille d’authentification, d’injection ou de désérialisation est révélée ;
  • les attaquants scannent massivement Internet ;
  • la compromission du point central permet une propagation rapide ;
  • les défenseurs découvrent tardivement l’impact réel sur les terminaux.

La leçon stratégique reste la même : une console de gestion endpoint ne doit pas être traitée comme une simple interface web. Son exposition doit être exceptionnelle, strictement filtrée et surveillée comme un actif critique. Ce point rejoint les bonnes pratiques de durcissement que les équipes peuvent retrouver sur /categorie/pratiques.

Impact

L’impact principal de CVE-2026-35616 est la prise de contrôle fonctionnelle d’un serveur EMS par un acteur non authentifié, avec exploitation active observée. Les conséquences concrètes pour les équipes IT, sécurité et direction des systèmes d’information sont multiples :

  • compromission du serveur de gestion centralisée ;
  • déploiement de malware sur les postes administrés ;
  • vol d’identifiants et de sessions ;
  • altération de politiques de sécurité ;
  • perte d’intégrité de la chaîne de confiance entre console et endpoints ;
  • risque de mouvement latéral vers le SI ;
  • nécessité de reconstruire la confiance sur l’outil d’administration.

En cas de compromission avérée, il ne faut pas raisonner uniquement en “patch serveur”. Il faut considérer trois périmètres d’investigation :

  • le serveur EMS lui-même ;
  • les comptes et secrets auxquels EMS avait accès ;
  • l’ensemble des endpoints gérés pendant la fenêtre d’exposition.

La difficulté opérationnelle est importante : même après correction, une console compromise peut avoir servi à distribuer une charge malveillante ou à extraire des données d’inventaire. La remédiation doit donc inclure une revue des déploiements récents, des changements de configuration et des actions administratives exécutées depuis EMS.

Comment patcher

La remédiation prioritaire consiste à mettre à jour FortiClient EMS vers la version corrigée publiée par Fortinet pour CVE-2026-35616, puis à retirer l’exposition Internet directe si elle existe. Comme EMS est généralement déployé sur Windows, la mise à jour se fait le plus souvent via le package officiel de l’éditeur et non via apt, dnf ou composer. Il faut donc prévoir une fenêtre de maintenance, une sauvegarde, et une validation post-installation.

Étapes immédiates recommandées

  • identifier toutes les instances EMS ;
  • confirmer leur version ;
  • télécharger le correctif ou la version cible depuis le portail officiel Fortinet ;
  • effectuer une sauvegarde de la configuration et, si possible, un snapshot système ;
  • appliquer la mise à jour selon la procédure éditeur ;
  • redémarrer les services si nécessaire ;
  • vérifier la version finale et le bon fonctionnement des communications avec les endpoints ;
  • retirer ou filtrer l’accès Internet à l’interface d’administration.

Exemple de vérification et d’arrêt préventif des services

Avant maintenance, il peut être utile d’identifier les services liés à EMS :

Get-Service | Where-Object { $_.DisplayName -match "Forti|EMS" -or $_.Name -match "Forti|EMS" }

Si la procédure Fortinet l’exige, arrêt contrôlé des services avant installation :

Stop-Service -Name "NomDuServiceEMS"

Après installation, redémarrage :

Start-Service -Name "NomDuServiceEMS"

Le nom exact des services dépend de la version et du packaging ; il faut se référer à la documentation de l’éditeur.

Exemple de vérification de version après correctif

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" | Where-Object { $_.DisplayName -match "FortiClient EMS" } | Select-Object DisplayName, DisplayVersion

Après patch, la version affichée doit correspondre à la version corrigée indiquée dans l’avis Fortinet. Toute ambiguïté doit être levée par contrôle dans l’interface d’administration et par comparaison avec la matrice de versions de l’éditeur.

Retrait de l’exposition Internet

Le correctif est indispensable, mais il ne remplace pas la réduction de surface d’attaque. Une console EMS ne devrait pas être accessible publiquement sans filtrage strict. Les mesures minimales sont :

  • restriction d’accès par liste blanche d’adresses IP ;
  • publication derrière un VPN ou un bastion d’administration ;
  • segmentation réseau dédiée ;
  • désactivation de toute publication directe inutile via NAT ou reverse proxy ;
  • journalisation renforcée des accès administratifs ;
  • MFA en amont si l’architecture le permet.

Sur un pare-feu Linux ou une passerelle intermédiaire, un filtrage d’urgence peut ressembler à :

iptables -A INPUT -p tcp --dport 443 -s 203.0.113.10 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP

Ou avec nftables :

nft add rule inet filter input tcp dport 443 ip saddr 203.0.113.10 accept nft add rule inet filter input tcp dport 443 drop

Dans un contexte cloud chez OVHcloud ou Scaleway, il faut aussi vérifier les security groups, ACL réseau, règles de load balancer et publications DNS. Une console “non exposée” côté serveur peut rester accessible via un proxy, une règle NAT historique ou un enregistrement DNS oublié.

Détection

Lorsqu’une faille est activement exploitée pour pousser un malware, la détection ne doit pas se limiter au serveur vulnérable. Il faut rechercher des signes de compromission sur EMS, sur le réseau, et sur les postes administrés. La logique de chasse doit couvrir la période comprise entre l’exposition publique de la console, la publication de la faille et la date de correction effective.

Indicateurs de compromission côté serveur EMS

  • connexions à l’interface d’administration depuis des adresses IP inconnues ;
  • requêtes HTTP atypiques vers des routes d’administration sans séquence de connexion normale ;
  • création de comptes administratifs non autorisés ;
  • modification de politiques ou de packages de déploiement ;
  • changements de configuration hors fenêtre de maintenance ;
  • fichiers déposés dans des répertoires applicatifs ou temporaires ;
  • processus enfants anormaux lancés par des services liés à EMS ;
  • communications sortantes inhabituelles depuis le serveur.

Les journaux à examiner en priorité incluent :

  • journaux applicatifs EMS ;
  • journaux IIS si EMS s’appuie sur des composants web Microsoft ;
  • journaux Windows Event ;
  • logs du reverse proxy ou du WAF ;
  • journaux du pare-feu en entrée et en sortie ;
  • historique des tâches planifiées et des services.

Exemples de recherches PowerShell utiles :

Get-WinEvent -LogName Security -MaxEvents 500 | Where-Object { $_.Message -match "Forti|EMS|logon|service" }
Get-ScheduledTask | Where-Object { $_.TaskName -match "Forti|EMS" -or $_.TaskPath -match "Forti|EMS" }
Get-ChildItem "C:\Windows\Temp","C:\Temp" -Recurse -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object FullName, LastWriteTime -First 100

IoC réseau et HTTP

Sans disposer d’un jeu d’IoC universel, plusieurs motifs doivent attirer l’attention :

  • pics de requêtes HTTPS vers EMS depuis des IP géographiquement incohérentes ;
  • accès à des routes d’administration sans authentification préalable visible ;
  • séquences de requêtes très courtes suivies de changements de configuration ;
  • téléchargements ou envois de packages depuis des sources non habituelles ;
  • communications sortantes du serveur vers des domaines récents ou à faible réputation ;
  • résolution DNS anormale depuis le serveur EMS ;
  • volumétrie inhabituelle entre EMS et les endpoints après une action administrative non planifiée.

Sur un proxy ou un SIEM, il est utile de rechercher des accès avec des User-Agent atypiques, des réponses 200 ou 302 sur des routes sensibles, et des actions d’administration exécutées en dehors des horaires habituels.

IoC côté endpoints administrés

Comme l’exploitation observée vise le déploiement d’un infostealer, les endpoints gérés par EMS doivent être considérés comme potentiellement touchés. Les signes à rechercher incluent :

  • installation récente d’exécutables ou packages non validés ;
  • création de services, tâches planifiées ou clés de persistance ;
  • processus inconnus exécutés depuis %ProgramData%, %AppData% ou des répertoires temporaires ;
  • accès anormaux aux bases de données de navigateurs ;
  • exfiltration vers des domaines ou IP non reconnus ;
  • alertes EDR sur vol de credentials, dump de navigateurs ou collecte de cookies ;
  • modification récente de politiques EMS reçues par les agents.

Exemples de vérifications rapides sur un poste Windows :

Get-Process | Sort-Object CPU -Descending | Select-Object -First 30 Name, Id, Path
Get-ChildItem "$env:ProgramData","$env:AppData","$env:LOCALAPPDATA\Temp" -Recurse -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object FullName, Length, LastWriteTime -First 200
Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location

Il faut également corréler ces éléments avec les événements de déploiement EMS : quels packages ont été poussés, à quelle date, vers quels groupes de machines, et par quel compte ou quelle API.

Chasse aux compromissions et rotation de secrets

Si une exploitation est suspectée, la réponse doit inclure :

  • isolation du serveur EMS ;
  • gel des déploiements sortants ;
  • export et sauvegarde des journaux ;
  • analyse des packages et scripts distribués récemment ;
  • rotation des comptes administratifs EMS ;
  • rotation des secrets stockés ou accessibles depuis le serveur ;
  • réinitialisation des identifiants potentiellement volés sur les endpoints touchés ;
  • vérification des accès VPN et SSO associés aux utilisateurs concernés.

Dans un environnement structuré, cette étape doit être pilotée avec l’équipe SOC, les administrateurs Windows, l’équipe réseau et les responsables IAM. Si une note du CERT-FR est publiée, elle doit être intégrée au dispositif de réponse, notamment pour les recommandations de journalisation et de confinement.

Mitigation

Lorsque le patch ne peut pas être appliqué immédiatement, il faut réduire drastiquement le risque d’exploitation. Ces mesures ne remplacent pas la correction, mais elles peuvent limiter l’exposition pendant la fenêtre de maintenance.

  • retirer toute exposition Internet directe de la console EMS ;
  • restreindre l’accès à un bastion ou à un VPN d’administration ;
  • mettre en place une liste blanche d’IP source ;
  • désactiver temporairement les fonctions de déploiement non indispensables si l’architecture le permet ;
  • renforcer la surveillance des journaux HTTP, système et réseau ;
  • vérifier l’intégrité des packages et politiques disponibles dans EMS ;
  • désactiver ou suspendre les comptes administratifs non utilisés ;
  • activer des alertes sur toute création de package, de compte ou de politique.

Une mitigation utile consiste aussi à déplacer l’accès d’administration derrière un contrôle d’accès réseau fort. Par exemple :

  • publication uniquement sur un réseau privé via VPN IPsec ou SSL VPN ;
  • accès via bastion avec journalisation centralisée ;
  • contrôle géographique ou ASN si le pare-feu le permet ;
  • désactivation de la résolution DNS publique du portail d’administration.

Si l’instance EMS est hébergée chez un prestataire ou dans un cloud public, il faut demander explicitement la revue des chemins d’accès externes : IP publique, équilibrage de charge, reverse proxy, règles de publication, tunnels d’administration, et DNS. Dans de nombreux incidents, l’exposition persiste à cause d’un composant intermédiaire oublié.

Mesures de durcissement complémentaires

Au-delà de l’urgence, ce type d’incident justifie une revue plus large :

  • inventaire des consoles d’administration exposées ;
  • suppression des accès Internet directs non indispensables ;
  • mise en place de MFA et de bastions ;
  • segmentation des serveurs de gestion ;
  • surveillance des actions à fort impact ;
  • politique de patching accéléré pour les outils d’administration ;
  • tests de restauration et de reconstruction de confiance ;
  • revue des dépendances entre console de gestion et endpoints.

Cette approche rejoint les pratiques de hardening et de réduction de surface d’attaque à appliquer sur l’ensemble des serveurs exposés, en particulier les composants d’administration. Des ressources complémentaires de durcissement sont disponibles dans la catégorie /categorie/pratiques.

La priorité opérationnelle autour de CVE-2026-35616 est simple : patcher FortiClient EMS vers la version corrigée publiée par Fortinet, supprimer l’exposition Internet des consoles, puis mener une revue de compromission côté serveur et côté endpoints. Dans un contexte d’exploitation active avec déploiement d’infostealer, attendre le prochain cycle de maintenance est un pari risqué. Toute organisation utilisant EMS comme point central de gestion doit traiter l’incident comme un sujet de sécurité serveur à fort impact métier, avec validation des versions, contrôle des journaux, rotation des secrets si nécessaire, et durcissement durable des accès d’administration. Pour compléter cette démarche avec des mesures de réduction de surface d’attaque et de durcissement, la catégorie /categorie/pratiques constitue un prolongement utile.

Sources citées : l’avis de sécurité officiel Fortinet relatif à CVE-2026-35616 doit servir de référence primaire pour les versions affectées et corrigées ; le signalement d’exploitation active et de déploiement d’infostealer a été relayé publiquement par BleepingComputer dans la dépêche consacrée à cette faille.

Rubrique Serveurs
Partager
Retour aux actualités