Des rançongiciels exploitent le RCE IKEv2 non authentifié des pare-feu WatchGuard Firebox

Décembre 2025. WatchGuard corrige CVE-2025-14733, un RCE non authentifié dans le processus iked de Fireware OS. 9 septembre 2026. Shadowserver dénombre encore près de 9 000 pare-feu Firebox exposés sur Internet, neuf mois après le correctif. 10 septembre 2026. CISA actualise sa fiche du catalogue KEV : la faille est désormais exploitée par des rançongiciels. Le message n’est pas « corrigez cette CVE », elle est corrigée depuis longtemps. Le message est « votre passerelle VPN de périmètre est peut-être encore ouverte, et le prix de l’oubli vient de passer de l’espionnage au chiffrement ».

Un RCE de périmètre corrigé depuis neuf mois

La faille est une écriture hors limites (CWE-787) dans le processus iked, le démon qui négocie les échanges de clés IKEv2 des VPN. Un attaquant distant, sans aucune authentification, peut envoyer une requête IKE_AUTH au format malveillant et exécuter du code arbitraire sur le pare-feu. CISA qualifie l’attaque de faible complexité et WatchGuard lui a attribué un CVSS 9,5, le score critique.

Ce qui rend la faille vicieuse, c’est sa surface. Elle touche deux configurations distinctes : le Mobile VPN en IKEv2 et le VPN inter-sites en IKEv2 vers une passerelle dynamique. Et même si vous avez supprimé ces configurations par le passé, un VPN inter-sites vers une passerelle statique encore actif peut laisser l’appareil vulnérable. En d’autres termes, l’historique de configuration d’un boîtier peut le maintenir exposé alors que rien de visible ne l’indique.

Les versions affectées couvrent l’essentiel du parc Fireware OS : les branches 11.x (jusqu’à 11.12.4 Update1 inclus), 12.x (jusqu’à 12.11.5 inclus) et 2025.1 (jusqu’à 2025.1.3). Le correctif atterrit dans Fireware OS 2025.1.4, 12.11.6, 12.5.15 et 12.3.1-b728352 selon le modèle.

Ce que les attaquants font une fois à l’intérieur

WatchGuard documente deux variantes d’activité post-exploitation observées dans la nature. Dans la première, l’attaquant chiffre puis exfiltre le fichier de configuration actif du Firebox vers l’adresse IP d’où provient l’attaque. Dans la seconde, il crée une archive gzip contenant à la fois la configuration active et la base locale des comptes d’administration, puis l’exfiltre vers la même adresse.

Cette seconde variante est la plus inquiétante pour la suite. La configuration d’un Firebox concentre les secrets de connexion VPN (clés pré-partagées, certificats, mots de passe) et la base admin locale donne les comptes d’administration de l’appareil. Une fois ces deux éléments sortis, l’attaquant ne se contente pas de traverser le périmètre : il détient de quoi rejouer les tunnels et s’administrer le boîtier à distance, même après le correctif. C’est précisément pourquoi WatchGuard demande de renouveler tous les secrets stockés localement sur tout appareil soupçonné d’avoir été compromis.

La bascule vers le rançongiciel change la nature du risque. En décembre, l’exploitation documentée relevait surtout de l’espionnage — on vole la configuration, on écoute, on repart. Désormais, CISA confirme que des groupes utilisent la faille pour chiffrer des données. Pour une PME dont le Firebox est la porte d’entrée unique du réseau, le scénario n’est plus « on nous observe », c’est « on nous arrête ».

Neuf mois plus tard, près de 9 000 pare-feu encore exposés

Le chiffre le plus accablant vient de Shadowserver. En décembre 2025, l’organisation recensait plus de 115 000 Firebox vulnérables exposés en ligne. Neuf mois plus tard, près de 9 000 instances restent non corrigées. C’est une diminution de plus de 90 %, et pourtant c’est encore un champ de cibles entières pour un rançongiciel qui n’a besoin que d’atteindre un service IKEv2 ouvert.

Pourquoi ces boîtiers ne sont-ils pas corrigés ? Parce qu’un pare-feu ne se patche pas comme un poste de travail. Un redémarrage de Firebox interrompt tous les tunnels VPN de l’entreprise : les sites distants, le télétravail, parfois la téléphonie. La fenêtre de maintenance doit être planifiée, validée, souvent exécutée de nuit. Dans une PME sans équipe dédiée, la mise à jour d’un pare-feu « qui fonctionne » recule indéfiniment — jusqu’à ce qu’un attaquant décide du calendrier à sa place.

Le parallèle est d’ailleurs systématique chez WatchGuard. En septembre 2025, l’éditeur corrigeait CVE-2025-9242, un RCE « presque identique » à celui-ci, pour lequel Shadowserver a ensuite recensé plus de 75 000 boîtiers exposés. Deux ans plus tôt, CVE-2022-23176 était exploitée par des hackers d’État russes. Le même éditeur, la même famille d’appareils, la même leçon qui ne s’apprend pas.

Comment savoir si votre Firebox est déjà compromis

WatchGuard publie des indicateurs d’attaque précis, applicables uniquement aux appareils non corrigés. Deux signatures de journaux ressortent.

D’abord, une chaîne de certificats anormalement longue dans la requête d’authentification, visible au niveau de journalisation par défaut :

iked[2938]: (203.0.113.1<->203.0.113.2) Received peer certificate chain is longer than 8. Reject this certificate chain

Ensuite, une charge utile CERT anormalement volumineuse dans la requête IKE_AUTH, visible au niveau de journalisation « info » :

iked (203.0.113.1<->203.0.113.2) "IKE_AUTH request" message has 6 payloads [ IDi(sz=21) CERT(sz=3000) SA(sz=44) TSi(sz=24) TSr(sz=24) N(sz=8) ]

Un payload CERT supérieur à 2 000 octets est un indicateur fort. À cela s’ajoutent deux signaux comportementaux : un processus iked qui se fige (interrompant les négociations et renégociations de clés) et un crash de iked avec rapport de défaut. Enfin, WatchGuard publie une liste d’adresses IP d’attaque connues — toute connexion sortante du boîtier vers l’une d’elles est un signal de compromission, à contrôler indépendamment des connexions entrantes.

Verdict

CVE-2025-14733 n’est pas une alerte de patch classique : le correctif existe depuis décembre 2025, et ce qui a changé le 10 septembre 2026, c’est l’escalade de l’exploitation vers le rançongiciel. La faille elle-même est un rappel brutal que la périphérie VPN reste la surface la plus exposée d’une PME, et que le vrai risque n’est pas la vulnérabilité mais le défaut de maintenance qui la laisse ouverte neuf mois.

Si vous exploitez un Firebox, vérifiez immédiatement la version de Fireware OS : tout appareil en 11.x, 12.x avant 12.11.6 ou 2025.1 avant 2025.1.4 doit être mis à jour, même si vous pensez avoir supprimé les configurations VPN vulnérables. Ensuite, traquez les indicateurs : payloads CERT volumineux, chaînes de certificats longues, connexions sortantes vers les IP publiées. Si un signal remonte, renouvelez tous les secrets stockés localement — pas seulement le mot de passe admin.

Si vous ne pouvez pas corriger tout de suite et que vous n’utilisez que des VPN inter-sites à passerelle statique, appliquez le contournement documenté par WatchGuard en attendant la fenêtre de maintenance. Mais ne le considérez pas comme une solution : restreindre l’exposition ne remplace jamais la mise à jour, et un pare-feu exposé est une cible qui attend son tour.

Références

• BleepingComputer — CISA: WatchGuard RCE flaw now exploited in ransomware attacks, 10 septembre 2026
• WatchGuard PSIRT — CVE-2025-14733 : Firebox iked Out of Bounds Write Vulnerability
• CISA — Known Exploited Vulnerabilities Catalog, fiche CVE-2025-14733
• NVD — CVE-2025-14733
• Shadowserver — WatchGuard Firebox vulnerable instances, série temporelle