Une nouvelle vulnérabilité de F5 BIG-IP mérite une attention urgente, mais son risque est facile à mal interpréter. CVE-2026-94127 ne concerne pas tous les déploiements BIG-IP et ne constitue pas une simple mise à jour pour les équipes qui utilisent le produit. Elle touche une configuration précise d’Access Policy Manager, dans laquelle une stratégie d’accès APM et un profil de serveur d’autorisation OAuth sont associés au même serveur virtuel. F5 indique que la vulnérabilité est exploitée dans la nature.

Passerelle d’accès d’entreprise montée en baie, avec câbles réseau et voyants dans une salle serveur sécurisée

La première question opérationnelle doit donc être plus précise que « Utilisons-nous F5 ? ». La question utile est la suivante : « Avons-nous un serveur virtuel BIG-IP exposé qui fait fonctionner APM comme serveur d’autorisation OAuth, et quelles preuves pouvons-nous recueillir avant et après la remédiation ? »

Les organisations qui remplissent cette condition doivent traiter le problème comme une tâche de réponse à incident comportant un volet de correction. L’équipement peut se trouver à une frontière d’accès, gérer des flux d’authentification et occuper une position de confiance entre les utilisateurs et les applications internes. Une compromission réussie pourrait donc dépasser largement le seul appareil. En revanche, selon l’avis du fournisseur, les déploiements qui utilisent APM strictement comme client OAuth ou serveur de ressources, sans profil de serveur d’autorisation OAuth, ne sont pas concernés.

Ce que CVE-2026-94127 affecte

CVE-2026-94127 est décrite comme un dépassement de tampon dans le tas de BIG-IP APM. Dans la configuration vulnérable, un trafic réseau spécialement conçu peut provoquer une exécution de code à distance sans authentification préalable. Le composant concerné se trouve dans le plan de données : le trafic atteint le serveur virtuel qui traite les demandes d’accès et les demandes OAuth correspondantes. Cette distinction est importante pour les défenseurs, car l’exposition ne se limite pas à l’interface d’administration.

La dépendance à la configuration est au cœur de l’avis. Un système BIG-IP doit exécuter une branche logicielle concernée et prise en charge ; APM doit être provisionné ; une stratégie d’accès doit être présente ; et un profil de serveur d’autorisation OAuth doit être associé au serveur virtuel qui reçoit le trafic. F5 a précisé que les déploiements utilisant APM uniquement comme client OAuth ou serveur de ressources, sans profil de serveur d’autorisation OAuth, ne sont pas affectés par ce problème.

La terminologie du produit peut compliquer l’inventaire. L’inventaire de la plateforme peut indiquer qu’APM est activé sur un équipement, tandis que l’inventaire réseau ne recense qu’une adresse IP virtuelle et un nom de service. Aucun de ces éléments ne permet à lui seul d’établir si CVE-2026-94127 s’applique. Les équipes doivent rapprocher la version logicielle, l’état des modules, la configuration des serveurs virtuels, l’association des stratégies d’accès, le rôle OAuth, l’exposition et le propriétaire.

L’alerte du Centre canadien pour la cybersécurité identifie les plages de versions concernées et les correctifs d’ingénierie disponibles. Les branches vulnérables citées comprennent BIG-IP 17.1.0 jusqu’aux versions antérieures au correctif 17.1 indiqué, 17.5.0 jusqu’aux versions antérieures au correctif 17.5 indiqué, et 21.1.0 jusqu’aux versions antérieures au correctif 21.1 indiqué. L’applicabilité exacte du build et du correctif doit être vérifiée dans l’avis client actuel de F5 et au regard de l’état de support de l’organisation avant l’approbation d’une modification.

Le problème est classé critique dans les publications publiques, avec un score CVSS v3.1 de 9,8 cité par plusieurs sources. Ce score apporte un contexte utile, mais ce n’est pas le signal de priorisation le plus important ici. Les éléments décisifs sont l’exécution de code à distance avant authentification, un composant d’accès exposé au réseau, une configuration pouvant se trouver devant de nombreuses applications et l’exploitation confirmée.

Pourquoi le rôle OAuth compte

OAuth est souvent présenté comme une fonctionnalité unique ayant un profil de risque unique. En pratique, une plateforme d’identité peut jouer plusieurs rôles. Un client OAuth demande une autorisation à un autre serveur d’autorisation. Un serveur de ressources accepte des jetons d’accès pour protéger une API. Un serveur d’autorisation authentifie les utilisateurs et délivre des jetons aux clients. Ces rôles entraînent des chemins de requête et des conditions d’exposition différents.

CVE-2026-94127 est liée au rôle de serveur d’autorisation sur APM. C’est pourquoi une affirmation générale comme « Nous n’utilisons pas OAuth » ne suffit pas, et pourquoi « APM est installé, mais il ne sert pas actuellement au VPN » ne permet pas de trancher. Un déploiement peut utiliser OAuth pour un portail applicatif, un service de fédération, une passerelle API ou un autre flux d’accès dont le propriétaire ne fait pas partie de l’équipe réseau.

Une revue utile part du serveur virtuel plutôt que du nom du produit. Pour chaque équipement BIG-IP, identifiez les serveurs virtuels accessibles depuis des réseaux non fiables ou largement approuvés. Recensez le profil d’accès associé et vérifiez si ce profil fait référence à une configuration de serveur d’autorisation OAuth. Notez ensuite les applications, API, services VPN ou flux administratifs qui dépendent du serveur virtuel. Vous obtiendrez ainsi une carte de l’exposition technique et des conséquences métier.

N’inférez pas la sécurité de l’absence d’une URL connue. Un proxy inverse ou une passerelle d’accès peut publier plusieurs chemins, et un nom d’hôte peut changer alors que le serveur virtuel sous-jacent reste le même. De même, un équipement peut être protégé d’Internet tout en restant accessible depuis des réseaux partenaires, des segments d’accès distant, un transit cloud ou d’autres environnements où un attaquant pourrait obtenir un accès réseau. L’exposition doit être évaluée à partir de la joignabilité réelle et du flux des requêtes.

La revue de configuration doit aussi couvrir les paires haute disponibilité, les unités en veille, les groupes de trafic, les équipements de reprise après sinistre, les systèmes de laboratoire connectés à la production et les appareils administrés au moyen d’une orchestration centralisée. Corriger uniquement l’unité active laisse une faille prévisible si le système de secours peut être promu avec le build ou la configuration vulnérable.

L’exploitation modifie la réponse

F5 a indiqué que CVE-2026-94127 est exploitée dans la nature. Cela ne signifie pas que tous les clients vulnérables ont été compromis et ne permet pas d’identifier tous les attaquants ou toutes les victimes. Cela établit toutefois que les défenseurs ne doivent pas attendre un cycle de maintenance pratique lorsqu’une configuration concernée est exposée.

Une réponse limitée au correctif répond à la question « La version est-elle corrigée ? ». Elle ne répond pas à « L’équipement a-t-il été utilisé avant la correction ? ». Pour une passerelle d’accès, cette seconde question est essentielle. L’appareil peut traiter le trafic d’authentification, conserver l’état des sessions, communiquer avec des services d’annuaire, atteindre des applications protégées et échanger avec des systèmes de gestion ou de journalisation. Si un attaquant a obtenu l’exécution de code, les conséquences possibles comprennent des modifications non autorisées de l’équipement, l’interception ou la manipulation de flux d’accès, l’exposition de secrets ou de jetons, la persistance ou un déplacement vers des systèmes connectés. Il s’agit de conséquences possibles, et non d’affirmations selon lesquelles elles se sont produites dans un environnement donné.

La réponse appropriée doit donc suivre deux axes : réduire l’exposition et préserver les preuves en parallèle. Une équipe peut installer le correctif du fournisseur tout en menant une évaluation ciblée de compromission. Elle peut aussi appliquer la mesure temporaire fournie par le fournisseur en préparant la modification, mais une solution de contournement ne doit pas devenir un motif pour repousser la version corrigée.

Le Centre canadien recommande d’examiner les journaux d’accès à la recherche d’indicateurs tels que des échecs d’authentification OAuth survenant en succession rapide ou en volume inhabituellement élevé. Ce signal ne prouve pas une exploitation. Il constitue un point de départ pratique pour une recherche limitée dans le temps, en particulier s’il est rapproché d’une activité administrative inattendue, de modifications de stratégies d’accès, de nouveaux comptes, de changements d’objets de serveurs virtuels, d’exports de configuration suspects, de redémarrages inexpliqués ou de connexions depuis l’équipement qui ne correspondent pas à son rôle habituel.

L’interprétation des journaux demande de la prudence. Un pic de requêtes OAuth échouées peut être dû à une panne client, à un déploiement défectueux, à un scanner ou à une attaque. À l’inverse, un journal calme ne prouve pas l’absence de compromission si la journalisation était incomplète, si les données ont été purgées, filtrées ou modifiées. Les enquêteurs doivent préserver les enregistrements originaux, documenter les heures et fuseaux horaires de collecte, comparer plusieurs sources de télémétrie et préciser ce que les preuves permettent ou non d’établir.

La première fenêtre de réponse

Le premier objectif consiste à déterminer si la condition préalable vulnérable existe. Désignez un responsable chargé de produire une liste de référence des systèmes BIG-IP et un autre chargé de la valider par rapport aux données de configuration. Ne vous appuyez pas sur un seul scanner de vulnérabilités. De nombreux scanners peuvent identifier un produit et une version, mais une exposition dépendante de la configuration exige souvent un accès à la configuration de l’équipement ou un export fiable depuis le système de gestion.

Pour chaque système, recueillez au minimum :

  • la version logicielle, le niveau de correctif, l’état du support et la forme de déploiement, matérielle ou virtualisée ;
  • la présence et l’activation d’APM ;
  • chaque serveur virtuel portant une stratégie d’accès APM ;
  • la présence d’un profil de serveur d’autorisation OAuth associé à ce chemin ;
  • la joignabilité réseau, notamment depuis Internet, les partenaires, l’accès distant et les segments internes ;
  • les applications dépendantes, les magasins d’identité, les API et les propriétaires métier ;
  • les relations de haute disponibilité et de reprise après sinistre ;
  • la télémétrie disponible sur les accès, l’authentification, l’administration, le système et le réseau.

Le résultat doit distinguer les systèmes « affectés », « non affectés parce que la condition de configuration est absente », « inconnus en attente de validation » et « hors de la plage de versions prise en charge ». Ces catégories ont des conséquences opérationnelles différentes. « Inconnu » ne doit pas être traité silencieusement comme « sûr », surtout si le système est joignable et que la configuration ne peut pas être vérifiée rapidement.

Lorsqu’un serveur virtuel affecté est exposé, réduisez les accès inutiles tout en préservant si possible le service métier. Des contrôles réseau limitant les entités autorisées à envoyer des requêtes au serveur virtuel peuvent réduire les possibilités d’attaque, mais ils ne remplacent pas le correctif du fournisseur. Un équipement qui n’est pas exposé à Internet peut néanmoins l’être pour un partenaire compromis, un poste, une charge de travail ou un compte d’accès distant.

F5 fournit, par l’intermédiaire de son support, une mesure d’atténuation sous forme d’iRule pour les organisations qui ne peuvent pas installer immédiatement le correctif d’ingénierie. La règle exacte, son emplacement, sa compatibilité et sa procédure de validation doivent provenir de F5 pour le déploiement concerné. Les équipes ne doivent pas copier une règle depuis un forum non vérifié ni improviser une logique de filtrage sur un trafic d’authentification de production. Un contrôle temporaire qui casse les flux OAuth légitimes peut provoquer une panne tout en laissant planer un doute sur sa couverture de sécurité.

Restreindre les interfaces de gestion à des réseaux administratifs de confiance reste une bonne pratique et figure dans les recommandations défensives, mais cela ne doit pas être confondu avec une atténuation complète de cette vulnérabilité. Le trafic vulnérable passe par le serveur virtuel du plan de données. Le renforcement du plan de gestion limite une autre exposition.

Corriger sans perdre l’enquête

Les modifications d’urgence sur une infrastructure d’accès nécessitent un plan court mais explicite. Avant le changement, consignez la version logicielle actuelle, la somme de contrôle de configuration ou le processus d’export approuvé par l’organisation, l’état de la haute disponibilité, les groupes de trafic actifs, les dépendances et les conditions de retour arrière. Confirmez que le correctif vise exactement la branche et le mode de déploiement concernés. Organisez un test de l’authentification, de l’émission des jetons, de leur validation, de la déconnexion, du renouvellement des sessions et de l’accès aux applications en aval.

Ne supposez pas qu’un redémarrage réussi de l’équipement prouve que la modification de sécurité a fonctionné. Après l’installation, vérifiez le build exécuté sur chaque unité concernée, confirmez que les serveurs virtuels vulnérables restent dans l’état prévu et testez les parcours utilisateurs qui dépendent d’APM. Si la configuration a été modifiée pendant le confinement, consignez cette modification séparément de la mise à jour logicielle afin que les enquêteurs puissent ensuite distinguer les effets de l’atténuation d’une activité de l’attaquant.

La préservation des preuves doit intervenir avant l’expiration des journaux. Exportez les enregistrements pertinents de l’équipement BIG-IP et des systèmes qui l’entourent : répartiteurs de charge, pare-feu applicatifs, pare-feu en amont, fournisseurs d’identité, services d’annuaire, télémétrie des postes, systèmes de détection réseau et journalisation centralisée. Conservez les copies brutes sous les contrôles prévus pour la gestion des incidents et utilisez des copies de travail pour l’analyse.

La période examinée doit commencer avant la divulgation publique et s’étendre, lorsque c’est possible, à toute la fenêtre de remédiation. La date de début exacte dépend de la conservation des données, de l’exposition et du modèle de menace de l’organisation. Au minimum, examinez les activités associées à des échecs OAuth inhabituels, à un volume anormal de requêtes, à des connexions d’administration, à des changements de configuration, à de nouveaux comptes ou comptes modifiés, à une activité de commande ou de shell inattendue, à des connexions sortantes inexpliquées et à des changements de fichiers ou de processus que le propriétaire de la plateforme ne peut pas expliquer.

Un correctif installé avec succès et l’absence d’indicateurs manifestes doivent être consignés comme l’évaluation actuelle, sans être transformés en certitude absolue. Si les journaux sont incomplets ou si l’équipement ne fournit pas suffisamment de preuves, faites remonter cette incertitude. La décision de reconstruire l’équipement, de renouveler les identifiants, de révoquer les sessions ou d’avertir les propriétaires d’applications concernés doit suivre les éléments disponibles et le plan de réponse à incident de l’organisation.

Hygiène de l’identité et des jetons après une exposition possible

Puisque la configuration concernée touche l’autorisation OAuth, les responsables de l’identité doivent participer à la revue. La question pertinente n’est pas seulement de savoir si un mot de passe a été volé. Il faut déterminer si un attaquant a pu influencer le traitement de l’authentification ou de l’autorisation, accéder à des jetons ou modifier les règles qui déterminent qui peut atteindre un service.

Selon le déploiement, les mesures postérieures à la remédiation peuvent inclure la révocation des sessions actives, la rotation des secrets utilisés par les clients OAuth, la revue des clés de signature et des certificats, la vérification des changements d’URI de redirection et d’enregistrement de clients, la validation de la durée de vie des jetons et la comparaison de la configuration du serveur d’autorisation avec une référence approuvée. Ces actions affectent la disponibilité et la confiance ; elles doivent donc être planifiées avec les équipes chargées de l’identité et des applications.

La rotation des jetons n’est pas automatiquement nécessaire dans tous les cas, et une consigne générale consistant à « tout renouveler » peut provoquer une panne évitable. Elle devient plus pertinente lorsqu’il existe des preuves d’accès à l’équipement ou à sa configuration, lorsque des secrets ont pu être lisibles, lorsque du matériel de signature a été exposé ou lorsque l’organisation ne peut pas établir quels objets ont été modifiés. La décision doit être liée aux éléments disponibles et aux hypothèses documentées.

Les propriétaires d’applications doivent savoir quels flux ont pu transiter par le serveur virtuel concerné et quelles vérifications ils doivent mener. Ils peuvent examiner les habitudes de connexion inhabituelles, les événements inattendus de consentement ou d’autorisation, les nouveaux enregistrements de clients, l’utilisation anormale de jetons et les accès provenant de lieux ou de charges de travail ne correspondant pas au comportement habituel. Cela répartit l’enquête entre les systèmes capables d’observer des effets en aval que la passerelle elle-même pourrait ne pas révéler.

Ce que les défenseurs ne doivent pas conclure

Plusieurs raccourcis sont tentants lors d’une réponse rapide à une vulnérabilité. Aucun n’est suffisamment fiable pris isolément.

Un score CVSS élevé ne prouve pas l’exploitation dans un environnement particulier. Dans ce cas, l’exploitation est signalée par le fournisseur, mais l’impact local doit encore être établi par des preuves.

Un résultat de scanner indiquant la présence de BIG-IP ne prouve pas que CVE-2026-94127 s’applique. La condition de configuration est déterminante.

L’absence d’une interface de gestion exposée à Internet ne prouve pas que le serveur virtuel du plan de données est sûr. Le chemin de requête vulnérable est différent.

Un équipement qui utilise OAuth n’a pas automatiquement le rôle vulnérable. Il faut distinguer les fonctions de client, de serveur de ressources et de serveur d’autorisation.

L’installation réussie du correctif ne prouve pas qu’aucun attaquant n’a agi avant la remédiation. Elle ferme une exposition logicielle ; elle n’efface pas l’historique.

Une iRule ou un filtre réseau n’équivaut pas à une version corrigée prise en charge. Les contrôles temporaires peuvent réduire l’exposition pendant la préparation d’une modification urgente, mais ils doivent être validés et associés à un responsable chargé de leur retrait.

Enfin, une seule entrée de journal suspecte ne doit pas être transformée en annonce de compromission. L’approche défendable consiste à la préserver, la corréler, l’enquêter et à communiquer le niveau de confiance du résultat.

Un arbre de décision pratique

Si une organisation n’exécute pas BIG-IP APM, CVE-2026-94127 ne constitue pas une action à mener pour elle, même si les inventaires d’actifs doivent rester exacts.

Si elle exécute BIG-IP mais qu’APM n’est pas provisionné, documentez ce fait et conservez les preuves qui ont permis de l’établir.

Si APM est provisionné mais qu’aucun serveur virtuel concerné ne combine une stratégie d’accès avec un profil de serveur d’autorisation OAuth, consignez la non-exposition fondée sur la configuration et poursuivez les mises à jour habituelles du fournisseur. Revérifiez les systèmes en cours de migration ou de configuration.

Si la configuration vulnérable existe sur une version affectée, priorisez l’équipement selon sa joignabilité et sa dépendance métier, appliquez le correctif du fournisseur dès que la modification peut être exécutée en sécurité et utilisez l’atténuation temporaire prise en charge par le fournisseur si le correctif ne peut pas être installé immédiatement. Lancez en parallèle la préservation des journaux et l’évaluation de compromission.

Si la configuration existe et que des indicateurs sont suspects, passez de la réponse à une vulnérabilité à la réponse à incident. Limitez l’exposition, protégez les preuves, impliquez les responsables de l’identité et des applications et procédez aux changements d’identifiants, de sessions, de jetons ou de clés en fonction des résultats et du plan de réponse.

Si la configuration ne peut pas être établie, traitez le système comme non résolu et non comme sûr. Il peut être nécessaire d’obtenir un export de configuration, d’ouvrir un dossier auprès du support, de soumettre l’équipement à une revue de changement d’urgence ou de limiter temporairement les accès jusqu’à ce que la question soit tranchée.

Pourquoi cet incident dépasse le seul cas F5

CVE-2026-94127 illustre un problème récurrent de la sécurité d’entreprise : l’actif qui ressemble à une appliance réseau peut aussi être un point de contrôle de l’identité. Les programmes classiques de correction organisent généralement le travail par fournisseur, produit, version et gravité. Ces champs sont nécessaires, mais ils peuvent masquer la relation entre un équipement et les décisions de confiance qu’il prend pour d’autres systèmes.

La gestion des vulnérabilités tenant compte de la configuration est plus difficile parce que la réponse est distribuée. L’inventaire logiciel connaît le build. L’inventaire réseau connaît l’adresse. Les équipes identité connaissent le rôle d’autorisation. Les équipes applicatives connaissent le parcours métier. Les opérations de sécurité connaissent la télémétrie disponible. Aucune de ces perspectives ne suffit à elle seule.

L’amélioration durable consiste à rendre ces liens explicites avant la prochaine urgence. Maintenez une cartographie à jour des passerelles d’identité, des serveurs d’autorisation OAuth, des serveurs virtuels, des stratégies d’accès, du matériel de signature, des fournisseurs d’identité en amont, des applications en aval et de leurs propriétaires. Conservez suffisamment de contexte de configuration pour permettre aux intervenants de déterminer l’exposition sans attendre une réunion de crise. Définissez quels journaux sont conservés, pendant combien de temps et qui peut les obtenir lors d’un incident.

La leçon concerne aussi les limites de la formule « corriger puis clôturer ». Pour une vulnérabilité exploitée confirmée sur un équipement de bord privilégié, la remédiation comporte deux livrables : la condition vulnérable est supprimée et l’organisation dispose d’une évaluation raisonnée de ce qui s’est passé avant sa suppression. Le second livrable peut être une évaluation de propreté documentée, un incident confirmé ou une lacune de preuve non résolue nécessitant une surveillance continue. Les trois sont plus utiles qu’un simple numéro de version.

En résumé

CVE-2026-94127 est urgente pour les organisations qui exécutent la configuration BIG-IP APM concernée de serveur d’autorisation OAuth, et non pour tous les clients F5. Confirmez la configuration au niveau du serveur virtuel, identifiez les systèmes et flux d’identité qui en dépendent, limitez les accès inutiles, obtenez le correctif ou l’atténuation temporaire pris en charge par le fournisseur et recherchez l’activité antérieure à la remédiation.

La réponse sereine est précise : trouvez les déploiements de serveurs d’autorisation OAuth, corrigez ceux qui sont concernés, préservez les journaux, vérifiez le plan de contrôle des accès et de l’identité, et ne clôturez le dossier que lorsque les preuves le permettent.

Sources