Le 15 juillet 2026, F5 a corrigé une faille de sécurité critique dans NGINX : la CVE-2026-42533, un dépassement de tampon. Cette vulnérabilité présente dans NGINX depuis 2011 permet à un attaquant distant non authentifié de faire planter les processus workers du serveur Web, via de simples requêtes HTTP. Dans le pire des cas, une exécution de code à distance est également envisageable. Voici ce que l’on sait.

CVE-2026-42533 : une faille critique dans NGINX

Cette nouvelle faille de sécurité, associée à la référence CVE-2026-42533 et à un score v4.0 de 9.2 sur 10 (soit une faille critique), est exploitable par un attaquant distant et non authentifié à l’aide de requêtes HTTP spécialement forgées. La faille se situe dans le moteur de scripts de NGINX, la partie du code qui assemble des chaînes de caractères à partir des directives, au moment du traitement de la requête.

La CVE-2026-42533 est directement liée à la directive map, comme l’explique F5 dans son bulletin de sécurité : “Une vulnérabilité existe dans NGINX Plus et NGINX Open Source lorsqu’une directive map utilise la correspondance par expression régulière et qu’une expression de chaîne fait référence aux variables de capture de l’expression régulière de la directive map avant de faire référence à la variable de sortie de celle-ci.” – Cela signifie que tous les serveurs NGINX ne sont pas vulnérables : cela dépend de la version installée, mais aussi de la configuration (plus précisément de l’usage de avec des regex).

Essayons de bien comprendre quel est le problème avec cette faille de sécurité.

Pour assembler une chaîne de caractères, NGINX procède en deux temps. Il mesure d’abord la place nécessaire, puis réserve un tampon (une zone mémoire) à cette taille exacte. Ensuite seulement, il y recopie les données. Imaginez une boîte taillée aux dimensions d’un premier objet, dans laquelle on tente ensuite d’en glisser un second, plus volumineux : le contenu déborde. C’est ce qui se produit ici. Entre l’étape de calcul et la recopie des données, l’évaluation de l’expression régulière du vient modifier la capture qui sert de référence (par exemple ). Le tampon est donc taillé pour la capture d’origine, mais rempli à partir d’une autre, dont la taille et le contenu sont dictés par la requête de l’attaquant. Le contenant est trop petit, et le débordement provoqué engendre l’écriture de données arbitraires dans la mémoire du processus.

DoS confirmé, exécution de code : jusqu’où va vraiment la menace ?

Dans son bulletin de sécurité, F5 associe cette vulnérabilité à un déni de service : le débordement fait planter ou fait redémarrer le worker, ce qui perturbe la disponibilité du service Web. Et puis, F5 mentionne aussi la possibilité d’exécuter du code à distance sur un serveur vulnérable, via cette faille, mais à une condition : la protection ASLR doit être désactivée ou contournable.

Toutefois, l’un des chercheurs ayant signalé la faille, Stan Shaw va plus loin. Il a publié un rapport et il affirme clairement que cette faille elle-même permettrait le contournement de l’ASLR. Ceci permettrait donc d’exécuter du code à distance sur un serveur vulnérable.

“L’absence de sauvegarde/restauration de l’état de capture PCRE dans le moteur de script d’Nginx permet à un attaquant distant non authentifié de déclencher un débordement de tampon de la mémoire dynamique (heap) dont le contenu et la longueur sont entièrement contrôlés, ainsi qu’une fuite d’informations sur les pointeurs de la mémoire dynamique suffisante pour contourner l’ASLR. Ces deux vulnérabilités s’enchaînent pour permettre l’exécution de code à distance fiable avant authentification.”, peut-on lire sur son site web.

La raison : l’écrasement fonctionnerait aussi dans l’autre sens. Lorsque la capture écrasée est plus petite que l’originale, le tampon surdimensionné restituerait des données non initialisées du tas. “Ce bug ne nécessite pas que l’ASLR soit désactivé. La technique de fuite d’informations le contourne en une seule requête GET.”, précise son rapport. Il indique également qu’il n’a pas publié l’exploit PoC pour laisser le temps aux utilisateurs de se protéger.

Comment se protéger ?

D’après le bulletin de sécurité publié par NGINX, toutes les versions de à sont vulnérables à cette faille de sécurité. Cela fait beaucoup de versions puisqu’il s’agit des versions actuelles et celles qui remontent à 2011, année où la directive a commencé à prendre en charge les expressions régulières.

Les correctifs de sécurité ont été intégrés aux nouvelles versions, à savoir :

• NGINX (branche stable),
• NGINX (branche mainline),
• NGINX Plus .

Selon F5, la faille affecte aussi NGINX Ingress Controller, Gateway Fabric, App Protect et Instance Manager, avec des correctifs déployés de façon progressive. À l’inverse, BIG-IP, BIG-IQ, F5 Distributed Cloud, F5OS et F5 AI Gateway ne seraient pas concernés.

L’installation du correctif de sécurité est recommandée pour se protéger. En complément, sache que le chercheur Stan Shaw a publié un scanner qui analyse les fichiers de configuration de votre NGINX pour voir si votre serveur est vulnérable ou non. L’idée étant de regarder comment sont écrites vos règles .

Cette nouvelle faille critique dans NGINX succède à la vulnérabilité NGINX Rift (CVE-2026-42945) découverte en mai. Un serveur Web reste une cible de choix : ces dernières semaines, NGINX a aussi été visé par l’attaque HTTP/2 Bomb, capable de saturer la mémoire de la machine cible (bien que pas limitée à NGINX).