Une faille zero-day dans FortiMail permet à des attaquants non authentifiés d’écrire des fichiers système

CVE-2026-104286 : faille zero-day FortiMail CVSS 9,8 exploitée sans authentification pour écrire des fichiers. Versions touchées et correctifs.

Une faille zero-day dans FortiMail permet à des attaquants non authentifiés d’écrire des fichiers système
Vulnérabilités

Image d’illustration générée par IA

Une vulnérabilité critique de Fortinet FortiMail est exploitée contre des interfaces d’administration accessibles depuis Internet, selon un rapport publié le 1er octobre 2026.

Référencée sous le numéro CVE-2026-104286 et désignée en interne FG-IR-26-175, cette faille peut permettre à un attaquant non authentifié d’écrire des fichiers arbitraires sur le système d’exploitation sous-jacent de l’appliance. Selon BleepingComputer, les attaques observées ont exploité la vulnérabilité pour exécuter du code ou des commandes sans autorisation.

La vulnérabilité affiche un score CVSS de 9,8. Fortinet a attribué sa découverte en interne à Gwendal Guégniaud, membre de l’équipe Product Security.

Des requêtes web conçues pour contourner le chemin d’accès prévu

CVE-2026-104286 touche l’interface d’administration de FortiMail. Fortinet classe les problèmes sous-jacents comme une traversée de chemin, identifiée par CWE-22, et une mauvaise gestion d’un octet ou caractère NULL, identifiée par CWE-158.

Un attaquant peut envoyer des requêtes HTTP ou HTTPS conçues pour amener l’appliance à écrire des fichiers en dehors de l’emplacement prévu par l’application. Aucune authentification n’est nécessaire.

Son vecteur CVSS est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Il décrit une vulnérabilité exploitable à distance, de faible complexité, qui ne nécessite ni privilèges ni interaction de la part d’un utilisateur. Une exploitation réussie peut avoir un impact élevé sur la confidentialité, l’intégrité et la disponibilité.

L’écriture de fichiers arbitraires est le mécanisme d’exploitation documenté. Selon l’emplacement et le contenu des fichiers écrits, cette capacité peut modifier le comportement de l’application ou y introduire des composants exécutables. Le rapport du 1er octobre décrit les activités examinées comme permettant l’exécution de commandes ou de code sans autorisation.

Cette distinction est importante : la description de Fortinet établit que la vulnérabilité permet d’écrire des fichiers sans authentification, tandis que les éléments rapportés sur les attaques montrent comment l’exploitation s’est manifestée sur les appliances touchées.

Quatre branches prises en charge de FortiMail comportent des versions vulnérables

Les versions concernées sont les suivantes :

Branche FortiMail Versions vulnérables
8.0 8.0.0 à 8.0.1
7.6 7.6.0 à 7.6.6
7.4 7.4.0 à 7.4.8
7.2 7.2.0 à 7.2.9

Pour FortiMail 7.2, les recommandations rapportées par Fortinet préconisent de passer à la branche 7.4 ou à une version ultérieure. Les administrateurs doivent tenir compte de cette recommandation de mise à niveau vers une branche ultérieure ainsi que des informations sur les versions corrigées : les versions jusqu’à 7.4.8 sont concernées, tandis que 7.4.9 était annoncée comme une prochaine version corrective.

Selon le rapport, aucun correctif n’était encore disponible pour les installations concernées des branches 7.4, 7.6 et 8.0. Fortinet a indiqué que les versions suivantes devraient corriger la faille :

  • FortiMail 7.4.9
  • FortiMail 7.6.7
  • FortiMail 8.0.2

En attendant la disponibilité et l’installation d’une version corrective adaptée, Fortinet recommande de désactiver la prise en charge d’IBE :

config system encryption ibe
set status disable
end

L’autre mesure temporaire consiste à couper l’accès Internet à l’interface d’administration de FortiMail. Si l’administration à distance reste nécessaire, son accès doit être limité aux réseaux privés de confiance.

Les administrateurs ne doivent pas considérer le filtrage réseau comme une preuve que l’appliance est saine. Les systèmes précédemment exposés doivent toujours faire l’objet de vérifications au regard des indicateurs publiés.

Fichiers, empreintes et indicateurs réseau pour rechercher une compromission

Fortinet a fourni plusieurs indicateurs de fichiers associés aux activités rapportées. Certains correspondent à des fichiers ajoutés, d’autres à des fichiers existants modifiés.

Fichier État rapporté SHA-256
/data/lib/liblog.so Ajouté 8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84
/bin/smit Modifié 77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a
/data/bin/webconsole Ajouté 7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38
/data/bin/mailservice Ajouté 4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b
/data/etc/httpd.conf Modifié 703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5
/data/etc/ld.so.preload Ajouté 8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6
/data/migadmin.tar.gz Modifié d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3

Les adresses IP associées aux attaques sont les suivantes :

  • 79[.]141.169.187
  • 45[.]129.0.192

Ces indicateurs doivent servir de pistes d’investigation, et non de liste de vérification obligatoire. Les informations disponibles ne permettent pas d’affirmer que chaque appliance compromise contient tous les fichiers ou toutes les traces répertoriés.

Les vérifications doivent porter sur l’intégrité des fichiers, la comparaison des empreintes, l’examen des requêtes adressées à l’interface d’administration et l’analyse des connexions sortantes vers les deux adresses. Les administrateurs doivent également rechercher les changements de configuration et les mécanismes de persistance, notamment les modifications touchant au chargement des services ou à l’exécution de tâches planifiées.

Les journaux font état d’une activité shell et d’une possible destination d’archive

Parmi les exemples fournis par Fortinet figure un événement de débogage cron dans lequel root lance une commande commençant par :

/bin/sh -c 'O=/migadmin ...

L’extrait fourni est tronqué et ne révèle ni la commande complète ni son résultat final. Toutefois, l’association d’un shell root, d’une exécution cron et d’une référence à /migadmin rend cet événement pertinent pour le triage forensique.

Un autre événement consigne la création, depuis l’interface en ligne de commande, d’un compte d’archivage nommé archive234. Il indique le serveur distant 79.141.169.187 et le répertoire /uploads, ainsi que les paramètres suivants :

  • Taille de rotation : 50
  • Intervalle de rotation : 1
  • Heure de rotation : 14
  • Mot de passe distant : masqué dans l’exemple

Cette configuration aurait pu servir à envoyer des informations archivées vers l’hôte distant. À elle seule, cette entrée de journal ne prouve pas qu’un transfert de données a abouti.

D’autres exemples font état d’une déconnexion réussie de admin, de tentatives d’authentification infructueuses pour un utilisateur interne représenté par *@domain.tld, ainsi que d’une erreur de déchiffrement IBE. Cette dernière signale un encodage Base64 invalide à la position 0, impliquant le caractère de valeur 0x2a.

Les défenseurs doivent corréler chronologiquement ces événements avec le trafic HTTP ou HTTPS vers l’interface d’administration, les changements de configuration, les horodatages des fichiers, l’activité cron et les sessions réseau sortantes. Un seul événement concordant ne suffit pas à reconstituer l’ensemble de l’intrusion.

La CISA fixe au 4 octobre la date limite de correction

La CISA a ajouté CVE-2026-104286 à son catalogue des vulnérabilités exploitées connues (KEV) le 1er octobre 2026. Les agences fédérales américaines doivent corriger la faille avant le 4 octobre 2026.

Elles doivent appliquer les mesures d’atténuation de Fortinet, conformément à la BOD 26-04 sur la priorisation des mises à jour de sécurité selon le risque et aux exigences de triage forensique de la CISA. Les organisations concernées doivent évaluer l’exposition à Internet de chaque équipement et respecter les consignes de mise à jour applicables de la BOD 26-04.

Pour les services cloud, les agences doivent suivre les instructions correspondantes de la BOD 26-04 ou cesser d’utiliser le produit si aucune mesure d’atténuation n’est disponible.

L’inscription au catalogue KEV confirme que l’exploitation n’est pas hypothétique. Les priorités opérationnelles sont donc de restreindre l’accès à l’interface d’administration, de désactiver la prise en charge d’IBE le cas échéant, de mener un triage forensique et d’installer la version corrective adaptée dès qu’elle sera disponible.

L’ampleur des attaques reste inconnue

Fortinet a indiqué à BleepingComputer échanger avec des organismes gouvernementaux, dont la CISA, et a renvoyé les clients à son avis de sécurité pour connaître les mesures correctives à appliquer.

Les informations disponibles ne permettent pas d’attribuer les attaques ni de déterminer le nombre total de systèmes compromis. Elles ne précisent pas non plus quand l’exploitation a commencé.

Ces zones d’ombre empêchent de tirer des conclusions sur l’ampleur de la campagne et l’identité de ses auteurs, mais ne changent rien à l’urgence de la réponse. Toute organisation qui utilise une version de FortiMail concernée doit considérer qu’une exposition antérieure de l’interface d’administration justifie une investigation, plutôt que de compter uniquement sur l’installation ultérieure d’une version corrigée.

Dossiers sécurité

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

CVE traitées dans cet article

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →