Fortinet corrige une vulnérabilité dans FortiOS permettant l’exécution de commandes système depuis la CLI : versions affectées, modèles impactés et plan d’action pour la mise à jour

Info Cloud

X (Twitter) Facebook Pinterest LinkedIn Email

Fortinet a publié un avis de sécurité concernant une vulnérabilité dans FortiOS, classée comme “Fourniture incorrecte de fonctionnalité spécifiée” (CWE-684). Cette faille pourrait permettre à un acteur malveillant authentifié localement d’exécuter des commandes système sur l’appareil en utilisant des ordres CLI conçus spécifiquement. La société a déjà publié des versions corrigées et précise quels branches et modèles FortiGate sont affectés.

Bien qu’il ne s’agisse pas d’une faille 0-day accessible à distance sans authentification, le risque opérationnel est conséquent : dans de nombreux environnements, la console CLI (SSH/console) est accessible à plusieurs opérateurs, comptes de service ou intégrations avec directories. Si l’un de ces accès est compromis — ou si une mauvaise séparation des privilèges existe —, un attaquant pourrait élargir son périmètre et prendre le contrôle du plan sous-jacent du pare-feu. C’est pourquoi une mise à jour rapide, couplée à des mesures de renforcement des accès administratifs, doit être une priorité.

Quelles versions de FortiOS sont concernées (et lesquelles corrigent la vulnérabilité)

Concernées
- FortiOS 7.6: 7.6.0
- FortiOS 7.4: de 7.4.0 à 7.4.5
- FortiOS 7.2: de 7.2.0 à 7.2.10
- FortiOS 7.0: de 7.0.0 à 7.0.15
- FortiOS 6.4: toutes les versions (aucune correction disponible dans cette branche; migration recommandée)
Versions corrigées
- 7.6.1 ou supérieur
- 7.4.6 ou supérieur
- 7.2.11 ou supérieur
- 7.0.16 ou supérieur
- Pour 6.4, Fortinet recommande migration vers une branche supportée intégrant le correctif.

La publication initiale de l’alerte date du 14 octobre 2025. En réseaux avec des exigences de disponibilité strictes, il est conseillé de planifier une fenêtre de maintenance dès que possible et de suivre la route de mise à jour recommandée par le fabricant pour changer de branche sans perdre en compatibilité.

Quels modèles FortiGate sont touchés

L’avis mentionne explicitement comme concernés les familles et modèles suivants :

100E/101E, 100F/101F
1100E/1101E
1800F/1801F
2200E/2201E
2600F/2601F
3300E/3301E, 3400E/3401E
3500F/3501F
3600E/3601E
3800D
3960E, 3980E
4200F/4201F
4400F/4401F
5001E
6000F
7000E, 7000F

Pour les autres modèles, ils ne figurent pas comme affectés dans ce bulletin. Cependant, si votre dispositif utilise une version vulnérable, vérifiez le modèle et programmez la mise à jour sans délai.

Pourquoi cette vulnérabilité est importante même si elle nécessite une authentification

Le vecteur nécessite une session valide (locale/CLI), mais en pratique :

De nombreuses organisations ont plusieurs administrateurs ou fournisseurs ayant accès.
Il est courant d’intégrer la gestion via LDAP/AD/RADIUS, ce qui augmente la surface d’attaque si une compte de domaine est compromis.
Il existe des jump-hosts et des VPN d’administration, qui, mal segmentés ou sans MFA, peuvent ouvrir des portes d’accès inappropriées.

Dans ce contexte, une faille qui augmente les capacités après authentification peut devenir un pivot critique : manipulation de politiques, implantation de persistance ou perturbation du trafic inspecté.

Plan d’action recommandé pour les équipes réseau et sécurité

1) Inventaire et vérification des versions

Recensez tous les FortiGate et notez modèle et version (en GUI : Dashboard → Firmware Version ; en CLI : get system status).
Si vous trouvez 7.6.0 ; 7.4.0–7.4.5 ; 7.2.0–7.2.10 ; 7.0.0–7.0.15 ou toute 6.4, planifiez au plus vite leur mise à jour vers 7.6.1 / 7.4.6 / 7.2.11 / 7.0.16 ou une version supérieure. Pour 6.4, envisagez une migration de branche.

2) Renforcement temporaire (si la mise à jour immédiate n’est pas possible)

Restreignez l’accès administratif aux adresses IP fiables (listes d’accès admin).
Activez MFA sur toutes les comptes avec privilèges.
Désactivez temporairement l’accès CLI/SSH depuis les interfaces non essentielles.
Revoyez les profils d’administrateur et appliquez le principe du moindre privilège.
Auditez les logs d’administration et créez des alertes pour détecter des commandes ou accès anormaux.

3) Stratégie de mise à jour en configuration HA/VDOM

Sauvegardez la configuration (au format texte et chiffrée) et faites un snapshot si possible.
Dans un cluster HA, mettez à jour en premier le membre secondaire, faites une migration contrôlée (failover) et mettez à jour le membre principal.
Si vous utilisez des VDOM, vérifiez la compatibilité de la version firmware et les particularités de chaque VDOM.
Après l’upgrade, vérifiez que politiques, VPN, SD-WAN et routage fonctionnent correctement et que le cluster est re-synchronisé.

4) Vérification après la mise à jour

Confirmez la version finale par GUI/CLI et effectuez tests fonctionnels.
Revoyez les logs d’administration des derniers jours pour repérer d’éventuels signaux anormaux.
Documentez la mise à jour et actualisez le CMDB/inventaire.

Bonnes pratiques durables pour réduire le risque de futures failles

Réseau de gestion dédié : gérez FortiGate uniquement depuis un réseau de gestion LAN ou console hors bande.
Comptes nominaux et gestion sécurisée : pas de comptes partagés, identifiants dans un gestor sécurisé, renouvellement périodique et MFA obligatoire.
Surface CLI minimale : si la gestion quotidienne s’effectue via GUI/API, limitez SSH à la LAN de gestion et bloquez son accès depuis le WAN.
Principe du moindre privilège : profils d’administration granulaires ; révisions trimestrielles des permissions.
Backups testés : ne pas seulement sauvegarder la configuration, mais aussi tester les restaurations.
Calendrier de patching : définissez des fenêtres récurrentes et un SLA pour les mises à jour critiques.

Vision pour la direction et la conformité

Risque : exécution de commandes système par un utilisateur authentifié; impact potentiel sur la confidentialité, intégrité et disponibilité du dispositif et du trafic inspecté.
Action : mettre à jour vers les versions corrigées (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16) ou migrer depuis 6.4 ; renforcer l’accès administratif.
Portée : familles et modèles listés ; les autres ne sont pas affectés selon cet avis.
Traçabilité : conservez évidences de la mise à jour (tickets, captures, logs) et mettez à jour vos politiques internes de gestion des vulnérabilités.

Que signifie “acteur malveillant authentifié localement” (et quoi n’est pas)

Dans la terminologie de ces alertes, “local” ne suppose pas nécessairement une présence physique. Cela désigne une personne qui se connecte à l’interface d’administration (console/SSH) avec des identifiants valides. Il peut s’agir d’un opérateur interne, d’un fournisseur temporaire ou d’un compte de service. C’est pourquoi limiter l’administration à un réseau de gestion, exiger le MFA et réaliser des audits d’accès ne sont pas optionnels : ce sont des mesures de sécurité complémentaires pour limiter la portée d’un incident.

L’essentiel, en une phrase

Si votre FortiGate utilise FortiOS 7.6.0 ; 7.4.0–7.4.5 ; 7.2.0–7.2.10 ; 7.0.0–7.0.15 ou une version 6.4, mettez à jour vers la version corrigée (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16) ou migratez dès que possible ; en attendant, restreignez l’administration aux IPs de confiance, activez MFA et surveillez les logs CLI.

Questions Fréquemment Posées

Comment vérifier rapidement la version de FortiOS via CLI et décider si une mise à jour est nécessaire ?
Connectez-vous en CLI et exécutez get system status. Si la version est 7.6.0, 7.4.0–7.4.5, 7.2.0–7.2.10, 7.0.0–7.0.15 ou toute 6.4, il faut mettre à jour vers une version supérieure (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16), ou migrer depuis 6.4.

Quels modèles FortiGate sont impactés par cette vulnérabilité dans FortiOS ?
Parmi eux : 100E/101E, 100F/101F, 1100E/1101E, 1800F/1801F, 2200E/2201E, 2600F/2601F, 3300E/3301E, 3400E/3401E, 3500F/3501F, 3600E/3601E, 3800D, 3960E, 3980E, 4200F/4201F, 4400F/4401F, 5001E, 6000F, 7000E et 7000F. Les autres modèles ne sont pas listés comme touchés dans ce bulletin.

Que faire si je ne peux pas appliquer la mise à jour aujourd’hui en raison d’une fenêtre de production critique ?
Mettez en place des mesures temporaires : limitez l’administration aux adresses IP spécifiques, exigez le MFA pour tous les comptes à privilèges, désactivez SSH/CLI sur les interfaces non essentielles et surveillez les commandes et accès inhabituels. Planifiez l’upgrade dès la première fenêtre adéquate.

Cette vulnérabilité permet-elle une attaque distante sans authentification depuis Internet ?
Non. La vecteur exige une authentification (session CLI) sur le dispositif. Cependant, si un compte administratif est compromis, l’impact peut être sérieux. D’où l’importance critique de patcher rapidement et de renforcer les identités et accès.