Table des matières de l'article :
Le 9 juin 2026, Nebula Security publiait sur X un message qui allait susciter des discussions au sein de toute la communauté des systèmes et de la sécurité : selon l’équipe, une nouvelle vulnérabilité d’exécution de code à distance dans NGINX avait été signalée à F5, accompagnée d’un correctif proposé, mais après environ deux semaines, aucune réponse officielle n’était encore arrivée.
Le document est disponible à cette adresse : https://x.com/nebusecurity/status/2064209727538745734Cela est particulièrement pertinent car cela survient à un moment déjà très délicat pour NGINX. En effet, au cours des semaines précédentes, le projet avait déjà dû faire face à d'importantes vulnérabilités dans le module. ngx_http_rewrite_module, y compris CVE-2026-42945, connu publiquement sous le nom de NGINX Rift, et CVE-2026-9256, surnommé nginx-poolslip.
https://x.com/nebusecurity/status/2064209727538745734
Ce nouveau rapport doit cependant être traité différemment des CVE déjà connues : pour l’instant, aucune CVE n’a été attribuée, aucun avis public de F5/NGINX n’a été publié et aucun correctif officiel n’est disponible . Cela signifie que nous ne disposons pas encore d’informations suffisantes pour parler de versions définitivement vulnérables, de conditions d’exploitation spécifiques, de configurations affectées ou de solutions de contournement validées par le fournisseur.
Autrement dit, nous nous trouvons dans une phase intermédiaire délicate : suffisamment d’informations pour s’inquiéter, mais pas assez pour clore techniquement le dossier par une simple commande de mise à jour.
Voici ce qu'a déclaré Nebula Security
Dans le message publié sur X, Nebula Security indique avoir signalé une autre exécution de code à distance (RCE) dans NGINX à F5 environ deux semaines auparavant, et avoir proposé un correctif. Le point crucial de cette communication est l'absence de réponse du fournisseur, du moins d'après les déclarations publiques de l'équipe de recherche.
Nebula précise également que la vulnérabilité ne dépend pas d'une configuration « inhabituelle » . Ce détail est important : souvent, lorsqu'une vulnérabilité requiert une combinaison spécifique de directives ou de paramètres, on a tendance à minimiser le risque en arguant qu'il s'agit d'une configuration rare ou irréaliste. Nebula conteste précisément cette hypothèse, en soulignant que dans la réalité, les configurations NGINX sont extrêmement variées, souvent superposées au fil du temps et rarement publiques.
Voici la traduction italienne :
D'après leur analyse préliminaire, un nombre important de déploiements concrets sont concernés, y compris des entreprises du classement Fortune Global 500. Cette affirmation doit toutefois être interprétée avec prudence : en l'absence d'un avis technique complet, nous ne pouvons vérifier les détails de manière indépendante. Néanmoins, le simple fait qu'un groupe de recherche ait décidé de rendre publiques ses pressions sur le fournisseur témoigne de la gravité du problème.
Pourquoi une exécution de code à distance (RCE) dans NGINX est une information capitale
NGINX n'est pas un logiciel marginal. C'est l'un des serveurs web et proxys inverses les plus utilisés au monde, présent sur les serveurs physiques, les VPS, les conteneurs, les appliances, les contrôleurs d'entrée Kubernetes, les chargeurs d'applications, les environnements Plesk, cPanel, les architectures personnalisées et les infrastructures cloud. Dans de nombreux cas, il est le premier composant à recevoir le trafic HTTP et HTTPS provenant de l'extérieur.
Une vulnérabilité d'exécution de code à distance (RCE) dans un composant frontalier comme NGINX présente un profil de risque très différent de celui d'une vulnérabilité locale ou d'un bug dans un service interne. Si elle est exploitable sans authentification et accessible via HTTP, elle pourrait théoriquement permettre à un attaquant distant d'exécuter du code dans le contexte du processus worker NGINX.
Il convient de préciser que l'exécution de code en tant qu'utilisateur NGINX n'équivaut pas nécessairement à l'obtention des privilèges root. NGINX, lorsqu'il est correctement configuré, exécute les workers en tant qu'utilisateur non privilégié, tel que… nginx, www-data ou similaire. Cependant, à partir de ce moment, un attaquant pourrait toujours lire les fichiers accessibles au processus, interagir avec les systèmes internes, se déplacer latéralement, tenter des élévations de privilèges locales ou exploiter les sockets, les identifiants, les configurations ou les secrets présents sur le système.
Dans un scénario d'hébergement ou de proxy inverse, même une compromission limitée peut avoir des conséquences importantes, surtout si le serveur gère plusieurs hôtes virtuels, transfère le trafic vers des backends privés ou contient des configurations avec des informations sensibles.
Contexte : NGINX Rift et nginx-poolslip
Pour comprendre la sensibilité du moment, il faut tenir compte du contexte. En mai 2026, NGINX a publié des mises à jour pour plusieurs vulnérabilités, notamment CVE-2026-42945, un dépassement de tampon de tas dans le module ngx_http_rewrite_moduleLa page officielle d'avis de sécurité de NGINX indique que les versions non vulnérables à la CVE-2026-42945 sont 1.31.0 e 1.30.1, tandis que les versions de sont vulnérables 0.6.27 1.30.0 à.
La vulnérabilité CVE-2026-9256 , un autre dépassement de tampon dans le module de réécriture, est apparue peu après . Dans ce cas, la page officielle de NGINX indique que les versions 1.31.1+ et 1.30.2+ ne sont pas vulnérables , tandis que les versions jusqu'à 1.31.0 le sont . Les notes de version de NGINX 1.30.2 mentionnent explicitement un dépassement de tampon de mémoire du tas dans le processus worker lors de l'utilisation d'une configuration avec des captures chevauchantes dans le module de réécriture, ce qui peut potentiellement permettre l'exécution de code arbitraire.
Ces deux cas ont déjà été identifiés, documentés et corrigés. Le nouveau rapport de Nebula Security semble toutefois concerner un cas distinct : nous ne disposons toujours pas d’un nom officiel, d’un identifiant CVE ni d’une page F5 permettant de déterminer précisément s’il est lié aux failles précédentes et, le cas échéant, de quelle manière.
Le problème du manque de CVE et de conseils
Lorsqu'une vulnérabilité n'a pas encore de CVE et qu'aucun avis officiel n'est publié, les administrateurs se trouvent face à un dilemme. D'une part, ils ne peuvent ignorer le signalement, surtout s'il provient d'un chercheur ou d'une équipe ayant une expérience produit. D'autre part, ils ne peuvent ni appliquer un correctif inexistant, ni confirmer l'exposition à l'aide d'un scanner fiable.
Il est important de ne pas confondre trois niveaux différents :
- les CVE déjà connues et corrigées, comme CVE-2026-42945 et CVE-2026-9256 ;
- le nouveau rapport public de Nebula Security, qui ne dispose actuellement d'aucune CVE ni d'aucun avis officiel ;
- les hypothèses opérationnelles que peut prendre un administrateur pour réduire les risques en attendant plus de détails.
Une erreur fréquente serait de dire : « J’ai mis à jour NGINX vers la version 1.30.2 ou 1.31.1, je suis donc forcément protégé contre cette nouvelle exécution de code à distance. » Ce n’est pas le cas. Ces versions corrigent les vulnérabilités connues et publiées, mais elles ne corrigent pas nécessairement la nouvelle vulnérabilité signalée par Nebula, à moins que F5/NGINX ne la confirme ultérieurement.
Que faire maintenant : inventaire des versions de NGINX
La première étape consiste à identifier précisément les instances NGINX présentes dans votre infrastructure. Dans de nombreux environnements, le problème ne se limite pas au serveur principal, mais concerne également les images de conteneurs, les contrôleurs d'entrée, les proxys inverses internes, les appliances, les systèmes existants et les installations personnalisées.
nginx -v 2>&1
nginx -V 2>&1
Sur les systèmes basés sur RPM tels qu'AlmaLinux, Rocky Linux, RHEL et CentOS :
rpm -qa | grep -E '^nginx|nginx-' | sort
dnf list installed | grep nginx
Sur Debian et Ubuntu :
dpkg -l | grep nginx
apt-cache policy nginx
Dans les environnements conteneurisés :
docker ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
podman ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
kubectl get pods -A | grep -i nginx
kubectl get ingressclass -A
Cet inventaire est crucial car de nombreuses organisations mettent à jour leur package NGINX OS mais oublient les images Docker, les graphiques Helm, les contrôleurs d'entrée ou les builds personnalisés.
Veuillez corriger toute vulnérabilité connue.
Même si la nouvelle vulnérabilité d'exécution de code à distance signalée par Nebula ne dispose pas encore d'un correctif public, il ne faut pas prendre de retard. Au contraire, vous devez vous assurer d'avoir déjà corrigé les vulnérabilités connues.
Pour NGINX Open Source compilé ou installé à partir des dépôts officiels NGINX, la cible minimale pour les CVE connues de mai 2026 est d'avoir au moins une version qui inclut des correctifs pour CVE-2026-42945 et CVE-2026-9256, donc 1.30.2 sur la branche stable ou 1.31.1 sur la branche principale, sauf indication contraire de votre fournisseur.
Sur AlmaLinux, Rocky Linux, RHEL et leurs dérivés, il convient d'être prudent avec les rétroportages : le numéro de version du paquet peut sembler ancien, mais il contient des correctifs de sécurité rétroportés par le mainteneur. C'est pourquoi, dans un environnement Linux d'entreprise, il est préférable de se fier aux avis et aux paquets de la distribution plutôt que de comparer naïvement uniquement la version amont.
dnf clean all
dnf update -y nginx*
systemctl restart nginx
nginx -v
Sur Debian et Ubuntu :
apt update
apt full-upgrade -y
systemctl restart nginx
nginx -v
Ces commandes ne doivent pas être interprétées comme des correctifs pour la nouvelle vulnérabilité non publiée, mais comme une mesure nécessaire pour au moins corriger les failles déjà connues.
Vérifier les modules et les configurations personnalisées
Un autre aspect souvent négligé est la présence de modules dynamiques ou de configurations personnalisées. NGINX est fréquemment compilé avec des modules tiers, des modules WAF, des modules Brotli, headers-more, Lua, NJS, streams, QUIC, HTTP/3 ou des composants fournis par des fournisseurs externes. Une vulnérabilité critique peut être aggravée par des configurations complexes, mais une configuration non standard peut également compliquer l'application des correctifs.
nginx -V 2>&1 | tr ' ' 'n' | grep -E 'configure|with-|add-module|modules-path|conf-path'
Si NGINX a été compilé manuellement, vous devez localiser le chemin d'accès au fichier binaire en cours d'exécution :
which nginx
readlink -f $(which nginx)
ps -eo pid,user,comm,args | grep '[n]ginx'
Dans de nombreux cas réels, il s'avère que le paquet du système d'exploitation est à jour, mais que le service systemd pointe vers un binaire compilé manuellement. /usr/local/nginx, /opt/nginx ou des répertoires similaires.
Réduisez la surface exposée
En attendant les informations officielles, il est conseillé de réduire au minimum tout ce qui est superflu. Si vous utilisez des hôtes virtuels temporaires, des environnements de test publics, des serveurs de noms inutilisés ou des emplacements obsolètes, il est temps de les désactiver.
Il est également utile de rechercher les configurations complexes et obsolètes, notamment celles liées aux réécritures, aux expressions régulières et aux redirections :
grep -RInE 'rewrite|if (|set $|return 30|proxy_pass|try_files' /etc/nginx /usr/local/nginx/conf 2>/dev/null
Avertissement : cette vérification ne permet pas d’identifier la nouvelle vulnérabilité de Nebula, car nous ignorons son déclencheur. Elle contribue toutefois à cartographier les zones de configuration les plus sensibles et à simplifier la logique. De récentes vulnérabilités dans NGINX ont démontré comment des directives apparemment anodines peuvent devenir dangereuses dans certaines combinaisons.
Dans la mesure du possible, il est conseillé de déplacer les règles complexes vers la couche application ou de les simplifier. Un proxy inverse doit assurer les fonctions minimales requises : terminaison TLS, proxy, mise en cache, compression, limitation de débit, en-têtes de sécurité et quelques règles claires. Toute expression régulière maintenue pendant des années sans révision contribue à l’augmentation de la dette technique.
Surveillez les plantages, les erreurs de segmentation et les anomalies des nœuds de calcul.
Une exécution de code à distance (RCE) basée sur une corruption de mémoire se manifeste souvent par des plantages, des redémarrages de processus, des erreurs de segmentation ou des anomalies dans les journaux. Ces signes n'indiquent pas toujours une exploitation, mais en période d'incertitude, ils deviennent significatifs.
journalctl -u nginx --since "24 hours ago" | grep -Ei 'segfault|signal|core|worker|exited'
dmesg -T | grep -Ei 'nginx|segfault|general protection|core dumped'
grep -R "signal 11|segmentation fault|core dumped" /var/log/nginx /var/log/messages /var/log/syslog 2>/dev/null
Il est conseillé d'envoyer ces événements à votre système de surveillance centralisé, votre SIEM ou votre système de gestion des journaux. Une panne isolée d'un nœud de calcul peut être gênante ; des pannes répétées lors de requêtes HTTP anormales justifient une enquête.
Plesk, cPanel, hébergement et environnements gérés
Dans les environnements d'hébergement, le problème est encore plus délicat. Plesk, cPanel, EasyApache, les dépôts des fournisseurs, les packages NGINX personnalisés et les proxys inverses intégrés peuvent avoir des cycles de mise à jour différents de celui du package NGINX de la distribution. Il ne suffit pas de vérifier dnf update o apt upgradeVous devez comprendre d'où provient réellement le fichier binaire NGINX en cours d'exécution.
Sur les serveurs dotés de panneaux de contrôle, il est recommandé :
- Consultez les avis du fournisseur du panel ;
- mettre à jour les composants du panneau et de la pile Web ;
- vérifier s'il existe d'autres dépôts ;
- redémarrer NGINX après la mise à niveau ;
- Vérifiez qu'il n'existe aucun fichier binaire personnalisé en dehors du contrôle du gestionnaire de paquets.
Pour un hébergeur, la bonne approche consiste à considérer NGINX comme un composant critique et omniprésent, au même titre que le noyau, OpenSSL, PHP-FPM et la base de données. Son exposition publique fait de toute tentative d'exécution de code à distance une priorité opérationnelle.
conclusion
Le nouveau rapport de Nebula Security ne constitue pas encore une CVE ni un avis officiel. Il est essentiel de le préciser afin d'éviter toute panique injustifiée. Par ailleurs, ignorer ce problème serait une grave erreur : NGINX est un composant central des infrastructures web modernes, et de récentes vulnérabilités du module de réécriture ont déjà démontré que des failles anciennes peuvent rester indétectables pendant des années.
En l'absence de correctif public, la meilleure solution est pragmatique : recenser toutes les instances NGINX, corriger immédiatement les vulnérabilités connues, vérifier les builds et les modules, réduire la surface d'exposition, s'assurer que les workers s'exécutent avec les privilèges minimaux, maintenir l'ASLR activé et surveiller les plantages ou anomalies. Dès la publication d'un avis officiel par F5 ou NGINX, il sera nécessaire d'appliquer rapidement le correctif et de redémarrer les services concernés.
Pour l'instant, la phrase la plus correcte est la suivante : il n'existe pas encore de correctif public ni de CVE attribué pour la nouvelle RCE citée par Nebula Security, mais les administrateurs doivent se préparer comme si l'avis pouvait arriver à tout moment.
