L’essentiel
CVE-2026-94127 est une faille critique, déjà exploitée, de F5 BIG-IP Access Policy Manager – mais une seule configuration est exposée : APM en serveur d’autorisation OAuth, avec une politique d’accès et un profil OAuth sur le même serveur virtuel. Si c’est le cas de l’un de vos serveurs virtuels, installez le correctif F5 ou appliquez l’iRule d’atténuation maintenant, puis cherchez dans les journaux des traces de compromission antérieures au correctif. Notre équipe d’audit de sécurité constate souvent le même angle mort : l’entreprise sait qu’elle exploite du BIG-IP, mais personne ne sait quels rôles OAuth il assume.
La leçon de fond est connue. Les équipements placés devant vos applications – répartiteurs de charge, passerelles VPN, proxys d’identité – sont devenus une première cible de choix. Ils sont exposés à Internet, manipulent des identifiants et sont mis à jour plus lentement que le code qu’ils protègent.
Qu’a annoncé F5 ?
F5 a publié l’avis K000162605 le 22 septembre 2026, décrivant un débordement de tampon dans le tas de BIG-IP APM. Un attaquant sans identifiants peut envoyer un trafic forgé vers une configuration OAuth vulnérable et exécuter du code arbitraire sur le système BIG-IP. L’éditeur indique clairement que la vulnérabilité « a été exploitée », d’où une publication hors cycle, en zero-day avec correctifs, plutôt que dans le patch trimestriel habituel.
L’agence américaine CISA l’a ajoutée le même jour à son catalogue des vulnérabilités activement exploitées (KEV), aux côtés de deux failles Check Point et d’une faille d’Arista VeloCloud Orchestrator. Les agences fédérales civiles américaines avaient jusqu’au 25 septembre pour corriger, un délai de trois jours que la CISA réserve aux cas les plus urgents. Ni F5 ni la CISA n’ont précisé le nombre de systèmes compromis ni l’origine des attaques, et Rapid7 ne signalait aucune preuve de concept publique au moment de la divulgation.
F5 compte plus de 23 000 clients, dont 48 des entreprises du Fortune 50, selon BleepingComputer. Cette diffusion, ajoutée au vol de code source et de détails de vulnérabilités BIG-IP lors d’une intrusion étatique chez F5 révélée en octobre 2025, explique pourquoi les équipes sécurité traitent chaque nouvelle zero-day BIG-IP en priorité.
Qui est réellement exposé ?
C’est ici que se joue la différence entre une fenêtre de maintenance sereine et un incident. Disposer d’une licence APM ne suffit pas à être vulnérable. Selon F5, un serveur virtuel doit porter à la fois une politique d’accès APM et un profil OAuth, et la faille ne se déclenche que lorsque APM agit comme serveur d’autorisation OAuth, c’est-à-dire qu’il émet lui-même des jetons. Si vous utilisez APM uniquement comme client OAuth ou serveur de ressources, en validant des jetons émis par Entra ID, Okta ou un autre fournisseur d’identité, F5 indique que vous n’êtes pas concerné.
Le problème, c’est que beaucoup d’entreprises ne savent pas répondre vite. Les configurations BIG-IP s’accumulent au fil des années, souvent montées par une équipe réseau qui a changé depuis, et les rôles OAuth se définissent par profil, pas par équipement. Un seul serveur virtuel oublié, qui fédère un portail partenaires ou une ancienne API mobile, peut être celui qui est exposé. L’attaque vise en outre le plan de données, c’est-à-dire le chemin emprunté par le trafic de vos utilisateurs : restreindre l’interface d’administration ne protège pas.
F5 donne des indicateurs précis : des échecs d’authentification OAuth répétés et des commandes suspectes, suivis peu après d’un TMM SIGABRT (plantage du Traffic Management Microkernel). Un redémarrage inexpliqué du TMM sur un boîtier APM ces dernières semaines mérite qu’on s’y attarde.
Qu’est-ce que cela change pour les entreprises françaises ?
D’abord, les équipements de bordure font partie de la surface d’attaque de vos applications, ce n’est pas un sujet réservé à l’équipe réseau. Quand BIG-IP émet les jetons OAuth de votre produit SaaS ou de votre API mobile, une faille d’exécution de code peut signifier vol de clés de signature, sessions falsifiées ou rebond vers le réseau interne. Les modèles de menace et revues d’architecture doivent mentionner le proxy et son rôle OAuth au même titre que la passerelle d’API et la base de données.
Ensuite, le compteur réglementaire démarre à la détection. Une violation de données personnelles doit être notifiée à la CNIL dans les 72 heures au titre du RGPD. Un proxy d’identité compromis placé devant des données clients peut déclencher en même temps RGPD, NIS2 et DORA : « nous avons patché le deuxième jour » ne répond donc qu’à moitié. Il faut aussi des journaux qui montrent si quelqu’un est entré avant.
Enfin, l’inventaire l’emporte sur l’héroïsme. Les équipes qui versionnent déjà leur configuration de bordure, avec des contrôles automatiques des paramètres à risque, ont répondu à « sommes-nous exposés ? » en quelques minutes cette semaine. Les autres relisaient les configurations à la main. Intégrer cet inventaire et l’automatisation des correctifs à votre pratique cloud et DevOps, c’est la réponse qui tiendra aussi pour la prochaine zero-day d’équipement, pas seulement pour celle-ci.
Que faire maintenant ?
- Repérer la configuration exposée. Listez tous les serveurs virtuels qui portent une politique d’accès APM et un profil OAuth, et vérifiez si APM joue le rôle de serveur d’autorisation. N’oubliez pas la préproduction ni les environnements partenaires.
- Corriger ou atténuer. Installez le hotfix F5 correspondant à votre branche (21.1.0, 17.5.x ou 17.1.x, selon K000162605). Si vous ne pouvez pas patcher aujourd’hui, obtenez l’iRule d’atténuation auprès du support F5 et appliquez-la.
- Chercher avant de se rassurer. Analysez les journaux à la recherche de rafales d’échecs d’authentification OAuth suivies de commandes suspectes et d’un TMM SIGABRT. Remontez avant le 22 septembre : c’était une zero-day.
- Considérer les jetons comme exposés. En cas d’indices de compromission, renouvelez les clés de signature OAuth et les secrets clients stockés sur l’équipement, révoquez les jetons actifs et recherchez de nouveaux comptes administrateurs ou des modifications de configuration. Évaluez en parallèle vos obligations de notification (CNIL, ANSSI, superviseur financier).
- Combler le manque d’inventaire. Versionnez les configurations de bordure et intégrez-les à votre modèle de menace et à vos scans de vulnérabilités, pour que la prochaine question « sommes-nous concernés ? » prenne quelques minutes.
Questions fréquentes
Qu’est-ce que CVE-2026-94127 ?
CVE-2026-94127 est un débordement de tampon dans le tas (CWE-122) de F5 BIG-IP Access Policy Manager (APM). Un attaquant distant non authentifié peut envoyer un trafic forgé vers une configuration OAuth vulnérable et exécuter du code arbitraire sur le système BIG-IP. F5 lui attribue un score CVSS v3.1 de 9.8 et CVSS v4.0 de 9.3, et l’a publiée le 22 septembre 2026 après avoir constaté qu’elle était déjà exploitée.
Tous les déploiements BIG-IP APM sont-ils vulnérables ?
Non. Tout dépend de la configuration. Un serveur virtuel doit porter à la fois une politique d’accès APM et un profil OAuth, avec BIG-IP APM en serveur d’autorisation OAuth. Les déploiements qui utilisent APM uniquement comme client OAuth ou serveur de ressources, sans profil de serveur d’autorisation, ne sont pas concernés selon F5.
Quelles versions sont corrigées ?
F5 a publié des correctifs d’ingénierie pour les branches supportées : Hotfix-BIGIP-21.1.0.2.0.30.22-ENG pour 21.1.0, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG pour 17.5.x et Hotfix-BIGIP-17.1.3.5.0.41.14-ENG pour 17.1.x, ou ultérieurs. Les équipes qui ne peuvent pas patcher immédiatement peuvent demander une iRule d’atténuation au support F5. La référence reste l’avis F5 K000162605.
Comment savoir si mon BIG-IP a déjà été compromis ?
F5 recommande de rechercher dans les journaux BIG-IP des échecs d’authentification OAuth répétés et des commandes suspectes, suivis peu après d’un TMM SIGABRT. L’exploitation ayant commencé avant le correctif, les équipes dont la configuration de serveur d’autorisation OAuth est exposée doivent aussi analyser les journaux antérieurs au 22 septembre 2026.
Faut-il notifier l’incident en France ?
Cela dépend de ce que révèle l’analyse, pas du correctif. En cas de compromission avérée, une violation de données personnelles doit être notifiée à la CNIL sous 72 heures au titre du RGPD ; les opérateurs régulés (OIV, OSE et entités concernées par NIS2) signalent leurs incidents à l’ANSSI ; les établissements financiers relèvent en outre du règlement DORA et de la déclaration d’incidents TIC majeurs auprès de leur superviseur. L’échéance CISA du 25 septembre ne s’applique qu’aux agences fédérales américaines.
Sources
F5 — K000162605: BIG-IP APM vulnerability CVE-2026-94127 (avis éditeur)
CISA — CISA Adds Four Known Exploited Vulnerabilities to Catalog (22 septembre 2026)
BleepingComputer — F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks
The Register — Someone’s attacking a critical 0-day RCE in F5 BIG-IP APM
Rapid7 — CVE-2026-94127: Critical Unauthenticated RCE in F5 BIG-IP APM