F5 corrige la faille zero-day du BIG-IP APM exploitée pour exécuter du code sans authentification

22 septembre 2026. F5 publie un avis et des correctifs d’ingénierie pour une faille du module APM de BIG-IP. 22 septembre 2026. La CISA ajoute la faille à son catalogue KEV des vulnérabilités activement exploitées. 23 septembre 2026. F5 précise que la faille ne concerne que le rôle de serveur d’autorisation OAuth. Pourquoi c’est important : CVE-2026-94127 permet d’exécuter du code à distance sans la moindre authentification, et l’attaque frappe le serveur virtuel lui-même — la restriction de l’interface de gestion n’y change rien.

Une faille logée dans le rôle de serveur d’autorisation OAuth

BIG-IP APM (Access Policy Manager) est le module qui contrôle la façon dont les utilisateurs accèdent aux applications et au réseau d’une organisation. La configuration vulnérable n’est pas anodine : il faut qu’un profil d’autorisation OAuth soit associé à une access policy sur le même serveur virtuel, celui qui reçoit le trafic OAuth.

Le défaut est un débordement de tampon dans le tas (heap-based buffer overflow). Un trafic malveillant envoyé précisément vers ce serveur virtuel déclenche une exécution de code à distance. F5 note la faille 9,8 sur 10 en CVSS v3.1 et 9,3 en CVSS v4.0 — le haut du barème pour une faille exploitable à distance, sans interaction et sans privilège.

Le détail qui change la donne est arrivé le lendemain. F5 a mis à jour sa fiche CVE à 00 h 45 UTC le 23 septembre pour restreindre le périmètre : la faille n’existe que lorsque APM joue le rôle de serveur d’autorisation — celui qui émet les jetons d’accès. Un système où APM sert uniquement de client OAuth ou de resource server, sans profil de serveur d’autorisation, n’est pas concerné. L’avis CERT-EU et l’entrée KEV de la CISA, publiés avant cette correction, décrivent la condition de façon plus large — une access policy et un profil OAuth sur le même serveur virtuel.

Pourquoi couper l’accès au plan de gestion ne protège pas

La leçon de cette faille tient en une phrase : l’interface de gestion n’est pas la cible. Sur la plupart des failles d’équipements réseau, la parade immédiate consiste à ne pas exposer l’administration (port 443 du management, SSH, interface web). Ici, cette mesure est inopérante.

Le trafic malveillant atteint le serveur virtuel lui-même, c’est-à-dire le plan de données qui fait transiter les connexions des utilisateurs. Autrement dit, un BIG-IP en production qui expose son service d’autorisation OAuth — précisément ce qu’on attend de lui — est atteignable sans que l’attaquant ait besoin d’un accès d’administration. Les systèmes en Appliance mode, réputés plus verrouillés, sont également vulnérables.

Cette nuance explique la réactivité de la CISA : l’agence a inscrit la faille au KEV le jour même de la divulgation, le 22 septembre, et fixe au 25 septembre l’échéance pour les agences civiles fédérales, au titre d’une directive émise en juin. Un délai de trois jours pour un correctif sur un équipement de périmètre dit à quel point la faille est jugée triviale à exploiter.

Les versions touchées et les correctifs

F5 n’a pas publié de version classique, mais des hotfix d’ingénierie (engineering hotfixes) par branche. Seules trois branches sont concernées, et uniquement pour les systèmes où APM est serveur d’autorisation OAuth :

Deux précisions méritent l’attention. D’abord, F5 n’a pas évalué les versions en fin de support technique : leur statut est inconnu, pas sain. Ensuite, la faille voisine CVE-2025-53521, déjà inscrite au KEV en mars, voit ses correctifs 17.1.3 et 17.5.1.3 tomber dans la plage affectée ci-dessus. Un système mis à niveau vers ces builds a donc encore besoin du nouveau hotfix s’il héberge un serveur d’autorisation OAuth.

Quand le hotfix ne peut pas être installé immédiatement, F5 fournit une iRule de contournement à appliquer sur le serveur virtuel concerné — obtenue en ouvrant un ticket auprès du support. La CISA recommande d’appliquer l’iRule d’abord, « pour permettre un tri forensique proactif », puis d’installer le correctif final dès que possible.

Détecter l’exploitation avant qu’elle ne se transforme en compromission

L’exploitation laisse une signature lisible dans les journaux. F5 et CERT-EU décrivent un triptyque qui doit déclencher une revue humaine : des échecs d’authentification OAuth répétés, suivis de commandes suspectes, suivis d’un SIGABRT de TMM peu après.

# Compteurs OAuth du module APM — surveiller la hausse de total_failed
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

# Échecs répétés de UserInfo : la signature de l'exploitation
grep "The access token is invalid" /var/log/apm

# Commandes suspectes dans l'audit, autour de l'horodatage des échecs
grep -iE "useradd|/bin/|curl|wget|tmctl" /var/log/audit/audit.log

Dans le détail, la combinaison à traquer est la suivante. Le journal APM montre des requêtes UserInfo en échec dans /var/log/apm, avec le message « The access token is invalid » — en particulier dix requêtes ou plus depuis une même adresse IP en peu de temps. Le compteur OAuth révèle une hausse inexpliquée de total_failed. Le journal d’audit enregistre des commandes suspectes autour de ces échecs. Les core files de TMM ne sont pas un signe en soi, mais valent investigation — F5 a observé TMM entrer en boucle et le démon SOD envoyer un SIGABRT.

Une zone d’ombre demeure, assumée par les avis : ni F5, ni la CISA, ni CERT-EU n’indiquent si l’installation du hotfix révoque un accès déjà obtenu par un attaquant. Le réflexe est donc double — corriger, mais aussi rechercher des signes de compromission avant de considérer le dossier clos.

L’angle identité : pourquoi un serveur d’autorisation OAuth est une cible de choix

La faille mérite qu’on s’arrête sur ce qu’est un serveur d’autorisation OAuth. C’est la brique qui émet les jetons d’accès que les applications présentent ensuite pour appeler des API ou des ressources protégées. En compromettant cette brique, l’attaquant ne vole pas un mot de passe : il forge sa propre légitimité. Un serveur d’autorisation corrompu peut émettre des jetons valides pour n’importe quelle application cliente — ce qui transforme une exécution de code unique en compromission durable de toute la chaîne d’identité.

C’est ce qui distingue cette faille d’un simple RCE sur un équipement de routage. Ici, la cible n’est pas le trafic, mais la confiance. L’attaquant qui tient le serveur d’autorisation peut, en principe, révoquer l’accès des autres, émettre des jetons pour lui-même ou s’installer durablement dans le flux d’authentification. La consigne de CERT-EU — préserver les preuves avant de corriger — prend alors tout son sens : on ne sait pas encore si le correctif ferme un accès déjà obtenu.

Autre particularité : la faille ne dépend pas d’un logiciel tiers, mais d’une configuration — l’association d’un profil d’autorisation OAuth à une access policy. Les équipes qui utilisent APM pour fédérer des identités (SAML, OIDC, OAuth) sont exactement celles qui sont exposées. La recommandation n’est donc pas seulement « patcher », mais recenser les serveurs virtuels qui portent un rôle de serveur d’autorisation, puis les traiter en priorité.

Verdict

CVE-2026-94127 est la démonstration qu’un équipement de périmètre peut être compromis par son plan de données, pas par son plan de gestion. Si votre BIG-IP APM sert de serveur d’autorisation OAuth, appliquez le hotfix de votre branche sans attendre, ou l’iRule de contournement en attendant. Si APM n’est utilisé que comme client OAuth ou resource server, vous n’êtes pas exposé à cette faille précise — mais vérifiez votre configuration pour l’affirmer, plutôt que de le supposer. Dans tous les cas, traquez les échecs UserInfo répétés et la hausse de total_failed : c’est la trace la plus fiable d’une exploitation déjà en cours.

Références

• The Hacker News — F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers (23 septembre 2026)
• CISA — Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-94127