EN
en direct

Le RAT PivotC2 exploite CVE-2025-25249, un débordement de tas Fortinet corrigé depuis janvier

Corrigé en janvier 2026, le débordement de tas CVE-2025-25249 dans le démon cw_acd de FortiOS est désormais exploité dans la nature : la CISA l’a inscrit au KEV le 9 septembre 2026, alors que SOCRadar observe le RAT PivotC2 déployé sur 178 appareils. Les équipes réseau doivent monter en version les trains FortiOS exposés avant le 12 septembre, puis retirer l’accès fabric devenu inutile.

Un pare-feu réseau monté en baie, son panneau avant couvert de ports sombres, un seul port fibre optique clignotant en ambre pendant que tous les autres restent éteints.

Janvier 2026. Fortinet publie CVE-2025-25249, un débordement de tas dans le démon cw_acd de FortiOS, et livre les correctifs dans la foulée. 9 septembre 2026. La CISA inscrit la faille à son catalogue KEV : l’exploitation est désormais confirmée en conditions réelles. 12 septembre 2026. C’est la date butoir imposée aux agences fédérales américaines. Entre les deux, la société de renseignement SOCRadar a observé une campagne ciblant plus de 30 000 adresses IP, aboutissant à l’infection de 178 appareils par PivotC2, un RAT taillé pour les boîtiers FortiGate. Le vrai sujet n’est pas la faille, c’est ce qu’elle dit d’un parc qui ne patche pas un bug CVSS 9.8 sur du matériel exposé en CAPWAP.

Un débordement de tas dans un démon qu’on ne surveille pas

CVE-2025-25249 est un débordement de tampon sur le tas (CWE-122 / CWE-787) situé dans le démon cw_acd, le service CAPWAP (Wireless Aggregate Controller) de FortiOS et de FortiSwitchManager. C’est lui qui gère le trafic de contrôle CAPWAP, en écoute sur le port UDP 5246, utilisé par le Security Fabric de Fortinet et par les fonctions de contrôleur sans fil.

Le problème de ce composant, c’est sa position : il est souvent joignable depuis l’extérieur, sur des FortiGate exposés, alors qu’il n’a pas la visibilité d’un service web ou d’un VPN. Un attaquant non authentifié et distant envoie des paquets spécialement forgés pour déclencher le débordement et exécuter du code arbitraire — sans identifiant, sans interaction utilisateur.

La sévérité fait débat sur le papier : le NVD note la faille CVSS 9.8 critique, Fortinet la note 7.4 élevé. L’écart tient à une nuance que Fortinet souligne dans son avis FG-IR-25-084 : l’activation de mécanismes comme ASLR et PIE augmente significativement l’effort nécessaire à l’exploitation. La leçon opérationnelle reste la même — un bug exploitable sans authentification sur un périmètre doit être traité au plafond, pas à la moyenne des deux scores.

PivotC2, un RAT écrit pour les FortiGate

L’exploitation observée ne se contente pas d’un shell. Les attaquants déploient PivotC2, un RAT en Node.js conçu spécifiquement pour les boîtiers FortiGate. SOCRadar relève un détail troublant : les commentaires détaillés et la structure du code suggèrent que ses développeurs ont utilisé une assistance de génération de code par IA.

La chaîne d’exploitation est directe. L’attaquant repère un FortiGate exposé avec le port UDP 5246 ouvert, envoie les paquets forgés, obtient un reverse shell, puis exécute un stager JavaScript d’une ligne via Node.js. Le stager télécharge la charge de deuxième étage, la décode en Base64, la déchiffre en XOR et l’écrit dans un fichier temporaire. PivotC2 tourne ensuite en processus détaché, survivant à la fermeture de la connexion initiale.

Les capacités du RAT en font un outil de post-exploitation complet :

  • Shell interactif via /bin/sh, bash, ash, dash ou busybox ;
  • Transfert de fichiers montant et descendant, avec streaming ;
  • Tunneling SOCKS5 et HTTP, et redirection de ports locale et distante ;
  • Scan réseau par plages CIDR et par ports ;
  • Récolte de configuration FortiGate et déchiffrement d’identifiants (AES-256-CBC, AES-128-GCM) : clés pré-partagées VPN, identifiants SSL-VPN, mots de passe Wi-Fi, comptes administrateurs ;
  • Mode automatique pour compromettre à l’échelle sans intervention.

Dans les intrusions confirmées, les attaquants ont exfiltré des boîtes aux lettres Microsoft Exchange vers du stockage cloud, après avoir utilisé le FortiGate compromis comme point de pivot vers le réseau interne. Un pare-feu, dans ce scénario, n’est pas la cible finale — c’est la porte d’entrée.

Un bug de janvier qui traîne jusqu’en septembre

Le calendrier est la partie la plus instructive. Fortinet a découvert la faille en interne — son équipe Product Security — et publié les correctifs en janvier 2026 : FortiOS 7.6.4, 7.4.9, 7.2.12, 7.0.18 et 6.4.17, ainsi que FortiSwitchManager 7.2.7 et 7.0.6. Huit mois plus tard, la CISA l’ajoute au KEV — ce qui exige, par définition, des preuves d’exploitation.

Ce décalage est le signal faible devenu signal fort. Un bug critique corrigé en janvier qui refait surface exploité en septembre signifie que des parcs entiers n’ont jamais appliqué le correctif, ou que des appareils oubliés — de test, de secours, de filiale — restent en ligne avec des versions vulnérables. C’est exactement le type d’actif qu’une campagne automatisée à 30 000 adresses IP finit par trouver.

Ce que doivent faire les équipes réseau

L’ordre des opérations est simple, et il commence par l’inventaire :

  • Inventoriez les versions exactes de chaque FortiGate/FortiOS, FortiSwitchManager et FortiSASE — y compris les boîtiers de test et les paires HA de secours ;
  • Montez en version au plancher corrigé ou au-delà : 7.6.4+, 7.4.9+, 7.2.12+, 7.0.18+, 6.4.17+ ; FortiSwitchManager 7.2.7+ et 7.0.6+ ;
  • Retirez l’accès fabric des interfaces qui n’en ont pas besoin, en supprimant le mot-clé fabric de la directive allowaccess ;
  • Restreignez le CAPWAP (UDP 5246-5249) aux seuls équipements de confiance via une local-in policy, là où le Security Fabric doit rester actif ;
  • Chassez les indicateurs PivotC2 : processus Node.js inattendus, connexions sortantes vers des serveurs inhabituels, modifications de configuration non tracées.

Un extrait de configuration minimal, pour retirer l’accès fabric d’une interface :

bash
config system interface
    edit "port1"
        set allowaccess ssh https
    next
end

Avant, allowaccess contenait fabric ssh https : la suppression de fabric coupe l’accès au chemin CAPWAP vulnérable sans toucher aux services d’administration nécessaires. Siemens a repris la même consigne dans son bulletin SSA-864900 pour ses systèmes qui embarquent du Fortinet.

Chasser PivotC2 avant de conclure

Le correctif empêche l’exploitation future, il ne nettoie pas un appareil déjà atteint. Fortinet et SOCRadar convergent sur une consigne simple : un boîtier qui a été joignable sur le chemin vulnérable doit être traité comme suspect jusqu’à preuve du contraire.

La chasse se concentre sur trois signaux :

  • Processus Node.js inattendus : PivotC2 s’exécute en Node.js, cherchez les processus node ou nodejs qui n’appartiennent pas à une application connue ;
  • Connexions sortantes inhabituelles : le RAT maintient un canal de commande vers un serveur contrôlé par l’attaquant, souvent sur des ports non standards ;
  • Fichiers temporaires et stagers : le stager écrit une charge Base64 puis XOR dans un fichier temporaire avant de lancer le RAT en processus détaché.

Un point que SOCRadar souligne : le RAT récolte et déchiffre les configurations FortiGate, y compris les clés VPN et les comptes administrateurs. Un appareil compromis ne se répare pas en le patchant — il faut révoquer les secrets qu’il portait et, dans le pire des cas, le reconstruire depuis un support propre.

Verdict

CVE-2025-25249 n’est pas une nouveauté : c’est un débordement de tas CVSS 9.8 corrigé depuis janvier 2026, qui resurgit en septembre sous la forme d’une campagne automatisée déployant PivotC2, un RAT sur mesure pour les FortiGate. La leçon tient dans le décalage : une faille critique sur un chemin réseau obscur — le CAPWAP — reste invisible tant qu’on ne la traite pas comme une surface exposée.

Si vous opérez des FortiGate ou des FortiSwitchManager, montez en version dès maintenant, puis retirez l’accès fabric inutile et restreignez le CAPWAP aux pairs de confiance. Le correctif existe depuis huit mois : l’exploitation observée sur 178 appareils n’est pas un avertissement théorique.

Si vous ne pouvez pas patcher immédiatement, coupez au minimum l’accès fabric et le port UDP 5246 vers l’extérieur — mais traitez cela comme une parade temporaire, pas une clôture. La seule clôture est la montée en version, doublée d’une chasse aux indicateurs de compromission.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Cisco confirme l’exploitation active de CVE-2026-20079, un contournement d’authentification CVSS 10.0 sur Secure FMC

Le 9 septembre 2026, Cisco confirme que CVE-2026-20079, un contournement d’authentification noté CVSS 10.0 dans Secure Firewall Management Center, est exploité activement, alors que le correctif existait depuis mars. Les équipes réseau doivent patcher sans attendre, puis chercher les indicateurs de compromission avant de conclure que l’appareil est sain.

ShieldCrash contourne le correctif ShieldBreak de Microsoft Defender pour lire des fichiers en SYSTEM

Le 9 septembre 2026, le chercheur Chaotic Eclipse publie ShieldCrash, un proof of concept qui contourne CVE-2026-69414 (ShieldBreak), la faille d’élévation de privilèges que Microsoft prétendait avoir corrigée dans le moteur antimalware de Defender. Vérifiez la version du Malware Protection Engine et traitez l’EDR lui-même comme une surface d’attaque à surveiller.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer