La semaine où l'émetteur d'identité lui-même est tombé — zero-day OAuth de F5 BIG-IP APM (CVE-2026-94127) et la concentration du KEV sur les plans de gestion et d'identité
F5 a divulgué le 22 septembre qu'un zero-day critique dans le chemin OAuth de BIG-IP APM (CVE-2026-94127, CVSS 9.8) permet une exécution de code à distance non authentifiée, et a confirmé une exploitation dans la nature. CISA l'a ajouté au catalogue KEV le même jour, avec une échéance fédérale au 25 septembre. Arista VCO et 2 failles de serveurs de gestion Check Point sont aussi entrées dans le KEV ce jour-là — nous examinons la convergence des attaques sur les plans de gestion et d'identité des appliances de frontière.
Cet article a été traduit par une machine.
Le 22 septembre 2026, F5 a divulgué CVE-2026-94127 (identifiant interne 2524777) dans BIG-IP Access Policy Manager (APM). Lorsqu'une politique d'accès APM et un profil OAuth sont configurés sur un serveur virtuel, un trafic malveillant spécifique peut mener à une exécution de code à distance (RCE) — un débordement de tampon sur le tas (CWE-122) — portant un score CVSS v3.1 de 9.8 (tel que rapporté par F5) et un CVSS v4.0 de 9.3 (tel que rapporté par F5, via NVD). La faille est limitée aux déploiements où BIG-IP APM est configuré comme serveur d'autorisation OAuth ; les déploiements qui utilisent APM strictement comme Client / Resource Server ne sont pas affectés. F5 indique être « au courant que cette vulnérabilité a été exploitée » et note que le défaut a été découvert en interne. Il s'agit d'un problème du plan de données, sans exposition du plan de contrôle, et BIG-IP en mode Appliance est aussi vulnérable. Les versions affectées sont 21.1.0 (corrigée dans Hotfix-BIGIP-21.1.0.2.0.30.22-ENG), 17.5.0-17.5.1 (corrigée dans Hotfix-BIGIP-17.5.1.9.0.160.12-ENG) et 17.1.0-17.1.3 (corrigée dans Hotfix-BIGIP 17.1.3.5.0.41.14-ENG) ; BIG-IP Next, F5 Distributed Cloud, NGINX et F5OS ne sont pas affectés (avis F5 K000162605).
CISA a ajouté la vulnérabilité à son catalogue KEV le 22 septembre, donnant aux agences civiles fédérales jusqu'au 25 septembre pour répondre (BOD 26-04, 3 jours à compter de l'inscription). Elle est soumise à un triage forensique, et les notes du KEV de CISA orientent les opérateurs vers l'application de l'iRule fournie par l'éditeur comme mitigation temporaire, puis vers l'installation du correctif final dès que possible. F5 propose de même une mitigation par iRule pour le serveur virtuel affecté, disponible par le support F5. Pour l'évaluation d'une compromission, F5 a publié 3 indicateurs de compromission, que l'avis de CERT-EU (2026-013) organise en un examen en 4 étapes : des échecs d'authentification OAuth répétés (invalid_token) dans /var/log/apm, une augmentation inexpliquée de total_failed via tmctl global_oauth_stat, des commandes suspectes dans /var/log/audit autour de ces horodatages, et la boucle TMM qui fait envoyer un SIGABRT par le démon SOD (la seule présence d'un fichier core TMM n'est pas un indicateur) — c'est la combinaison et la fréquence de ceux-ci qui sont en corrélation avec une attaque (selon The Hacker News, le catalogue KEV de CISA et CERT-EU).
Analyse (séparée des faits) : ce qui mérite l'attention est moins le CVE isolé que la composition des 4 entrées arrivées dans le catalogue KEV le 22 septembre : cette faille F5 BIG-IP APM, plus Arista VeloCloud Orchestrator (CVE-2026-93952) et 2 failles de serveurs de gestion Check Point (CVE-2026-93616 / CVE-2026-85102). Leur fil commun est que les « plans de gestion et d'identité » des fonctions réseau distribuées sont les cibles. La semaine dernière, cet observatoire a couvert le contournement d'authentification de l'API de gestion de Cisco ISE (CVE-2026-76460) et le problème selon lequel les journaux propres d'une appliance compromise ne sont plus une source primaire. Ce cas avance d'un pas de plus : là où APM est utilisé comme serveur d'autorisation OAuth, l'appliance elle-même est en pratique l'émetteur d'identité, et une RCE non authentifiée sur son plan de données porte la connotation de capturer l'émetteur lui-même. Le fait que F5 ait découvert le défaut en interne suggère une fenêtre silencieuse d'exploitation dans la nature avant la divulgation ; l'attribution de la partie qui exploite n'est pas encore publique.
Implications défensives : (1) Si vous exécutez BIG-IP APM comme serveur d'autorisation OAuth, appliquez d'abord le hotfix correspondant (ou une version ultérieure sur la même branche). Les déploiements qui utilisent APM strictement comme client / serveur de ressources sont hors périmètre, mais les configurations hybrides qui incluent un profil de serveur d'autorisation exigent un inventaire par serveur virtuel. (2) Là où la mitigation par iRule est déployée avant le correctif, enregistrez-la comme une mitigation — selon les notes de CISA, comme un palliatif à coupler au correctif final. (3) Exécutez la détection en 4 étapes de CERT-EU (répétition des échecs OAuth, total_failed, journaux d'audit, core TMM) sur l'appliance elle-même, tout en examinant aussi l'historique pare-feu / NetFlow du trafic vers APM, sur la prémisse que les journaux propres de l'appliance peuvent ne plus être une source primaire. (4) Avec le même regard, inventoriez l'exposition des actifs du « plan de gestion et d'identité » — Arista VCO et les serveurs de gestion Check Point compris — en parallèle du correctif par CVE. Les faits ici s'appuient sur l'avis de F5 (https://my.f5.com/manage/s/article/K000162605), le catalogue KEV de CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), la fiche CVE du NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-94127), l'avis CERT-EU 2026-013 (https://cert.europa.eu/publications/security-advisories/2026-013/), The Hacker News (https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html) et SecurityWeek (https://www.securityweek.com/critical-f5-big-ip-vulnerability-exploited-as-zero-day/). L'analyse est tenue séparée du compte rendu.