if ( !emtpy($headline_subheadline ) ) : ?>
Les trois nouvelles failles NGINX ne sont pas encore connues pour être exploitées, mais pourraient exposer les systèmes à des plantages, des déni de service et une potentielle exécution de code.
endif; ?>
F5 révèle une fois de plus des failles de cybersécurité dans ses offres principales.
Le fournisseur de fourniture d’applications et de sécurité a publié des correctifs de sécurité hors bande (OOB) qui corrigent plusieurs failles de NGINX, son logiciel hautes performances qui contrôle le trafic numérique des sites Web. Il s’agit notamment de trois failles de gravité critique qui pourraient permettre aux attaquants de planter des systèmes, d’exécuter du code et de lancer des attaques par déni de service (DoS).
Les correctifs de sécurité OOB sont des mises à jour logicielles d’urgence publiées en dehors des cycles de maintenance normaux.
CVE-2026-15176, CVE-2026-97205 et CVE-2026-93479 ont une gravité de 9,2 dans la dernière version (4.0) du Common Vulnerability Scoring System (CVSS). Les produits logiciels concernés incluent NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric et NGINX Instance Manager.
Bien que F5 affirme n’avoir découvert aucune preuve que ces problèmes sont exploités dans la nature, il conseille aux clients d’installer ou de mettre à niveau vers des versions corrigées. Les analystes sont d’accord.
« NGINX est la porte d’entrée : proxy inverse, équilibreur de charge et entrée Kubernetes », a déclaré Frank Dickson de Dickson Research, notant que la sécurité de la couche de transport (TLS) se termine généralement dans NGINX. « L’exécution de code sur cette boîte signifie voir les mots de passe, les cookies de session et les jetons API en clair, ainsi que les clés privées qui rendent le tout digne de confiance. »
Permettre aux attaquants de faire planter les systèmes
CVE-2026-15176 et CVE-2026-97205 sont des vulnérabilités dans NGINX de F5, qui pourraient provoquer un débordement de tampon de tas dans le processus de travail du serveur. Ce type de corruption de la mémoire pourrait entraîner une panne ou un redémarrage du système, donnant ainsi accès aux attaquants. Les acteurs malveillants pourraient également exécuter du code sur des systèmes dotés de l’ASLR (Address Space Layout Randomization), une technique destinée à empêcher l’exploitation en organisant de manière aléatoire les emplacements de mémoire lorsqu’une application démarre, est désactivée ou contourne complètement l’ASLR. Ces failles pourraient permettre aux attaquants de lancer des attaques DoS pour rendre le serveur inaccessible aux utilisateurs légitimes, a expliqué F5.
CVE-2026-93479 est similaire, dans le sens où il s’agit d’une faille de directive map qui pourrait permettre à des attaquants d’envoyer des requêtes HTTP contrefaites pour provoquer un débordement de tampon de tas ; ils peuvent également exécuter du code lorsque l’ASLR est désactivé ou le contourner.
Ces vulnérabilités font suite à la divulgation par F5 de CVE-2026-42530 en juin. La faille dans NGINX Open Source pourrait également potentiellement permettre à des attaquants distants de provoquer un DoS ou de déclencher l’exécution de code.
Les clients peuvent atténuer CVE-2026-15176 en évitant l’utilisation de la variable et de la directive dans un bloc d’emplacement, a déclaré F5, et CVE-2026-97205 peut être atténué en désactivant les E/S de fichiers asynchrones (AIO) et les inclusions côté serveur (SSI).
Pendant ce temps, F5 a conseillé d’atténuer CVE-2026-93479 en évitant les captures sans nom et en utilisant plutôt des captures nommées et en limitant leur utilisation au bloc avec la correspondance d’expression régulière.
Mais, a noté Seva Ioussoufovitch, analyste de recherche senior chez Infotech, « étant donné que NGINX est utilisé sur un large éventail de systèmes, cela peut augmenter le risque de perte de disponibilité des services pour de nombreuses entreprises ».
Le dernier d’une série de problèmes de cybersécurité
Bien que ces trois vulnérabilités ne soient pas connues pour être exploitées à l’état sauvage, F5 a subi à plusieurs reprises le poids des cyberattaques ces dernières années, ce qui est inquiétant car la société de cybersécurité et de mise en réseau de distribution d’applications (ADN) sert des dizaines de milliers de clients, dont 80 % des sociétés Fortune 500, ont noté les analystes.
Les acteurs malveillants ont ciblé à plusieurs reprises les failles de ses systèmes et produits pour cartographier les serveurs internes, détourner des appareils, violer les systèmes, voler des documents sensibles et déployer des logiciels malveillants pour effacer les données. Au cours des cinq dernières années, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a signalé huit vulnérabilités F5 activement exploitées ; quatre d’entre eux ont été la cible d’attaques de ransomware.
Par exemple, une violation d’un État-nation en 2025 et la directive d’urgence 26-01 de la CISA étaient centrées sur le BIG-IP de F5, et F5 avait déclaré à l’époque que le code source de NGINX n’avait pas été consulté. Mais, a noté Dickson, le « coup d’avertissement » de NGINX est arrivé en mai lorsque CVE-2026-42945, un débordement de module de réécriture surnommé NGINX Rift, est arrivé avec une preuve de concept publique d’exécution de code à distance.
« La faille d’alias et de réécriture de cette semaine réside dans le même quartier », a-t-il déclaré, soulignant que « les attaquants lisent également les journaux des modifications ».
Atténuation
Ioussoufovitch a noté que les failles dépendent de la configuration, les entreprises devraient donc commencer par un audit des configurations NGINX actuelles pour aider à hiérarchiser les risques de ce correctif. F5 a également déclaré que le risque d’exécution de code à distance (RCE) augmente considérablement lorsque l’ASLR est désactivé, les utilisateurs doivent donc vérifier que l’ASLR et d’autres protections typiques au niveau du système d’exploitation sont activées de manière proactive pour au moins limiter le risque d’exploitation de types d’attaque similaires.
Les entreprises doivent s’assurer qu’elles disposent d’un inventaire clair des systèmes qui exécutent NGINX, y compris ceux sur lesquels il est intégré dans d’autres produits. Ceci est essentiel pour prendre en charge les audits de configuration, les efforts de segmentation et les efforts de surveillance des travailleurs NGINX, qui peuvent indiquer que les attaquants « exploitent ce type de vulnérabilités », a déclaré Ioussoufovitch.
« NGINX a déjà eu plusieurs versions de sécurité cette année, et je m’attends à ce que cette tendance se poursuive dans le futur », a-t-il noté.
Dickson a convenu que l’inventaire est la première étape. NGINX « se cache à l’intérieur » des contrôleurs d’entrée, des appareils et des images de conteneurs. De nombreuses équipes obtiennent NGINX à partir de leur distribution Linux, et non de nginx.org, et Amazon Linux répertorie toujours le correctif AIO comme en attente.
« Un correctif sur le site du fournisseur ne corrige pas vos serveurs », a-t-il prévenu.
En plus d’effectuer l’inventaire, les entreprises doivent rechercher dans leurs configurations des alias associés à la réécriture, des AIO associés à SSI et mapper des blocs à l’aide de captures d’expressions régulières sans nom.
Si une organisation ne peut pas appliquer de correctif aujourd’hui, les solutions de contournement sont simples, a déclaré Dickson : désactivez AIO ou arrêtez de servir les pages SSI ; basculer la carte vers les captures nommées ; confirmez que l’ASLR est activé, exécutez les travailleurs sans privilèges ; et segmentez la porte d’entrée afin qu’elle ne puisse pas atteindre les joyaux de la couronne. Et surveillez les processus de travail qui redémarrent sans cesse.
« Ces failles nécessitent la bonne configuration pour être détectées, et c’est une bonne nouvelle », a déclaré Dickson. « La mauvaise nouvelle est que de nombreuses organisations ne savent peut-être pas ce que disent réellement leurs configurations NGINX. »
