NGINX visé par le CERT-FR : une faille du moteur njs expose au déni de service et à l'exécution de code

Le CERT-FR a publié le 20 mai 2026 l'avis CERTFR-2026-AVI-0619, qui documente une vulnérabilité critique dans F5 NGINX. Derrière une alerte technique de routine se cache une question que tout DPO connaît désormais : à partir de quand un bulletin de sécurité devient-il une obligation RGPD ?

Ce qui s'est passé

L'avis du CERT-FR vise le module NGINX JavaScript, plus connu sous le nom de njs, dans ses versions 0.9.4 à 0.9.8 — l'éditeur étant F5, propriétaire de NGINX. La faille est référencée sous l'identifiant CVE-2026-8711.

Le scénario d'attaque est simple, et c'est ce qui le rend préoccupant. Un attaquant non authentifié — donc sans identifiant ni accès préalable — peut envoyer des requêtes HTTP spécialement forgées qui provoquent un dépassement de tampon (heap buffer overflow) dans le processus de travail de NGINX. Le serveur redémarre alors brutalement : c'est un déni de service. Et sur les systèmes où la randomisation de l'espace d'adressage (ASLR) est désactivée, le même mécanisme peut aller plus loin et permettre l'exécution de code arbitraire. L'éditeur a corrigé la faille dans la version 0.9.9 de njs.

NGINX n'est pas un logiciel anodin : il fait tourner une part considérable des sites les plus fréquentés du web, comme serveur, comme reverse proxy ou comme répartiteur de charge. Le module njs, lui, permet de scripter le comportement de NGINX en JavaScript. Toutes les installations ne l'utilisent pas — mais celles qui l'activent l'exposent en première ligne de leur infrastructure.

Pourquoi c'est important

Un avis de vulnérabilité n'est pas, en soi, un événement juridique. Il le devient dès lors qu'un serveur concerné traite des données personnelles. C'est précisément le moment où l'article 32 du RGPD s'active : le responsable de traitement doit mettre en œuvre des « mesures techniques et organisationnelles appropriées » pour garantir la sécurité des données — et la gestion des correctifs en fait partie intégrante. Ce n'est pas une bonne pratique optionnelle, c'est une obligation. Notre guide sur la sécurité des données détaille comment structurer cette démarche au quotidien.

La directive NIS 2 ajoute une couche pour les entités régulées : elles doivent disposer d'un processus formalisé de gestion des vulnérabilités et notifier l'ANSSI d'un incident significatif sous 24 heures. Et si la faille venait à être exploitée et que des données personnelles étaient compromises, l'article 33 du RGPD impose la notification de la violation à la CNIL dans les 72 heures.

La position de NGINX dans l'architecture aggrave l'enjeu. En tant que reverse proxy, il voit passer l'ensemble du trafic d'une organisation. Une exécution de code sur ce composant n'est donc pas un incident périphérique : elle expose potentiellement tout ce qui se trouve derrière. C'est le même schéma que Leto a documenté ces dernières semaines pour les avis CERT-FR concernant Apache HTTP Server ou Nextcloud — la brique d'infrastructure compromise devient le point d'entrée vers la donnée.

Ce que ça change pour les organisations

La marche à suivre tient en quelques actions concrètes, à enclencher sans attendre.

D'abord, inventorier : quelles instances NGINX sont déployées, lesquelles utilisent le module njs, et dans quelle version ? Seules les versions 0.9.4 à 0.9.8 sont concernées. Ensuite, appliquer le correctif en passant à njs 0.9.9. Si le déploiement du patch ne peut pas être immédiat, vérifier que l'ASLR est bien activée — c'est le cas par défaut sur la plupart des systèmes modernes — limite le risque au déni de service plutôt qu'à l'exécution de code. Ce n'est qu'une mesure transitoire, pas un substitut au correctif.

Il faut aussi documenter la décision : l'évaluation du risque, le calendrier de patching retenu et sa justification constituent la preuve d'accountability que l'article 32 et l'article 24 du RGPD exigent. Enfin, analyser les journaux à la recherche de redémarrages anormaux des processus de travail NGINX, signes d'une tentative d'exploitation. Pour les entités soumises à NIS 2, cet avis doit simplement s'intégrer au processus de gestion des vulnérabilités déjà en place. Si une exploitation est avérée, le réflexe à connaître est balisé dans notre guide sur la réaction à une violation de données.

Ce que Leto pense de cette décision

Le caractère répétitif de ces avis est, en lui-même, le vrai message. Un bulletin du CERT-FR n'est plus un événement exceptionnel : c'est une routine hebdomadaire. Ce que la CNIL appréciera, en cas de violation, n'est pas de savoir si vous aviez connaissance de telle faille précise — mais si vous disposiez d'un processus capable de la détecter, de l'évaluer et de la traiter dans un délai raisonnable. Le DPO qui traite chaque avis comme une urgence isolée a déjà un train de retard. L'enjeu n'est pas de patcher njs 0.9.9 cette semaine : c'est de construire, une bonne fois, la chaîne de gestion des vulnérabilités qui rendra le prochain avis CERT-FR non pas anxiogène, mais simplement administratif.

Sources : CERT-FR — Avis CERTFR-2026-AVI-0619 · F5 — Bulletin de sécurité njs (CVE-2026-8711) · Vulnerability-Lookup — CERTFR-2026-AVI-0619