CVE-2025-25249 a été publiée le 13 janvier 2026. Elle a été ajoutée au catalogue CISA KEV le 9 septembre 2026 — huit mois plus tard — avec une échéance de remédiation à trois jours.
C'est un débordement de tas dans FortiOS, FortiSwitchManager et FortiSASE, permettant d'exécuter du code ou des commandes via des paquets forgés. Notée 8.1, elle n'était pas en tête des files de priorité en janvier. Elle l'est aujourd'hui, parce qu'elle est exploitée.
Ce décalage est le vrai sujet de cet article.
La vulnérabilité
| Champ | Valeur |
|---|---|
| CVE | CVE-2025-25249 |
| CVSS 3.1 | 8.1 (HIGH) |
| Vecteur | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Type | Débordement de tas (CWE-122) |
| Authentification | Aucune |
| Publication NVD | 2026-01-13 |
| Ajout CISA KEV | 2026-09-09 |
| Échéance CISA | 2026-09-12 |
Description :
A heap-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiOS 6.4 all versions, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows attacker to execute unauthorized code or commands via specially crafted packets.
Ce que « AC:H » veut dire — et ne veut pas dire
Le score est tiré vers le bas par un seul élément : AC:H, complexité d'attaque élevée. Tout le reste du vecteur est au maximum : réseau, aucun privilège, aucune interaction, impact complet.
« Complexité élevée » en CVSS ne signifie pas « difficile au point d'être improbable ». Cela signifie que l'exploitation dépend de conditions que l'attaquant ne contrôle pas entièrement — un état mémoire particulier, une configuration, une course. Pour un attaquant opportuniste qui scanne Internet, c'est un frein réel. Pour un groupe qui cible une organisation précise et dispose de temps, c'est un obstacle d'ingénierie, pas une barrière.
L'ajout au KEV dit précisément cela : quelqu'un a fait le travail.
Versions affectées et corrigées
| Produit | Branche | Versions affectées | Première version hors plage |
|---|---|---|---|
| FortiOS | 7.6 | 7.6.0 → 7.6.3 | 7.6.4 |
| FortiOS | 7.4 | 7.4.0 → 7.4.8 | 7.4.9 |
| FortiOS | 7.2 | 7.2.0 → 7.2.11 | 7.2.12 |
| FortiOS | 7.0 | 7.0.0 → 7.0.17 | 7.0.18 |
| FortiOS | 6.4 | toutes | voir ci-dessous |
| FortiSwitchManager | 7.2 | 7.2.0 → 7.2.6 | 7.2.7 |
| FortiSwitchManager | 7.0 | 7.0.0 → 7.0.5 | 7.0.6 |
| FortiSASE | — | géré par Fortinet | 25.1.39 / 25.1.51 selon NVD |
⚠️ Ces numéros sont les bornes issues de NVD. Vérifie dans l'advisory Fortinet PSIRT la version recommandée pour ta branche — Fortinet conseille souvent une version plus récente que la première corrigée.
Le cas FortiOS 6.4 mérite une mention : la description dit « all versions ». La branche 6.4 est en fin de support. Si tu y es encore, la réponse n'est pas un correctif mais une migration vers une branche maintenue.
FortiSASE est un service opéré par Fortinet : la correction est de leur ressort, mais vérifie l'état de ton tenant auprès du support.
Vérifier ta version :
get system status
Pourquoi huit mois de délai ne veulent pas dire huit mois de sécurité
Le schéma est récurrent chez les équipements réseau, et il piège les organisations qui priorisent par score :
- Janvier : la CVE sort à 8.1, sans exploitation connue. Elle rejoint le backlog derrière les 9.8.
- Les mois passent : les parcs FortiGate ne sont pas mis à jour au rythme des publications, parce qu'une mise à jour de pare-feu coupe le trafic.
- Septembre : l'exploitation est constatée. Tous les équipements qui n'ont pas bougé depuis janvier sont exposés — et ils sont nombreux.
Le délai entre publication et exploitation n'a pas protégé ceux qui ont attendu : il a simplement donné à l'attaquant le temps de trouver les conditions qui font baisser le score.
C'est le troisième ajout Fortinet au KEV que nous couvrons cet été, après FortiSandbox et FortiOS en juillet. Pour un parc Fortinet, la cadence de mise à jour doit être pensée comme continue, pas comme un chantier ponctuel.
Détection
- Redémarrages inattendus ou plantages de processus : un débordement de tas raté fait souvent tomber le service ciblé avant qu'une tentative réussisse
- Comptes administrateurs inconnus :
show system admin - Modifications de configuration non documentées : politiques, VPN, routes, serveurs DNS
- Fichiers ou scripts inhabituels — sur FortiOS, la persistance post-exploitation passe historiquement par le système de fichiers ; le bypass du mécanisme anti-persistance documenté en juillet montre que ce point n'est pas théorique
- Trafic sortant initié par l'équipement lui-même vers des destinations non liées à ses services
diagnose debug crashlog read
execute log filter category event
execute log display
Mitigation
1. Mettre à jour vers une version corrigée de ta branche
L'échéance CISA était le 12 septembre. Si ce n'est pas fait, c'est prioritaire.
2. Réduire l'exposition des interfaces
- Interface d'administration jamais exposée sur Internet : restriction par
trusted hosts - Désactiver les services non utilisés sur les interfaces externes
3. Sortir de FortiOS 6.4
Aucune mesure temporaire ne remplace une branche maintenue.
4. Si tu suspectes une compromission
- Vérifier l'intégrité du firmware avec les outils Fortinet
- Considérer qu'une simple mise à jour ne suffit pas à éliminer une persistance déjà installée
- Faire tourner les identifiants : comptes administrateurs, clés VPN, certificats, secrets partagés LDAP/RADIUS
- Comparer la configuration à une sauvegarde antérieure à la période suspecte
Pourquoi surveiller en continu votre parc Fortinet
Une CVE à 8.1 sans exploitation connue ne déclenche aucune alerte chez la plupart des équipes. Huit mois plus tard, son entrée au KEV devrait en déclencher une immédiatement — mais seulement si quelqu'un sait quelles versions tournent sur chaque équipement à ce moment-là.
Avec cveo.tech, inventorie tes équipements Fortinet avec leur version exacte, et reçois une alerte automatique dès qu'une CVE qui les concerne entre au catalogue CISA KEV — y compris celles que tu avais légitimement laissées dans le backlog.