Chaque entreprise possède une machine qui décide qui vous êtes. Vous vous connectez une fois, elle vérifie la session, émet un jeton et dit à toutes les applications derrière elle de vous faire confiance. Pour beaucoup d'organisations, cette machine est F5 BIG-IP Access Policy Manager (APM) en rôle de serveur d'autorisation OAuth.
Le 22 septembre, F5 a confirmé que des attaquants exécutent déjà leur propre code dessus. Sans se connecter. La faille porte la référence CVE-2026-94127, elle est notée 9.8 (CVSS v3.1), et son correctif doit figurer dans votre planning aujourd'hui, pas au prochain trimestre.
La version courte
- CVE-2026-94127 est un débordement de tampon basé sur le tas (CWE-122) dans BIG-IP APM, noté 9.8 en CVSS v3.1 et 9.3 en v4.0.
- Elle n'existe que lorsque APM est configuré comme serveur d'autorisation OAuth : une politique d'accès et un profil OAuth sur le même serveur virtuel.
- Un trafic malveillant spécifique envoyé à ce serveur virtuel permet à un attaquant non authentifié d'exécuter du code.
- F5 a divulgué la faille le 22 septembre et a publié des correctifs d'ingénierie. Le CISA l'a ajoutée au catalogue KEV le jour même et a donné aux agences fédérales jusqu'au 25 septembre.
- La formulation de F5 : « We have learned that this vulnerability has been exploited. »
Trois jours entre l'avis et l'échéance fédérale. C'est la nouvelle arithmétique du patch, et ce n'est pas une coquille.
Ce qu'est exactement la faille
BIG-IP APM est le module qui arbitre l'accès à vos applications : il exécute la politique d'accès, applique les contrôles de conformité et délivre les jetons que les applications en aval acceptent comme preuve d'identité.
La configuration vulnérable est étroite mais courante : une politique d'accès APM et un profil de serveur d'autorisation OAuth sur le même serveur virtuel. Quand un système est configuré ainsi, un trafic malformé visant le serveur virtuel peut déborder un tampon du tas et remettre l'exécution à l'attaquant.
Les branches concernées et leurs correctifs :
- 21.1 — 21.1.0 avant le correctif →
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG - 17.5 — de 17.5.0 à 17.5.1 →
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG - 17.1 — de 17.1.0 à 17.1.3 →
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
Une bonne nouvelle existe. Si APM n'agit que comme client ou serveur de ressources OAuth, sans profil de serveur d'autorisation configuré, vous n'êtes pas concerné. F5 a mis à jour sa fiche CVE à 00h45 UTC le 23 septembre pour restreindre la condition au rôle de serveur d'autorisation, ce qui signifie que les premières formulations du CERT-EU et du catalogue KEV étaient plus larges que la portée finale. Vérifiez le rôle, pas seulement la version.
Pourquoi restreindre l'interface d'administration ne vous sauvera pas
Le réflexe après toute faille zero-day sur une appliance de bordure est de cacher l'interface d'administration derrière un jump host et de considérer le sujet clos. Ici, cela ne sert à rien.
Il s'agit d'un problème du plan de données. Le trafic malveillant vise le serveur virtuel qui traite les flux OAuth, c'est-à-dire exactement l'adresse que vos utilisateurs, et ceux de vos partenaires, sont censés joindre. F5 indique qu'il n'y a aucune exposition du plan de contrôle et, point crucial, que les systèmes BIG-IP en mode Appliance sont également vulnérables. Le mode Appliance est justement le durcissement que l'on applique pour rendre ces équipements plus difficiles à détourner.
L'exposition n'est donc pas « qui peut joindre le port d'administration ». Elle est « qui peut joindre le point de terminaison d'identité ». Dans la plupart des architectures, c'est Internet.
Et ces appliances ne sont pas rares. Shadowserver suit actuellement plus de 14 700 adresses IP portant une empreinte BIG-IP APM. Ce chiffre ne dit pas combien sont non corrigées ou mal configurées, mais il dit à quel point cette classe de cibles est attractive.
Comment savoir si vous avez déjà été touché
C'est ici que l'histoire devient inconfortable. F5 a divulgué la faille en zero-day, ce qui signifie que les détails exploitables circulaient déjà avant que vous ayez un correctif à installer. Tout ce qui arrive en zero-day a déjà brûlé un temps d'avance inconnu.
F5 a publié des indicateurs que les défenseurs peuvent rechercher. Le motif qui mérite une alerte est une séquence, pas un événement isolé :
- Des échecs répétés d'authentification OAuth contre le serveur virtuel BIG-IP APM.
- Des commandes suspectes apparaissant peu après ces échecs.
- Un événement TMM SIGABRT juste derrière.
Si vous voyez cette chaîne dans une même fenêtre, traitez-la comme une compromission confirmée, pas comme une théorie. Les étapes suivantes du motif, les commandes post-exploitation, n'existent que si quelque chose est entré d'abord.
Si vous ne pouvez pas installer le correctif immédiatement, F5 a publié une iRule via ses canaux de support, qui peut être attachée au serveur virtuel concerné comme atténuation temporaire. Temporaire veut dire exactement cela : elle vous achète les heures nécessaires pour planifier la vraie correction, elle ne la remplace pas.
Ce que nous ferions cette semaine
- Auditez la configuration, pas la bannière de version. Un scan distant ne peut pas dire si des profils de serveur d'autorisation OAuth sont configurés. Extrayez la configuration et listez chaque serveur virtuel qui combine une politique d'accès et un profil OAuth.
- Appliquez les correctifs nommés sur les branches concernées, en commençant par tout ce qui est exposé à Internet. Si une fenêtre de maintenance est inévitable, placez d'abord l'iRule et documentez l'exception.
- Recherchez la chaîne d'indicateurs plus loin que le 22 septembre. Les attaquants connaissaient la faille avant l'avis ; commencez la revue des journaux avant la date de divulgation.
- Tournez les secrets au moindre doute, pas à la certitude. Si la chaîne apparaît, partez du principe que les jetons et secrets clients émis par cette appliance peuvent être compromis. Faites tourner les secrets clients OAuth, revoyez la gestion des clés de signature et invalidez les sessions en cours.
- Cartographiez le rayon d'impact. Toute application qui fait confiance à ce serveur d'autorisation comme fournisseur d'identité se trouve en aval de cette faille. Celles qui acceptent les jetons sans revérifier les claims sont à examiner en premier.
- Testez la restauration du plan d'identité. Votre gestionnaire d'accès est devant presque tout. S'il tombe, comment rentrez-vous ? La plupart des équipes avec lesquelles nous discutons ne l'ont jamais répété.
La conclusion
L'infrastructure d'identité est devenue le joyau de la couronne, et les attaquants sont d'accord. Il y a deux jours, nous écrivions sur les appliances VPN Check Point ; aujourd'hui, c'est le gestionnaire d'accès de F5. Le schéma est constant : les machines qui décident qui entre sont celles qui valent la peine d'être cassées, et leurs failles ne se soucient pas de vos restrictions sur l'interface d'administration.
Corrigez vite, mais ne vous arrêtez pas à la correction. L'échéance de trois jours est un signal sur la vitesse à laquelle l'exploitation suit la divulgation. Détection, audit de configuration et chemin de rétablissement répété sont ce qui vous porte pendant les jours où vous n'avez pas de correctif.
Si vous n'êtes pas certain que votre déploiement BIG-IP APM fonctionne comme serveur d'autorisation OAuth, cette incertitude est le risque. Fermons-la.