Fortinet corrige un zero-day FortiMail déjà exploité pour écrire des fichiers arbitraires
La CVE-2026-104286, notée CVSS 9,8, laisse un attaquant non authentifié écrire des fichiers arbitraires sur l’interface d’administration de FortiMail via une traversée de chemin et un octet NULL. En attendant le correctif, désactivez l’IBE et coupez l’interface de gestion d’Internet.
1er octobre 2026. Fortinet publie un avis de sécurité FG-IR-26-175 signalant que la CVE-2026-104286, une faille critique de FortiMail, est déjà exploitée dans des attaques de type zero-day. 1er octobre 2026. La vulnérabilité, notée CVSS 9,8, combine une traversée de chemin (CWE-22) et une neutralisation incorrecte d’un octet NULL (CWE-158) pour laisser un attaquant non authentifié écrire des fichiers arbitraires sur le système sous-jacent. 1er octobre 2026. Aucun correctif n’est encore disponible pour la plupart des branches : Fortinet demande d’appliquer un contournement immédiat. Pourquoi c’est important : FortiMail est une passerelle de messagerie déployée en bordure de réseau, et une écriture de fichier arbitraire sur sa console d’administration peut se transformer en prise de contrôle complète de l’appliance.
Une traversée de chemin doublée d’un octet NULL
La mécanique tient en une phrase. L’interface d’administration de FortiMail ne borne pas correctement les chemins d’accès transmis par le client, et neutralise mal l’octet NULL (\0) qui permet, dans certains langages, de tronquer une chaîne avant sa vérification. Résultat : un attaquant qui envoie des requêtes HTTP ou HTTPS spécialement construites peut faire écrire au service des fichiers à l’emplacement de son choix, sans jamais s’authentifier.
Le couple CWE-22 + CWE-158 est un classique du path traversal qui revient régulièrement sur les appliances réseau. La traversée de chemin autorise la sortie du répertoire attendu (../../), tandis que l’octet NULL sert à faire accepter un chemin malveillant par une couche de contrôle qui s’arrête à la fin de la chaîne. Les deux, combinés, transforment un simple bogue de validation en primitif d’écriture arbitraire — la brique de base de la plupart des prises de contrôle à distance.
Le danger est démultiplié par la position de FortiMail dans l’infrastructure. La passerelle traite le flux de messagerie d’une organisation, héberge des politiques antispam, des clés de chiffrement et, souvent, des comptes à privilèges. Une écriture de fichier arbitraire peut déposer un webshell sur la console, modifier des fichiers de configuration, ou altérer des binaires pour persister au-delà d’un simple redémarrage.
Ce qu’une écriture arbitraire permet concrètement
Une primitive d’écriture de fichier arbitraire n’est pas une exécution de code à proprement parler, mais elle y mène presque toujours. Sur une appliance comme FortiMail, elle ouvre au minimum trois portes.
La première est le dépôt d’un webshell : un fichier placé dans un répertoire servi par le serveur web d’administration suffit à transformer l’écriture en exécution de commandes. La deuxième est la modification de la configuration — par exemple celle du moteur de routage ou des règles d’authentification — pour créer une porte dérobée discrète. La troisième est la corruption de fichiers système destinée à persister : remplacer un binaire, un script de démarrage ou un certificat pour que la compromission survive aux redémarrages et aux correctifs.
La CVE-2026-104286 est d’autant plus préoccupante qu’elle est exploitée dans la nature, selon Fortinet, sans qu’aucun détail public ne précise encore l’ampleur ni l’identité des attaquants. Le vecteur CVSS — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — confirme le pire scénario : accessible depuis le réseau, aucune interaction utilisateur requise, aucun privilège nécessaire, et un impact élevé sur la confidentialité, l’intégrité et la disponibilité.
Un périmètre large et un correctif encore absent
L’avis liste quatre branches affectées, soit l’essentiel du parc en production :
- FortiMail 8.0 : versions 8.0.0 à 8.0.1 — correctif prévu en 8.0.2 ;
- FortiMail 7.6 : versions 7.6.0 à 7.6.6 — correctif prévu en 7.6.7 ;
- FortiMail 7.4 : versions 7.4.0 à 7.4.8 — correctif prévu en 7.4.9 ;
- FortiMail 7.2 : versions 7.2.0 à 7.2.9 — branche en fin de vie, migration vers 7.4 exigée.
Le point notable : aucun correctif n’est encore publié. Les versions correctives sont « à venir ». C’est une configuration rare — un zero-day exploité, documenté publiquement, pour lequel l’éditeur impose de tenir sans patch. La faille a été découverte en interne par Gwendal Guégniaud, de l’équipe Product Security de Fortinet, ce qui suggère une détection en amont d’une divulgation externe, mais n’empêche pas l’exploitation observée sur le terrain.
La branche 7.2 mérite une attention particulière : elle est déjà en fin de support, et Fortinet ne prévoit aucun correctif — la seule issue est une montée de version vers 7.4. Pour une passerelle de messagerie en production, ce n’est pas une opération anodine, et les équipes concernées doivent la planifier immédiatement.
Les deux contournements à appliquer sans attendre
Faute de correctif, Fortinet propose deux contournements, à choisir selon l’exposition de l’appliance.
Le premier, et le plus efficace, consiste à désactiver la fonctionnalité IBE (Identity-Based Encryption), qui est le vecteur de la faille. La commande CLI est courte :
config system encryption ibe
set status disable
endLe second, complémentaire, est une hygiène réseau que toute appliance d’administration devrait déjà respecter : retirer l’interface de gestion d’Internet ou la restreindre à un réseau d’administration privé, idéalement derrière un VPN ou un bastion. Une console de FortiMail n’a aucune raison d’être joignable depuis l’Internet public, et c’est précisément l’exposition que l’attaquant exploite.
Ces deux mesures ne remplacent pas le correctif, mais elles neutralisent le vecteur le temps qu’il arrive. L’ordre recommandé est sans ambiguïté : désactiver l’IBE d’abord, car il supprime la faille à la source, puis segmenter l’accès à la console pour couvrir les autres failles éventuelles de l’interface.
Une cible de choix dans la ligne de mire
Ce zero-day s’inscrit dans une séquence plus large. Les appliances réseau — pare-feu, passerelles de messagerie, concentrateurs VPN — sont devenues les cibles privilégiées des attaquants, parce qu’elles sont exposées, peu surveillées à l’intérieur, et riches en accès. Fortinet, Cisco, Citrix, Ivanti, WatchGuard : la liste des éditeurs touchés par des failles exploitées en amont d’un correctif ne cesse de s’allonger en 2026.
La CVE-2026-104286 illustre un motif récurrent : la surface d’administration est le maillon faible. Qu’il s’agisse d’une traversée de chemin ici, d’un contournement d’authentification chez Cisco la semaine dernière, ou d’une faille DTLS chez Citrix, le point d’entrée est presque toujours l’interface que l’on expose « parce qu’il faut bien l’administrer ». La réponse est structurelle : aucune console de gestion ne doit être joignable depuis Internet.
La leçon est limpide. La CVE-2026-104286 se défend en deux gestes simples — désactiver l’IBE et retirer la console d’Internet — qui, combinés, couvrent l’essentiel du risque sans attendre le correctif. Ce sont ces réflexes, plus que le patch à venir, qui feront la différence entre une appliance compromise et une alerte de plus dans le flux RSS.
Verdict
Si votre FortiMail expose sa console d’administration sur Internet, appliquez le contournement dès maintenant : désactivez l’IBE et restreignez l’accès à un réseau d’administration. La faille est exploitée, notée CVSS 9,8, et aucun correctif n’est disponible — vous n’avez pas le luxe d’attendre. Si vous êtes en FortiMail 7.2, planifiez dès cette semaine la migration vers 7.4 : la branche ne recevra pas de patch. Dans tous les cas, inscrivez le correctif (8.0.2, 7.6.7 ou 7.4.9) au plus haut de votre backlog et appliquez-le dès publication — le contournement achète du temps, il ne remplace pas la rustine.