Ah, F5… ce bon vieux champion du load balancing, gardien des flux SSL et héros autoproclamé de la “Digital Resilience”.
Sauf que cette fois, le résilient, c’est surtout l’attaquant. Car oui, F5 s’est fait hacker. Bien comme il faut.
Et pas un petit “oops, on a oublié de patcher un CVE”. Non.
On parle d’un accès prolongé dans les entrailles du code source, de fuites de vulnérabilités non publiées, et d’une alerte CISA en mode panique nationale.
Tu veux du drame cyber ? Attache ta ceinture SSL, on y va.
Incident : compromission de F5 (détectée en août 2025, révélée mi-octobre) avec vol de code source BIG-IP et d’informations sur des vulnérabilités non divulguées.
Gravité : CISA publie l’Emergency Directive ED 26-01 (15 oct. 2025) pour les agences fédérales : inventaire, correctifs immédiats, remplacements si EoS.
Surface exposée : ~266 000 instances BIG-IP détectées sur Internet après l’annonce.
🔍 Le pitch : “BIG-IP, small security”
L’affaire démarre comme beaucoup d’histoires modernes : par un communiqué de presse laconique.
F5 reconnaît une “activité non autorisée” dans ses systèmes internes. Traduction : un acteur APT (probablement sponsorisé par un État) s’est invité dans le laboratoire de développement de BIG-IP.
Et il n’est pas venu pour le café.
Résultat :
- Vol de code source complet ou partiel,
- Exfiltration d’infos sur des vulnérabilités non encore corrigées,
- Et, cerise sur le WAF, un risque d’exploitation en chaîne d’approvisionnement.
Bref, le scénario parfait pour un supply-chain drama à la SolarWinds.
🕵️♂️ Les coupables ? Mystère et bulle de TLS
F5 parle pudiquement d’un “acteur étatique sophistiqué”.
Traduction : on ne veut pas dire “la Chine” ou “la Russie” sans preuves, mais tout le monde a une idée.
Certains chercheurs pointent UNC5291, un groupe déjà vu dans les compromissions Ivanti, mais rien d’officiel.
Et dans le doute, tout le monde surveille ses reverse proxies comme un faucon sur un mulot.
💣 Les risques : du load balancing au load leaking
Imagine : tu gères des flux critiques — portails bancaires, applications internes, portails RH, e-commerce, API publiques…
Et ton BIG-IP, celui censé protéger tout ça, devient un cheval de Troie d’entreprise.
Grâce au code source volé, l’attaquant connaît :
- les failles logiques du système,
- les modules vulnérables (TMM, SSL, APM…),
- et les mécanismes d’auth interne.
En clair : le plan du coffre-fort.
Et la clé USB du coffre-fort.
Et la combinaison du coffre-fort.
Les analystes estiment que 266 000 instances BIG-IP sont exposées sur Internet.
Autrement dit, 266 000 chances de transformer un reverse proxy en reverse catastrophe.
⚠️ CVE Party : le patch ou la mort
Depuis le début de l’année, F5 aligne les bulletins comme un DJ balance des drops.
Quelques hits récents :
- CVE-2025-61955 / 57780 : contournement du mode “Appliance”. Tu pensais être verrouillé ? Spoiler : non.
- CVE-2025-53868 : faille critique SCP/SFTP, note CVSS 8.7.
- CVE-2025-60016 : vulnérabilité SSL/TLS, encore une fois dans le moteur TMM.
- CVE-2024-41727, 45844, 27202… bref, une symphonie de failles.
Le Patch Tuesday de F5 ressemble à un calendrier de l’Avent pour pentesters : chaque case cache un nouveau cadeau.
🧠 CISA : “Fermez tout, patch tout, respirez après”
La CISA (Cybersecurity and Infrastructure Security Agency) n’a pas fait dans la dentelle.
Le 15 octobre 2025, elle publie une Emergency Directive (ED 26-01) ordonnant à toutes les agences fédérales de :
- Inventorier tous les systèmes F5,
- Appliquer immédiatement les correctifs,
- Remplacer les modèles obsolètes,
- Et surtout, isoler les interfaces d’administration.
Autrement dit : “Vous avez acheté un F5 ? Très bien. Maintenant, débranchez-le, réparez-le, et recâblez-le proprement.”
🏭 Les victimes collatérales : Fortune 500 et compagnie
F5, c’est le ciment invisible de la plupart des infrastructures critiques.
Selon plusieurs études, plus de 85 % des entreprises du Fortune 500 utilisent F5 d’une façon ou d’une autre.
Quelques noms publics :
- Cardinal Health (santé)
- McGraw Hill (éducation)
- Austrian Lotteries (jeu en ligne)
- SA Water (utilities)
- Robi Axiata (télécom)
- Et d’innombrables administrations, banques et retailers anonymes.
En gros : si tu as déjà acheté quelque chose, payé une facture ou validé un ticket, tu es probablement passé par un F5.
🔐 Recommandations réalistes (et un peu désabusées)
Avant de paniquer, voici ce qu’un RSSI lucide ferait :
- Dépublier toutes les interfaces TMUI et SSH exposées.
- Appliquer les patchs d’octobre 2025 sans attendre.
- Remplacer les modèles en fin de support (oui, même s’ils “marchent encore très bien”).
- Hunt les IoC (indicateurs de compromission) : logs TMM, connexions APM suspectes, certificats modifiés.
- Activer le mode Appliance… mais après avoir vérifié qu’il ne soit plus contournable (sic).
Et si ton équipe te dit “on verra plus tard”, imprime cet article, mets-le sur leur clavier et écris :
“Le pare-feu, c’est comme la ceinture de sécurité : inutile jusqu’à la première collision.”
🤯 Leçon du jour : même les gardiens ont besoin de garde
F5 vient de rejoindre le club très fermé des “éditeurs de sécurité hackés par des gens plus forts qu’eux”.
Un club déjà fréquenté par SolarWinds, Ivanti, Kaseya, et consorts.
Moralité ?
Aucun éditeur n’est invulnérable, pas même ceux qui vendent la protection ultime.
Et si ton architecture repose sur un seul équipement “magique”, prépare-toi à un réveil brutal.
💬 Conclusion : F5, ou le paradoxe du firewall schizophrène
Dans cette affaire, F5 a prouvé deux choses :
- Les pare-feux modernes sont aussi vulnérables que les applis qu’ils protègent,
- Et les pirates, eux, ont bien lu les documentations produit.
Alors la prochaine fois que tu vois une appliance “Next-Gen” flambant neuve, souviens-toi :
“Next-Gen”, ça veut souvent dire : prochaine à tomber.
🧠 Pour aller plus loin
1. Aperçu global de l’architecture et des modules BIG-IP
- Le produit BIG-IP est la plateforme logicielle (et matérielle/virtuelle) de F5 : « BIG-IP est le nom marketing global pour la suite logicielle modulaire de F5 ». WorldTech IT
- Cette plateforme repose sur un OS propriétaire/micro-noyau appelé TMOS (Traffic Management Operating System) qui gère le traitement applicatif / réseau (“full proxy”).
- On y “active” différents modules selon besoins :
- LTM (Local Traffic Manager) — gestion du trafic applicatif et load balancing.
- ASM (Application Security Manager) — WAF / sécurité applicative.
- APM (Access Policy Manager) — contrôle d’accès, authentification.
- AFM (Advanced Firewall Manager) — firewall réseau/attaque DDoS (dans certains contextes).
- DNS (BIG-IP DNS, ex GTM) — fonctions DNS, répartition géographique.
- Ces modules sont installés sur le même “héritage” logiciel/hardware (BIG-IP / TMOS) mais peuvent être activés ou non, et peuvent être sur matériel ou version virtuelle (BIG-IP VE) ou cloud. F5 Cloud Docs
2. Cartographie des dépendances / interdépendances
Voici un schéma (logique) des principaux liens/dépendances entre les composants et modules, avec les points de vigilance en terme de vulnérabilité.
Schéma simplifié
[Infrastructure physique/virtuelle]
↓
TMOS (Kernel + microkernel TMM)
↓
BIG-IP base (hardware or virtual)
↓
┌────────────── Modules activés ───────────────┐
| LTM ←→ DNS |
| ↓ ↓ |
| ASM ←→ APM |
| ↘ |
| AFM |
└──────────────────────────────────────────────┘
Dépendances détaillées
- Le système TMOS / BIG-IP est fondamental : tous les modules partagent le même noyau, la même plateforme logicielle. Une vulnérabilité dans le cœur (TMOS) affecte donc potentiellement tous les modules.
- Le module LTM est souvent “le socle” : dans beaucoup de déploiements, LTM est requis car il gère le trafic applicatif. D’autres modules (ASM, APM) ajoutent des fonctions “au-dessus”. WorldTech IT
- ASM (WAF) dépend du traitement appliqué par LTM : le trafic doit être acheminé via LTM pour que ASM puisse inspecter/apply les politiques.
- APM dépend à la fois du système de base (BIG-IP) et du LTM ou de la capacité de gestion d’accès — il utilise les ressources de BIG-IP pour authentifier, autoriser, etc.
- DNS module dépend de la plateforme BIG-IP et peut interagir avec LTM pour la répartition globale.
- AFM (firewall/DoS) dépend de la capacité de TMOS/BIG-IP à gérer les règles réseau, tables d’attaque, etc.
- Virtualisation / Cloud & version matérielle : Le BIG-IP VE (édition virtuelle) dépend de l’hyperviseur, et certaines fonctions matérielles peuvent être limitées. F5 Cloud Docs
Impacts de vulnérabilité
- Une faille dans TMOS ou dans un module “socle” (LTM) peut permettre un impact transversal sur tous modules activés.
- Un module “optionnel” activé (ex: APM) peut introduire une chaîne d’attaque si mal configuré ou pas patché, et via la base commune (BIG-IP) se propager aux autres modules.
- Les interconnexions (ex: LTM + ASM + APM) créent des parcours plus complexes : par exemple, un accès compromis via APM (contrôle d’accès) pourrait ouvrir une voie vers la gestion de l’appareil ou du trafic LTM/ASM.
- Dans un contexte “alerte rouge” comme évoqué par l’ANSSI, il est important de cartographier tous les modules utilisés, leur version logicielle, et leurs dépendances vis-à-vis du matériel/platforme.
3. État des lieux technique – ce qu’il faut vérifier dans votre contexte
Voici une liste de vérifications recommandées :
- Versions logicielles : Vérifier la version de TMOS, BIG-IP, et de chaque module (LTM, ASM, APM, AFM, DNS) installée. F5 présente des matrices de compatibilité. my.f5.com
- Modules activés : Lister tous les modules installés et activés sur chaque appliance/instance BIG-IP (physique ou virtuelle).
- Architecture déployée : Identifier si c’est hardware ou VE (virtual edition) ou cloud, et quels hyperviseurs ou plateformes sont utilisées (VMware, KVM, Azure, etc).
- Flux de trafic / chemin applicatif : Cartographier comment le trafic applicatif traverse les modules — ex : client → APM (authentification) → LTM (équilibrage) → back-end; ou client → LTM → ASM (WAF) → serveur.
- Interopérabilité / dépendances externes : Vérifier les points de connexion aux annuaires (LDAP/RADIUS) dans APM, ou aux bases DNS dans module DNS, ou aux logs externes, etc. Ces points externes peuvent devenir des vecteurs.
- Procédures de patching / mise à jour : Vu l’alerte de sécurité (faille F5 mentionnée), vérifier que les correctifs sont appliqués sur le matériel et logiciel BIG-IP.
- Scope de la faille : Comprendre quel module ou version est concernée par la faille signalée — cela permet de cibler les systèmes à risque.
4. Exemple simplifié de cartographie visuelle
Dans cette illustration, vous verrez :
- Le “tronc commun” (TMOS + BIG-IP) sur lequel tous les modules reposent.
- Les modules activés (LTM, ASM, APM, DNS, AFM) comme des “extensions” au tronc.
- Les flèches entre modules montrant :
- LTM ↔ ASM (trafic inspecté)
- LTM ↔ DNS (répartition globale)
- APM → LTM (après auth, trafic équilibré)
- AFM → TMOS/BIG-IP (règles réseau/attaque).
- Le fait que si le tronc est compromis, tous les modules le sont potentiellement.
5. Conclusion et recommandations immédiates
- Vu l’alerte de l’ANSSI (et vos observations sur la faille de F5), je recommande immédiatement de :
- Identifier toutes les instances BIG-IP dans votre périmètre.
- Lister versions, modules activés, plateforme (hardware/VE/cloud).
- Vérifier si la version concernée par la vulnérabilité est présente.
- Mettre à jour/patcher selon les recommandations de F5.
- Vérifier les chemins d’accès administrateur, les habilitations, les flux inter-modules.
- Mettre en place un plan de surveillance renforcée (logs, alertes, trafic anormal) pour les modules sensibles — notamment APM et ASM, car ils traitent accès ou sécurité applicative.
- À moyen terme : cartographier le “qui dépend de quoi” pour chaque service/applicatif dans l’entreprise — chaque module F5 peut être un point de vulnérabilité ou de propagation.
