NGINX Rift - un nouvel exploit NGINX

• NGINX Rift est une PoC d’exécution de code à distance visant CVE-2026-42945, un dépassement critique de tampon de tas dans ngx_http_rewrite_module de NGINX
• Cette vulnérabilité permet une exécution de code à distance sans authentification sur les serveurs utilisant les directives rewrite et set
• Le problème provient d’un bug introduit en 2008, causé par un traitement différent du drapeau is_args entre la passe de calcul de longueur et la passe de copie du moteur de scripts NGINX
• Lorsqu’une chaîne de substitution rewrite contient ?, is_args est défini dans le moteur principal, mais le calcul de longueur s’exécute dans un sous-moteur nouvellement initialisé à 0 et ne renvoie donc que la longueur de capture d’origine
• À l’étape de copie, ngx_escape_uri et NGX_ESCAPE_ARGS sont appelés avec is_args = 1, ce qui étend chaque octet échappable à 3 octets et provoque un débordement du tampon de tas sous-alloué avec des données d’URI contrôlées par l’attaquant
• L’exploit utilise du heap feng shui entre les requêtes pour corrompre le pointeur cleanup d’un ngx_pool_t adjacent, et comme il est impossible d’insérer des octets nuls dans les octets d’URI, il effectue le spray via le corps POST
• Le pointeur corrompu est redirigé vers un faux ngx_pool_cleanup_s, configuré pour appeler system() lors de la destruction du pool
• En plus de CVE-2026-42945, trois autres problèmes de corruption mémoire — CVE-2026-42946, CVE-2026-40701 et CVE-2026-42934 — ont aussi été découverts automatiquement par le système d’analyse de sécurité de depthfirst après un seul onboarding du code source de NGINX
• Les versions affectées sont NGINX Open Source 0.6.27–1.30.0 et NGINX Plus R32–R36 ; les versions corrigées indiquées sont Open Source 1.31.0/1.30.1 et Plus R36 P4/R35 P2/R32 P6
• L’avis complet de l’éditeur est disponible sur https://my.f5.com/manage/s/article/K000160932, et les détails techniques sont traités dans le technical write-up
• La PoC a été testée sur Ubuntu 24.04.3 LTS et propose un enchaînement avec ./setup.sh, docker compose -f env/docker-compose.yml up, puis python3 poc.py --shell pour lancer un conteneur NGINX vulnérable et ouvrir un shell

[GN⁺]

Réactions sur Hacker News

• En tant que responsable sécurité, je suis fatigué de voir autant de réactions qui affirment ou laissent entendre que ce problème est beaucoup moins effrayant simplement parce que l’exploit publié ne contourne pas ASLR
  Le texte original affirme qu’il existe un moyen de contourner ASLR de façon fiable avec cette attaque, et je pense qu’il est raisonnable de le considérer comme l’hypothèse par défaut même sans preuve
  ASLR n’est qu’une technique de défense en profondeur qui rend l’exploitation plus difficile, et dans la plupart des cas, avec assez de temps et de compétence, un contournement d’ASLR finit par arriver
  Avec les agents LLM, cette barrière de temps et de compétence baisse toutes les quelques semaines, donc ce n’est qu’une question de temps avant qu’un exploit entièrement opérationnel apparaisse, qu’il soit rendu public ou qu’il reste privé
  Dire « si ASLR est activé, ce n’est pas dangereux » est tout simplement faux, et c’est très nuisible pour ceux qui y croient
  Cette croyance erronée selon laquelle on peut ignorer les failles de sécurité parce que des mécanismes d’atténuation rendent l’exploitation plus difficile a déjà causé beaucoup de dégâts par le passé
  C’est une bonne chose d’avoir des mécanismes d’atténuation modernes, mais il faut corriger ça le plus vite possible, et si vous êtes un éditeur, ne traitez pas un rapport de vulnérabilité comme invalide simplement parce que le chercheur n’a pas montré de contournement d’ASLR ; corrigez la cause racine

  • Une vulnérabilité accessible à distance ne doit pas être prise à la légère
    Cela dit, pour l’instant les prérequis semblent un peu particuliers
    J’utilise nginx depuis 10 ans dans diverses configurations, et je n’ai jamais utilisé rewrite et set ensemble
  • On peut raisonnablement considérer que les gens qui disent « l’IA va régler la cybersécurité » et ceux qui disent « si ASLR est activé, ça va » se recoupent à 100 %
    Et ils disent forcément « cyber »
  • Je ne suis pas d’accord avec ce point de vue, ou au moins je préférerais le formuler autrement
    ASLR ressemble à un mot de passe supplémentaire à deviner, avec une certaine entropie, et il est généralement fiable
    Si la vulnérabilité n’inclut pas de fuite d’information, ASLR peut complètement l’atténuer, ou bien il faut une deuxième vulnérabilité
    C’est une autre discussion
    ASLR peut complètement atténuer une vulnérabilité prise isolément, mais pas forcément empêcher toute chaîne d’exploitation
    Cela dit, pour convaincre de patcher rapidement, il vaut mieux invoquer la possibilité d’une deuxième vulnérabilité créant une fuite d’information
    Les chaînes d’exploitation sont dangereuses avec tous les types de vulnérabilités
  • Il est difficile d’empêcher la désinformation de se propager sur Internet, et la plupart des gens ne savent même pas qu’ils ont tort
    Ce qui est vraiment nuisible, c’est de croire tel quel un commentaire aléatoire sur Internet énoncé avec assurance
    Développer la capacité de percer ce genre de choses aide non seulement en sécurité, mais aussi ailleurs
  • Quand je lis un rapport de remote code execution sur un logiciel exposé à l’Internet public, je fais généralement la mise à niveau en quelques minutes
    C’est précisément pour ça que je lis ce genre de rapports, et il faut les prendre au sérieux
    Sinon, la machine finira bientôt compromise
    Ces derniers temps, beaucoup d’exploits de remote code execution rendus publics semblent sortir sans préavis, et j’aimerais au moins qu’on laisse quelques minutes pour mettre à jour le logiciel
    On se croirait à la fin des années 1980 et au début des années 1990, quand les bugs sendmail exploitables à distance tombaient en cascade sans garde-fous sur la divulgation
    Si on ne lit pas ces rapports, ou trop tard, des millions de machines peuvent être compromises
    Actuellement, nginx représente environ 39 à 43 % du marché public des serveurs web, donc c’est assez sérieux

• C’est assez grave, mais il y a des prérequis
  Il faut une directive rewrite dont la chaîne de remplacement contient un point d’interrogation, suivie d’une directive set qui référence un groupe de capture d’expression régulière
  Par exemple : set $var $1
  En outre, la preuve de concept suppose ASLR désactivé

  • Exemple : https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • Existe-t-il une distribution qui désactive ASLR par défaut ?
    Même en le désactivant manuellement, nginx ne me viendrait pas à l’esprit comme candidat probable
  • On n’utilise presque plus rewrite aujourd’hui, non ?
    J’ai l’impression que c’était surtout à l’époque de PHP et d’Apache

• La page officielle de F5 est ici : https://my.f5.com/manage/s/article/K000161019
  Comme cela a été écrit ailleurs, ASLR protège
  En attendant une version corrigée sur les plateformes affectées, la mesure d’atténuation recommandée est « d’utiliser des captures nommées au lieu de captures anonymes dans les définitions rewrite »
  En substance : « pour atténuer la vulnérabilité dans cet exemple, remplacez $1 et $2 par les captures nommées appropriées $user_id, $section »
  F5 a patché 1.31.0 et 1.30.1
  OpenResty dispose de correctifs pour 1.27 et 1.29 : https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  L’avancement pour OpenResty, le serveur d’applications Lua basé sur Nginx, peut être suivi ici : https://github.com/openresty/openresty/issues/1119

• La preuve de concept désactive ASLR : https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Les processus worker sont forkés depuis le master, donc ils héritent de la même disposition mémoire
    On peut faire crasher les workers un nombre illimité de fois
    Il est donc très probable qu’il existe un moyen d’en faire un oracle de lecture
    Au minimum, un déni de service fiable semble possible
    Analyse complète de Depth First : https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• Existe-t-il de bonnes alternatives à Apache et Nginx, écrites dans un langage memory-safe et avec peu de trous de sécurité ?
  J’ai brièvement regardé Jetty, écrit en Java, et Caddy, écrit en Go, mais vu l’historique d’autres types de vulnérabilités comme l’injection de shell dans Jetty, je ne suis pas certain que ce soit vraiment mieux

  • La sûreté mémoire est une bonne chose, mais elle ne bloque pas toutes les menaces
    Les opérateurs d’infrastructure devraient aujourd’hui se familiariser avec les défenses actives de type MAC, c’est-à-dire SELinux et AppArmor
    Avant, la friction était forte, mais il existe maintenant davantage d’outils pour en faciliter l’usage
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Pour information, j’ai créé moi-même ces deux dépôts
  • Pour un logiciel utilisé à l’échelle d’Apache et de nginx, il est inévitable qu’il y ait un historique de vulnérabilités
    Le fait qu’ils aient tous deux conservé une telle part de marché pendant aussi longtemps est plutôt un bon signe
  • Caddy a été vraiment agréable à utiliser
    En revanche, je trouve moyen le modèle qui produit des milliers de binaires selon la combinaison de plugins voulue, au lieu d’un véritable système de plugins
    Cela dit, si on compile depuis les sources, c’est assez propre et simple
  • Apache, et probablement Nginx aussi, ont énormément de fonctionnalités et de composants
    La plupart des serveurs HTTP alternatifs réduisent fortement le périmètre, donc il faut d’abord décider des fonctionnalités dont on a besoin
    Je n’ai pas vu beaucoup de discussions sur des serveurs HTTP en langage memory-safe
    Les trois gros serveurs en C — Apache, Nginx et lighttpd — sont tous assez solides, et peu de gens semblent vouloir migrer vers un nouveau projet uniquement à cause du langage
    De plus, choisir la plupart des langages memory-safe implique aussi d’accepter leur runtime, parfois très volumineux, ou leur machine virtuelle, ainsi que leurs dépendances
    Avec un serveur web Java, il y a de fortes chances qu’on se retrouve avec log4j, comme souvent dans un projet Java pris au hasard
  • Pour un usage de load balancer, HAProxy fait très bien le travail

• « L’exploit utilise du heap feng shui inter-requêtes (cross-request heap feng shui) », c’est la première fois que je vois feng shui utilisé de cette façon

• C’est patché dans Debian 12 ?
  Et si on n’utilise ni rewrite ni set nulle part, on peut considérer qu’on n’est pas affecté ?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • Ubuntu était patché ce matin
    Debian ne semble pas encore avoir patché trixie
  • Il me semble assez rare d’utiliser nginx sans même utiliser set au minimum
    Dans la plupart des cas d’usage de nginx, on termine TLS puis on transmet la requête à node/php/go, etc.
    Donc je pensais qu’il y aurait au moins une ligne du genre proxy_set_header X-Host $host; avec un set contenant des données contrôlées par l’attaquant
    Correction : les captures nommées ne semblent pas affectées
    S’il n’y a pas de $1 quelque part, ça devrait aller

• Meilleurs liens :
  https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
  https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)