Une faille critique en périphérie du réseau
F5 a corrigé CVE-2026-94127, une vulnérabilité critique d’exécution de code à distance dans BIG-IP Access Policy Manager (APM). Ce débordement de tampon dans le tas obtient un score CVSS de 9,8 et faisait déjà l’objet d’une exploitation active avant la disponibilité du correctif.
BIG-IP APM contrôle l’accès aux ressources internes, effectue des vérifications côté client, gère l’authentification et les autorisations, et fournit une connectivité VPN aux utilisateurs distants. Sa position en périphérie du réseau rend l’identification précise des actifs et leur remédiation rapide particulièrement importantes.
La Cybersecurity and Infrastructure Security Agency américaine a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities, confirmant ainsi son exploitation dans des attaques réelles.
Quels déploiements sont concernés ?
La vulnérabilité n’est exploitable que lorsque le système BIG-IP réunit les deux éléments suivants :
BIG-IP APM est configuré ;
un profil de serveur d’autorisation OAuth est configuré.
Le problème concerne également les systèmes BIG-IP fonctionnant en mode appliance lorsque ces conditions sont remplies. Selon F5, les déploiements qui utilisent APM uniquement comme client OAuth ou serveur de ressources ne sont pas affectés.
Cette distinction rend le contexte de configuration indispensable. Savoir qu’APM est installé ne suffit pas : les équipes doivent déterminer le rôle OAuth configuré sur chaque système.
La Shadowserver Foundation suit plus de 15 000 déploiements BIG-IP APM exposés à Internet, dont environ 5 000 en Amérique du Nord et 5 000 en Europe. Ces chiffres ne précisent pas combien disposent de la configuration vulnérable de serveur d’autorisation OAuth.
Correctifs et mesure temporaire disponibles
F5 recommande d’appliquer le hotfix correspondant à la branche encore prise en charge :
21.x :
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.iso17.5.x :
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.iso17.1.x :
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.iso
F5 a également publié une iRule accessible depuis son portail de support. Celle-ci peut servir de mesure temporaire en attendant l’application du hotfix approprié.
Pour chaque appliance concernée, le processus d’intervention devrait consigner :
La branche BIG-IP installée.
La présence d’APM et d’un profil de serveur d’autorisation OAuth.
Le hotfix retenu ou le déploiement temporaire de l’iRule.
L’heure de l’intervention et l’opérateur responsable.
La validation après changement et les preuves de configuration conservées.
Rechercher des indicateurs de compromission corrélés
F5 précise qu’un indicateur isolé ne prouve pas nécessairement une exploitation. Les administrateurs doivent rechercher une séquence associant plusieurs échecs d’authentification OAuth, des commandes suspectes, puis un événement TMM SIGABRT.
Plus de 10 messages d’échec OAuth répétés, en particulier lorsqu’ils proviennent de la même adresse IP, doivent conduire à une investigation. La commande suivante permet de consulter les compteurs concernés :
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failedSi les volumes observés paraissent suspects, F5 recommande d’examiner les événements enregistrés aux mêmes horaires dans :
/var/log/auditLes équipes doivent également rechercher des fichiers core TMM. L’exploitation peut placer TMM dans une boucle, provoquer son arrêt et générer ces fichiers. Ces éléments doivent être corrélés et ne doivent pas être considérés séparément comme une preuve de compromission.
La preuve d’installation du correctif ne remplace pas l’analyse d’incident si des activités OAuth suspectes ou des arrêts de TMM se sont produits avant la remédiation.
Comment ConnectMyAssets peut aider
ConnectMyAssets fournit une approche sur site et indépendante des constructeurs pour coordonner cette intervention dans une infrastructure réseau multimarque.
Dynamic CMDB : identifier les actifs BIG-IP inventoriés, leurs branches logicielles, leur exposition réseau et leurs responsables opérationnels. Le contexte de configuration aide à distinguer les serveurs d’autorisation OAuth des systèmes utilisés uniquement comme clients ou serveurs de ressources.
Suivi des CVE par actif : associer CVE-2026-94127 aux appliances concernées et suivre leur état de remédiation individuellement.
Backup & History : conserver les versions de configuration avant et après le déploiement du hotfix ou de l’iRule, avec un historique des changements et un point de retour arrière.
Compliance Engine : enregistrer les contrôles et les preuves de remédiation pour des référentiels tels que NIS2, ISO 27001, PCI, CISA et NIST.
Automation : coordonner des tâches reproductibles de collecte et de remédiation sur les actifs affectés tout en maintenant un processus auditable.
Suivi de fin de vie : rendre visible le cycle de vie logiciel afin de déterminer la branche prise en charge et le chemin de correction applicables.
ConnectMyAssets fonctionnant sur site, les configurations, les informations d’actifs et les preuves de remédiation restent dans l’environnement de l’organisation. L’objectif ne consiste pas seulement à déclarer la CVE traitée, mais à démontrer quels systèmes ont été évalués, pourquoi ils sont considérés comme affectés ou non, ce qui a changé et comment le résultat a été vérifié.
Priorités immédiates
Inventorier les systèmes BIG-IP APM internes et exposés à Internet.
Vérifier si chacun dispose d’un profil de serveur d’autorisation OAuth.
Appliquer le hotfix F5 approprié ou utiliser l’iRule publiée comme mesure temporaire.
Analyser conjointement les échecs OAuth, les journaux d’audit, les commandes suspectes, les événements TMM SIGABRT et les fichiers core.
Conserver les configurations avant et après intervention ainsi que les preuves de remédiation.
Soumettre à une analyse humaine tout système présentant des indicateurs corrélés.
Cet incident illustre une nouvelle fois l’intérêt des attaquants pour les équipements de périphérie et les passerelles VPN comme points d’entrée dans les réseaux d’entreprise. La rapidité d’application des correctifs est essentielle, mais elle doit s’accompagner d’un contexte de configuration fiable et de preuves de remédiation vérifiables.
Source : Network World
