Analyse · Exposition
FortiMail : une faille exploitée avant le correctif
Du 1er au 5 octobre 2026, une faille FortiMail exploitée n'avait qu'un contournement. Décision de risque tracée, recherche de compromission, angle MSP.
Par Sentrix · Publié le 2026-10-05
Le 1er octobre 2026, Fortinet a publié le bulletin FG-IR-26-175 sur une faille de FortiMail déjà exploitée, et la CISA l'a ajoutée le même jour à son catalogue des vulnérabilités exploitées (KEV). Pendant les premiers jours, la seule réponse disponible était un contournement. Ce scénario n'est pas rare, et il demande une méthode différente de la correction habituelle.
Ce que disent les bulletins
Fortinet (FG-IR-26-175, publié le 1er octobre, mis à jour le 5 octobre). La faille CVE-2026-104286, cotée 9,8 sur l'échelle CVSS, est décrite ainsi : « An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests. » Le bulletin précise : « This has been reported to be exploited in the wild. »
Les versions touchées sont 8.0.0 à 8.0.1, 7.6.0 à 7.6.6, 7.4.0 à 7.4.8 et 7.2.0 à 7.2.9. Le bulletin mis à jour indique de passer à 8.0.2, 7.6.7 ou 7.4.9 et plus. Pour la branche 7.2, il n'y a pas de version corrigée : Fortinet demande de passer à la branche 7.4 ou plus récente. En attendant, deux contournements : désactiver la fonction IBE (Identity-Based Encryption) ou restreindre l'accès à l'interface webmail aux réseaux de confiance.
La CISA (1er octobre). L'agence a inscrit CVE-2026-104286 au catalogue KEV le jour même de la publication du bulletin. L'inscription signifie que l'exploitation est avérée, pas seulement possible.
Les premières analyses (2 octobre). Truesec écrivait alors : « Currently there are no patches available, here are the current workaround as provided by Fortinet's PSIRT. » Pendant cette fenêtre, une organisation exposée n'avait que deux choix : couper la fonction ou couper l'accès.
Pourquoi ça compte
La plupart des processus de gestion des vulnérabilités sont écrits pour un seul cas : un correctif existe, on le planifie, on le déploie, on le vérifie. Le cas FortiMail en montre un autre, plus dangereux : la faille est exploitée, publique, et il n'y a rien à installer. Si le processus ne prévoit pas ce cas, la décision se prend dans l'urgence, sans trace, et le contournement reste en place des mois après la sortie du correctif, ou disparaît lors d'un changement de configuration sans que personne le remarque.
Deuxième leçon : une passerelle de messagerie est un actif de bordure, exposé à Internet, au même titre qu'un VPN ou un pare-feu. Elle doit figurer dans l'inventaire d'exposition avec sa version, sa branche et les fonctions activées. Savoir en quelques minutes si la fonction IBE est active sur vos appareils, c'est savoir si vous êtes exposé.
Troisième leçon : l'exploitation précède souvent le bulletin. Une faille qui permet d'écrire des fichiers sans authentification laisse des traces possibles. Appliquer le contournement ferme la porte, mais ne dit rien de ce qui est déjà entré.
Ce que nous en pensons chez Sentrix
Une faille exploitée sans correctif se traite en quatre temps :
- Savoir en une heure si vous êtes exposé. Version, branche, fonction IBE, interface webmail joignable depuis Internet ou non. C'est l'inventaire que le module CTEM d'exposition continue tient à jour, actif par actif, avec un propriétaire par ligne.
- Faire du contournement une décision de risque tracée. Qui l'a décidé, sur quels appareils, à quelle date, jusqu'à quand, et la preuve qu'il est appliqué. La date de fin est celle de la mise à jour, pas « plus tard ».
- Chercher une compromission avant de corriger. Fichiers inattendus, comptes ou règles ajoutés, configuration modifiée. Conservez les journaux avant la mise à jour, qui peut effacer des traces. Notre service de réponse aux incidents prend le relais si vous trouvez quelque chose.
- Mettre à jour dès la sortie de la version corrigée, puis retirer le contournement seulement si la fonction est nécessaire, et fermer la décision de risque. Les branches 7.2 doivent passer à la branche 7.4 ou plus récente.
Pour un MSP ou un MSSP, l'enjeu est la simultanéité. La même passerelle tourne chez plusieurs clients. La décision doit être prise une fois, appliquée le même jour chez tous les clients touchés, et tracée client par client. Une vue unique de l'exposition de tous les clients transforme une nuit d'appels en une liste de travail.
Le catalogue KEV sert d'étalon pour la priorité : voir notre article sur la priorisation des correctifs avec le catalogue KEV et celui sur les cinq étapes du CTEM. Notre service de gestion des vulnérabilités et des correctifs applique la même méthode au quotidien.
La prochaine étape
Écrivez dès aujourd'hui, dans votre procédure de gestion des vulnérabilités, la section « faille exploitée sans correctif » : qui décide, en combien de temps, comment le contournement est tracé et quand il est retiré. Puis vérifiez que vos passerelles de messagerie figurent dans votre inventaire avec leur version. Si vous voulez faire l'exercice avec nous, contactez-nous.
Sources
Questions fréquentes
- Quelles versions de FortiMail sont touchées par CVE-2026-104286 ?
- Selon le bulletin FG-IR-26-175 de Fortinet : 8.0.0 à 8.0.1, 7.6.0 à 7.6.6, 7.4.0 à 7.4.8 et 7.2.0 à 7.2.9. Le bulletin, mis à jour le 5 octobre 2026, indique de passer à 8.0.2, 7.6.7 ou 7.4.9 et plus. La branche 7.2 n'a pas de version corrigée : Fortinet demande de passer à la branche 7.4 ou plus récente.
- Le contournement suffit-il si je ne peux pas mettre à jour tout de suite ?
- Il réduit l'exposition, il ne remplace pas la mise à jour. Fortinet propose de désactiver la fonction IBE (Identity-Based Encryption) ou de restreindre l'accès à l'interface webmail aux réseaux de confiance. Traitez-le comme une décision de risque temporaire : qui l'a prise, sur quels appareils, jusqu'à quelle date, et la preuve qu'elle est appliquée. Et vérifiez d'abord que l'appareil n'a pas déjà été compromis.
- Pourquoi chercher une compromission si j'ai appliqué le contournement ?
- Parce que la faille permet à un attaquant non authentifié d'écrire des fichiers arbitraires sur le système, et qu'elle était exploitée avant toute mesure. Un contournement appliqué le 3 octobre ne retire pas un fichier écrit le 30 septembre. Examinez les fichiers inattendus, les comptes et la configuration, et conservez les journaux avant toute mise à jour.
Parlons de votre programme de conformité.
Dernière mise à jour : 2026-10-05
