Le 15 juillet 2026, nginx a publié les versions 1.30.4 (stable) et 1.31.3 (mainline) pour corriger CVE-2026-42533, un débordement de tampon de tas noté 9.2 sur l'échelle CVSS. Aucune authentification n'est nécessaire : une requête HTTP forgée suffit. Sur une compilation par défaut, le résultat est le plantage puis le redémarrage du processus worker — un déni de service — et là où l'ASLR est désactivé ou contournable, l'exécution de code à distance devient possible.

Le déclencheur : map + expression régulière + groupes de capture

La cause n'est pas l'analyseur HTTP mais l'évaluation de script en deux passes de nginx : la passe qui calcule une longueur et celle qui écrit la valeur partagent le même état de capture PCRE. Lorsqu'une directive map contenant une expression régulière est évaluée entre deux références au même groupe de capture (par exemple $1), cet état partagé est écrasé silencieusement, les deux passes divergent sur la taille du tampon et l'écriture dépasse la zone allouée.

Autrement dit, tous les nginx ne sont pas exploitables, mais la plage affectée est énorme : de 0.9.6 à 1.30.3 (stable) et 1.31.2 (mainline), soit la plupart des compilations livrées depuis 2011. Côté commercial, NGINX Plus R33 à R36 sont concernés (corrigé dans R36 P7) et 37.0.0.1 à 37.0.2.1 sont corrigés dans 37.0.3.1.

Pourquoi cela ne peut pas attendre

Le chercheur a délibérément retenu l'analyse complète et le PoC pendant 21 jours après le correctif afin de laisser une fenêtre de mise à jour aux administrateurs. Cette fenêtre est refermée. Un autre cas de la même année illustre la vitesse de militarisation : CVE-2026-42945 — le débordement de tas « Nginx Rift » dans ngx_http_rewrite_module, corrigé en mai 2026 — était exploité dans la nature environ une semaine après le correctif, avec une estimation de 5,7 millions de serveurs nginx exposés sur Internet exécutant des versions potentiellement vulnérables. Deux failles comparables en six mois : un bon argument contre le serveur web « installé une fois, jamais touché ».

Une vérification en trois étapes

  • Vérifiez la version, mais ne vous fiez pas au seul nginx -v : Debian et Ubuntu rétroportent les correctifs sur l'ancien numéro de version, donc une compilation affichant encore 1.24.0 peut très bien être corrigée. Pour les paquets de distribution, lisez la révision du paquet via apt policy nginx et confirmez la CVE dans apt changelog nginx. Seules les compilations issues du dépôt officiel ou faites à la main se comparent directement à 1.30.4 / 1.31.3.
  • Vérifiez si votre configuration utilise map avec une expression régulière : grep -rn "map " /etc/nginx/, en cherchant les entrées commençant par ~ et les références répétées à des groupes de capture comme $1 sur le même chemin de requête. Sans cette combinaison, l'exposition est bien moindre.
  • Vérifiez si des workers redémarrent silencieusement : grep -i "worker process.*exited on signal" /var/log/nginx/error.log. Des sorties répétées en signal 11 sont le symptôme classique — et côté visiteur, cela ressemble seulement à un 502 occasionnel, ce qui explique pourquoi on met souvent cela sur le compte du réseau.

Comment mettre à jour

Paquets de distribution : sudo apt update && sudo apt install --only-upgrade nginx, puis sudo nginx -t && sudo systemctl reload nginx. Dépôt officiel ou compilation maison : passez à 1.30.4 / 1.31.3 ou plus récent, validez avec nginx -t, puis rechargez. Un reload ne coupe pas les connexions établies, aucune fenêtre de maintenance n'est donc nécessaire. À noter : les mêmes versions corrigent aussi CVE-2026-60005 (divulgation mémoire dans ngx_http_slice_module) et CVE-2026-56434 (use-after-free dans ngx_http_ssi_module) — trois problèmes réglés en une mise à jour.

Faites de « je peux corriger moi-même » un critère d'achat

La rapidité de réaction à un avis de sécurité dépend de votre accès root et de votre liberté de choisir le moment du reload. En hébergement mutualisé, vous attendez le planning du prestataire et ne pouvez généralement même pas lire l'error.log complet. Sur votre propre VPS, dix minutes suffisent entre l'avis et le reload. Les nœuds SharkCloud au Japon, à Singapour, à Hong Kong et aux États-Unis sont des instances indépendantes où les versions du système et du serveur web vous appartiennent : un avis se traite le jour même, pas à la prochaine fenêtre de maintenance.