Un système alimenté par LLM a trouvé 4 bugs de sécurité, dont un critique dans le module de réécriture d’URL du serveur Web.
Les chercheurs ont découvert une vulnérabilité critique dans le serveur Web Nginx, largement utilisé, qui peut potentiellement conduire à l’exécution de code à distance dans certaines conditions. La faille est un débordement de tampon de tas qui n’a pas été détecté dans le code du programme au cours des 18 dernières années.
Suivie sous le numéro CVE-2026-42945, la vulnérabilité est l’un des quatre bogues trouvés dans Nginx par des chercheurs de la startup de sécurité DepthFirst AI, à l’aide de leur plate-forme alimentée par LLM. Cela s’ajoute au nombre croissant de failles que les scanners de sécurité et les humains ont manquées dans des projets open source de grande envergure au fil des années, mais qui ont été découvertes à l’aide de modèles d’IA ces derniers mois.
Nginx est l’un des serveurs Web les plus populaires, alimentant près d’un tiers de tous les sites Web sur Internet, et est également intégré à de nombreux produits commerciaux. Le logiciel est également couramment utilisé comme proxy inverse, équilibreur de charge et cache pour d’autres applications et serveurs Web.
La vulnérabilité CVE-2026-42945 est localisée dans , un composant qui gère les réécritures d’URL et affecte les versions de Nginx de 0.6.27 à 1.30.0. Le problème a reçu un score de gravité CVSS de 9,2 et a été corrigé dans les versions 1.31.0 et 1.30.1.
Le produit commercial, Nginx Plus, détenu et développé par la société de sécurité des réseaux et des applications F5, est également vulnérable et a reçu des correctifs dans les versions R36 P4, R32 P6 et 37.0.0. D’autres produits F5 basés sur l’open source Nginx et Nginx Plus sont concernés, mais n’ont pas encore reçu de mises à jour, notamment Nginx Instance Manager, F5 WAF pour Nginx, Nginx App Protect WAF, F5 DoS pour Nginx, Nginx App Protect DoS, Nginx Gateway Fabric et Nginx Ingress Controller.
« Cette vulnérabilité existe lorsque la directive rewrite est suivie d’une directive rewrite, if ou set et d’une capture d’expression régulière compatible Perl (PCRE) sans nom (par exemple, $1, $2) avec une chaîne de remplacement qui inclut un point d’interrogation (?) », a déclaré F5 dans son avis. Selon la société, l’exploitation entraînera un déni de service sous la forme d’un crash du serveur et, sur les systèmes sur lesquels la randomisation de la disposition de l’espace d’adressage (ASLR) est désactivée, l’exécution de code arbitraire.
Réaliser le RCE
Bien que l’exploit de preuve de concept (PoC) développé par DepthFirst et partagé avec F5 n’inclue pas de contournement ASLR, les chercheurs pensent qu’il est possible d’en réaliser un. ASLR est une technologie d’atténuation des exploits de corruption de mémoire présente et activée par défaut dans la plupart des systèmes d’exploitation modernes.
« Nginx utilise une architecture multi-processus dans laquelle les processus de travail dérivent d’un seul processus maître », a déclaré Zhenpeng Lin, chercheur à DepthFirst, dans un article de blog. « En raison de cette conception, l’espace mémoire est dupliqué exactement pour chaque travailleur enfant. Cela signifie que la disposition du tas reste entièrement déterministe entre les différents travailleurs. Si notre exploit échoue et fait planter un travailleur, le processus maître en génère simplement un nouveau avec exactement la même disposition de mémoire. Cela nous permet d’essayer en toute sécurité plusieurs fois jusqu’à ce que nous réussissions sans nous soucier du crash du travailleur et de la modification de la disposition de la mémoire. Théoriquement, nous pourrions exploiter cette conception pour fuir l’ASLR en écrasant progressivement les pointeurs octet par octet. «
Les chercheurs pensent également que les configurations Nginx requises pour exploiter cette vulnérabilité sont courantes. Par exemple, les règles de réécriture d’URL sont souvent utilisées lors de la migration des points de terminaison des API vers de nouveaux emplacements sans provoquer de perturbations pour les clients externes qui tentent toujours d’interroger l’ancienne URL. La directive set peut être utilisée pour stocker le chemin d’origine, ou des parties de celui-ci, dans une variable personnalisée pour conserver l’état, acheminer les points de terminaison de manière dynamique ou pour le transmettre à l’application backend à des fins d’audit et de journalisation.
« Ensemble, ces deux directives constituent des éléments de base communs dans les configurations de passerelle API », a déclaré Lin.
Depuis que l’exploit de validation de principe a été publié sur GitHub, il est conseillé aux utilisateurs de mettre à niveau vers une version corrigée dès que possible, car les vulnérabilités de Nginx ont été exploitées par des attaquants dans le passé. Le déni de service constitue à lui seul un risque sérieux pour les serveurs Web, même sans le contournement ASLR proposé par les chercheurs.
Les trois autres vulnérabilités divulguées par DepthFirst et corrigées dans les nouvelles versions de Nginx peuvent également conduire à un déni de service, des fuites de mémoire ou une modification des données. Ils sont suivis sous les noms CVE-2026-42946 (CVSS 8.3 – gravité élevée), CVE-2026-42934 (CVSS 6.3 – moyenne) et CVE-2026-40701 (CVSS 6.3 – moyenne).
