Une faille vieille de 18 ans frappe le serveur web open-source NGINX. Des chercheurs de la société de sécurité DepthFirst AI l’ont repérée grâce à un système de scan autonome. Les attaquants exploitent cette vulnérabilité pour des attaques de déni de service. Dans certains cas, elle mène à une exécution de code à distance.
Les experts cataloguent la faille sous le nom CVE-2026-42945. Elle obtient un score de gravité critique de 9,2 selon la version récente du système CVSS.
Les chercheurs ont débusqué trois autres problèmes de corruption mémoire durant la même session de scan de six heures.
NGINX équipe un tiers des sites web les plus visités. Ce serveur web et proxy inverse répartit les flux réseau vers plusieurs serveurs backend. Il accélère les chargements en mettant en cache les contenus. La société américaine F5 détient et maintient le projet. Les fournisseurs cloud, entreprises SaaS, banques, plateformes médias, sites e-commerce et clusters Kubernetes l’utilisent.
La référence CVE-2026-42945 désigne un débordement de tampon dans le tas du module ngx_http_rewrite_module. Elle touche les versions de NGINX de 0.6.27 à 1.30.0. Le code porte cette faille depuis environ 18 ans.
DepthFirst AI précise que les configurations NGINX combinent souvent les directives ‘rewrite’ et ‘set’. Ce schéma domine dans les passerelles API et setups de proxy inverse. L’origine réside dans une gestion incohérente des états dans le moteur de scripts interne de NGINX. Ce moteur traite les réécritures en deux étapes : il évalue d’abord la mémoire à allouer, puis copie les données.
Un drapeau ‘is_args’ reste actif après une réécriture avec ‘?’. NGINX calcule alors la taille du tampon sur des longueurs d’URI non échappées. Plus tard, il inscrit des données échappées plus volumineuses, comme ‘+’ et ‘&’. Ce processus provoque le débordement.
Les chercheurs ont prouvé une exécution de code sans authentification. Ils ont forgé des requêtes HTTP spéciales qui corrompent les structures de mémoire adjacentes de NGINX. Ces requêtes écrasent les pointeurs de gestionnaires de nettoyage. Elles pulvérisent de fausses structures en mémoire via des corps de requêtes POST. Elles obligent NGINX à lancer la fonction ‘system()’ au moment du nettoyage des piscines mémoire.
Cette exécution de code à distance nécessite que la protection ASLR soit désactivée sur le système. Cette mesure contre les attaques mémoire s’active par défaut. On la désactive parfois pour booster les performances dans les systèmes embarqués ou machines virtuelles d’analyse.
L’architecture multi-processus de NGINX facilite l’exploitation. Les processus workers héritent de dispositions mémoire quasi identiques du processus maître. Cela permet une manipulation fiable du tas et des essais répétés si un worker plante.
Les chercheurs expliquent : le processus maître relance un nouveau worker avec la même disposition mémoire si l’exploit échoue et cause un crash. Cela offre plusieurs tentatives sans altérer la disposition mémoire. En théorie, on contourne l’ASLR en écrasant les pointeurs octet par octet.
Les trois autres failles obtiennent une gravité moyenne :
- CVE-2026-42946 — allocation mémoire excessive dans les modules SCGI/UWSGI qui crashent les workers avec ~1 To d’allocation (gravité élevée)
- CVE-2026-40701 — utilisation après libération dans la gestion asynchrone de résolution DNS OCSP (gravité moyenne)
- CVE-2026-42934 — erreur d’une unité dans l’analyse UTF-8 qui provoque des lectures hors limites (gravité moyenne)
Impact et correctifs
Les chercheurs ont découvert les failles le 18 avril 2026. Ils les ont signalées au vendeur le 21 avril.
L’avis de sécurité de F5, publié hier, liste les versions NGINX touchées :
- NGINX Open Source de 0.6.27 à 1.30.0
- NGINX Plus R32 à R36
- NGINX Instance Manager 2.16.0 à 2.21.1
- F5 WAF pour NGINX 5.9.0 à 5.12.1
- NGINX App Protect WAF 4.9.0 à 4.16.0 et 5.1.0 à 5.8.0
- F5 DoS pour NGINX 4.8.0
- NGINX App Protect DoS 4.3.0 à 4.7.0
- NGINX Gateway Fabric 1.3.0 à 1.6.2 et 2.0.0 à 2.5.1
- NGINX Ingress Controller 3.5.0 à 3.7.2, 4.0.0 à 4.0.1, et 5.0.0 à 5.4.1
F5 fournit les correctifs dans NGINX Open Source 1.31.0 et 1.30.1, NGINX Plus R36 P4, et NGINX Plus R32 P6.
Pour ceux qui ne mettent pas à jour, F5 conseille de remplacer les groupes de capture PCRE anonymes ($1, $2, etc.) par des captures nommées dans les règles ‘rewrite’ vulnérables. Cette mesure supprime le prérequis principal d’exploitation.
Exploitabilité dans le monde réel
Certains chercheurs contestent la faisabilité réelle autour de CVE-2026-42945. Ils jugent que la preuve de concept de DepthFirst AI repose sur des conditions rares en déploiements standards.
Kevin Beaumont souligne que l’exploitation exige une configuration NGINX vulnérable avec des motifs rewrite spécifiques. L’attaquant doit connaître ou trouver l’extrémité affectée. La preuve de concept RCE s’est testée avec l’ASLR désactivée.
Beaumont insiste : les chercheurs ont bâti leur exploit sur un setup délibérément vulnérable. Il ne prouve pas d’exécution fiable sur systèmes renforcés réels.
AlmaLinux confirme cette analyse après reproduction indépendante de la faille.
Les mainteneurs de cette distribution Linux valident que planter les processus workers NGINX via une requête forgée reste simple et fiable. Les attaques de déni de service deviennent réalistes.
Cependant, ils précisent que transformer le débordement en exécution de code à distance fiable sur systèmes avec ASLR activé ne s’avère pas simple. Ils doutent d’un exploit générique et fiable issu des travaux de DepthFirst AI.
AlmaLinux avertit que ‘pas simple’ n’équivaut pas à impossible. Le potentiel DoS suffit pour qualifier la faille d’urgente.