Après plusieurs jours de flou autour d’un possible contournement de correctif, Fortinet confirme l’exploitation active d’une nouvelle faille zero-day liée à FortiCloud SSO. En attendant les patchs, l’éditeur a bloqué les attaques directement côté serveur.
La campagne d’attaques observée la semaine dernière sur des pare-feu FortiGate vient de franchir un cap. Après avoir reconnu que des équipements à jour avaient malgré tout été compromis, Fortinet confirme désormais l’exploitation d’une nouvelle vulnérabilité critique, distincte de celle corrigée en décembre. En attendant la publication de tous les correctifs, l’éditeur a choisi une réponse inhabituelle mais immédiate, à savoir bloquer les connexions à risque directement via son infrastructure FortiCloud.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
D’un correctif incomplet à une nouvelle vulnérabilité
Après les premiers signalements publics, dont ceux relayés par Arctic Wolf, Fortinet avait d’abord rattaché les intrusions observées à CVE-2025-59718, une faille critique de contournement d’authentification liée à FortiCloud SSO, corrigée début décembre. Mais dans la foulée, des administrateurs avaient signalé des compromissions sur des pare-feu pourtant à jour, élément qui ne collait pas avec la seule hypothèse d’un patch manquant.
Le 23 janvier, Fortinet a fini par reconnaître publiquement que certains équipements parfaitement à jour avaient bien été touchés, évoquant l’existence probable d’un chemin d’attaque alternatif via FortiCloud SSO. Il n’aura pas fallu attendre beaucoup plus longtemps pour que l’éditeur tranche sur le sujet, confirmant une vulnérabilité distincte, désormais suivie sous la référence CVE-2026-24858, classée critique et affublée d’un score CVSS de 9.4.
Selon l’avis de sécurité publié, cette faille permettait à un attaquant disposant d’un compte FortiCloud et d’un appareil enregistré de se connecter en administrateur à des équipements d’autres organisations dès lors que FortiCloud SSO était activé, puis d’en télécharger la configuration et d’y créer un compte local pour s’y maintenir, y compris sur des systèmes pleinement corrigés contre les failles de décembre.
Une réponse d’urgence côté FortiCloud, prudence côté entreprises
À défaut de correctif immédiatement déployable, Fortinet a opté pour des mesures d’atténuation côté serveur. Le 23 janvier, l’éditeur a commencé par désactiver les comptes FortiCloud utilisés dans les attaques. Le 26 janvier, FortiCloud SSO a ensuite été désactivé pour enrayer les abus, avant la publication d’un avis public le 27 janvier.
Le même jour, l’accès FortiCloud SSO a été rétabli, sauf pour les appareils exécutant des versions vulnérables de FortiOS, FortiManager ou FortiAnalyzer. Fortinet renvoie vers son avis de sécurité et la liste des versions à installer selon les branches, certaines étant déjà disponibles, d’autres encore en cours de développement.
Dans tous les cas, si vous utilisez des pare-feu Fortinet et que la connexion via FortiCloud SSO est activée, surveillez en priorité l’enchaînement décrit par l’éditeur, à savoir une authentification SSO inattendue suivie d’un téléchargement de configuration puis de la création d’un compte administrateur local au nom générique. Si ces signaux apparaissent dans vos logs, l’équipement et sa configuration doivent être considérés comme compromis.
Il faudra alors vérifier l’ensemble des comptes administrateurs, puis faire tourner les identifiants, y compris ceux liés à un annuaire interne. Fortinet recommande aussi de restaurer une configuration issue d’une sauvegarde saine, plutôt que de conserver un état dont l’intégrité n’est plus garantie, et de restreindre strictement l’accès à l’interface d’administration à des réseaux de confiance. Enfin, si FortiCloud SSO n’est pas indispensable, désactivez-le pour réduire la surface d’exposition.
Sources : Fortinet [1], Fortinet [2]
