La décision a été aussi rapide que peu courante : Fortinet a désactivé temporairement la fonctionnalité d’authentification unique (SSO) de FortiCloud après avoir confirmé l’exploitation active d’une vulnérabilité zéro-day touchant plusieurs de ses produits les plus déployés. La faille, identifiée par le fabricant sous le nom FG-IR-26-060 et référencée comme CVE-2026-24858, permet à un attaquant disposant d’un compte FortiCloud et d’un dispositif enregistré de se connecter à des appareils liés à d’autres comptes, dès lors que le SSO de FortiCloud est activé sur ces équipements.
Ce incident met en lumière un problème de fond qui inquiète de plus en plus les équipes de sécurité : la commodité de la gestion cloud et du SSO peut devenir une surface d’attaque critique lorsque l’authentification se transforme, en pratique, en un « pass VIP » permettant d’administrer des infrastructures. La vulnérabilité est classifiée comme omission d’authentification par voie ou canal alternatif (CWE-288), une catégorie bien connue mais particulièrement sensible lorsqu’elle est combinée à des accès administratifs.
Ce qui distingue cette vulnérabilité zéro-day : ce n’est pas un bug isolé, mais un pattern
Selon l’analyse publiée par Fortinet, cet incident partage des similitudes avec la vague de décembre 2025 liée au contournement du SSO (CVE-2025-59718 et CVE-2025-59719), mais avec une nuance clé : en janvier, des cas ont été détectés où l’accès non autorisé concernait des appareils qui étaient déjà à jour avec la dernière version disponible au moment de l’attaque, ce qui indiquait une nouvelle voie d’exploitation.
La société a également clarifié un point qui avait suscité des inquiétudes initiales : bien qu’on craignait une propagation plus large affectant les implémentations SAML, il a finalement été confirmé que l’incident concerne exclusivement FortiCloud SSO et non les fournisseurs d’identités SAML tiers ou FortiAuthenticator. Cette précision est essentielle pour limiter le risque dans les environnements à identité fédérée, où tous les SSO n’ont pas la même configuration.
Chronologie : comptes malveillants, coupure du SSO et réactivation avec « blocage par version »
La riposte s’est accélérée en quelques jours :
- 22–23 janvier 2026 : Fortinet a désactivé les comptes FortiCloud utilisés lors des attaques, selon sa propre chronologie publique.
- 26 janvier 2026 : le fournisseur a coupe le SSO de FortiCloud pour freiner l’abus.
- 27 janvier 2026 : le service a été rétabli, mais avec une modification comparable à la mise en place d’un pare-feu : FortiCloud SSO a cessé d’accepter les connexions depuis des appareils en versions vulnérables, incitant les organisations à mettre à jour leurs systèmes pour continuer à utiliser ce flux d’authentification.
Par ailleurs, CISA a publié une alerte concernant une exploitation en cours, et selon le registre NVD, le 27 janvier 2026, la CVE a été ajoutée au catalogue KEV avec une date limite de remédiation fixée au 30 janvier 2026 pour les entités fédérales, preuve claire de l’urgence.
Produits et versions impactés : une correction par branches, pas un simple « bouton »
Les notices techniques détaillent une portée étendue, notamment lorsque le SSO de FortiCloud est activé. En pratique, le défi opérationnel réside dans le fait que les mises à jour dépendent de la branche installée.
Selon l’alerte d’INCIBE, les chemins recommandés incluent notamment :
- FortiOS : mettre à jour vers 7.6.6 ou supérieur ; 7.4.11 ou supérieur ; 7.2.13 ou supérieur ; 7.0.19 ou supérieur.
- FortiManager : 7.6.6+, 7.4.10+, 7.2.13+, 7.0.16+.
- FortiAnalyzer : 7.6.6+, 7.4.10+, 7.2.12+, 7.0.16+.
- FortiProxy : 7.6.6+, 7.4.13+ ; pour les branches 7.2/7.0, il est conseillé de migrer vers une version corrigée.
De plus, le registre du NVD (NIST) recense également une vulnérabilité affectant FortiWeb dans plusieurs branches (8.0.0–8.0.3, 7.6.0–7.6.6, 7.4.0–7.4.11), renforçant l’idée d’un problème transversal dans l’écosystème lorsque l’authentification cloud est concernée.
Signes de compromission : l’attaque laisse des traces, mais celles-ci peuvent sembler « légitimes »
Une des difficultés majeures de cette affaire est que la trace initiale peut être confondue avec un accès valide : une connexion via SSO suivie d’actions administratives.
Fortinet a fourni des indicateurs concrets : deux comptes observés lors des connexions, plusieurs adresses IP (dont certaines protégées par Cloudflare), ainsi qu’un schéma répété de création de comptes admin locaux pour assurer une persistance. La société a aussi publié des exemples de logs avec des identifiants d’événements pour “connexion administrateur réussie” et “attribut d’objet configuré”, typiques lors de l’ajout d’un nouvel administrateur.
Le risque opérationnel ne se limite pas au contrôle du dispositif : certains reports décrivent que les acteurs ont téléchargé des configurations après leur accès, un scénario particulièrement sensible puisqu’il permettrait d’exposer des règles, VPN, segmentation, routes et mécanismes d’authentification. Certains médias évoquent même des campagnes automatisées et un nombre élevé de terminaux potentiellement compromis.
Priorités pour les équipes IT et de sécurité
Dans un environnement technologique, le message principal est simple : il ne s’agit pas seulement d’appliquer un correctif « au dernier moment ». L’enjeu est de réduire la surface d’attaque et d’interrompre le vecteur dès que possible, car il s’agit d’une faille d’accès administratif.
Voici quelques mesures recommandées :
- Vérifier si le SSO FortiCloud est activé sur les équipements en bout de réseau et en gestion. Si ce n’est pas indispensable, le désactiver temporairement en attendant la mise à jour.
- Mettre à jour par branche vers des versions corrigées (ou migrer si la branche ne bénéficie pas d’un correctif direct), en privilégiant les actifs exposés ou accessibles depuis Internet.
- Analyser les comptes administrateurs (locaux et distants) pour repérer des ajouts inattendus, des changements de profil ou des connexions via SSO en horaires anormaux.
- Restreindre l’administration (par exemple, via des politiques “local-in”, des listes d’IP de confiance ou la réduction des services exposés), une pratique classique qui devient critique lorsque l’identité centralisée échoue.
- En cas de compromission : changer les identifiants, réaliser une audite des intégrations (VPN/LDAP) et vérifier l’intégrité de la configuration avant de faire confiance à l’appareil.
Leçons pour 2026 : l’identité cloud comme infrastructure critique
Ce cas illustre une idée qui dépasse Fortinet : lorsque un fabricant transforme le SSO cloud en une expérience « sans friction », cela accélère le secteur… mais augmente aussi le niveau de risque. Et lorsqu’un bypass apparaît, l’incident devient systémique : il ne s’agit plus d’atteindre une seule machine, mais de remettre en cause un mode opératoire entier.
La réaction même — désactiver le SSO fournisseur pour le réactiver en bloquant les versions vulnérables — montre à quel point la frontière entre sécurité, continuité et contrôle se déplace. Pour de nombreuses organisations, le défi immédiat est technique (corriger, auditer). Le défi stratégique, lui, consiste à élaborer des opérations pouvant continuer même lorsque le « cerveau » de l’authentification cloud rencontre une défaillance temporaire.
Questions fréquentes
Comment vérifier si le SSO FortiCloud est activé et pourquoi est-ce crucial dans le cadre de CVE-2026-24858 ?
L’exploitation décrite s’active lorsque le login administratif via FortiCloud SSO est activé. Les alertes recommandent de le vérifier explicitement, car il peut rester activé lors de l’enregistrement si l’option n’est pas désélectionnée.
Quelles versions de FortiOS doivent être considérées comme « minimum » pour mitiger FG-IR-26-060 ?
Cela dépend de la branche concernée : les guides publics recommandent de viser des versions comme 7.6.6, 7.4.11, 7.2.13 ou 7.0.19 (ou supérieures), ainsi que des versions équivalentes pour FortiManager et FortiAnalyzer.
Quels logs peuvent indiquer une exploitation du SSO ou la création de comptes administrateurs à des fins de persistance ?
Fortinet a publié des indicateurs et exemples de logs liés à des connexions via SSO et à l’ajout d’administrateurs locaux. La recommandation pratique est de croiser les événements “connexion SSO” + “création d’admin” + “exportation ou téléchargement de configuration”.
Pourquoi CISA a-t-elle élevé le niveau d’urgence et que signifient les dates dans le catalogue KEV ?
Le registre NVD montre que la CVE a été ajoutée au KEV le 27 janvier 2026, avec une date limite de remédiation fixée au 30 janvier 2026 pour le secteur fédéral, ce qui témoigne de l’exploitation active et de la priorité absolue à la mitigation.
