Skip to main content
Publié le 12 août 2026
CVE-2026-42533 — débordement de tampon avec map et regex. Touche nginx 0.9.6 à 1.31.2. Corrigé en 1.30.4 (stable) et 1.31.3 (mainline). Si vous avez corrigé en mai pour Nginx Rift, ce correctif ne couvre pas celle-ci.

​
Ce que la plupart ont mal lu

Deux débordements de tas sont apparus dans le moteur de script de nginx à quelques mois d’intervalle, et ils se ressemblent assez pour être confondus. Ce ne sont pas les mêmes — et, c’est là que ça compte, la version qui corrige l’une exécute encore l’autre. Lisez les deux dernières lignes ensemble. Rift est corrigée en 1.30.1. La CVE-2026-42533 touche tout jusqu’à 1.31.2. Un serveur passé en 1.30.1 en mai, coché comme « corrigé », est en plein dans la plage. Si votre dernière mise à jour nginx a été motivée par la couverture de Rift, le travail n’est pas fini.

​
La faille

Les deux bugs viennent de la même conception. nginx évalue les expressions de script en deux passes : la première mesure la taille de tampon nécessaire, la seconde y écrit. Quand l’état sur lequel s’appuie le moteur change entre les deux passes, l’écriture dépasse la taille mesurée, et le débordement atterrit sur le tas. Rift y parvenait via un drapeau périmé. Celle-ci y parvient via l’état des captures PCRE : il n’existe pas de sauvegarde-restauration autour, donc les captures d’une évaluation écrasent celles d’une autre. Le déclenchement exige une forme de configuration précise : un bloc map fondé sur une regex, et une directive qui référence à la fois une capture de regex et la variable de sortie du map dans la même expression. Ce n’est pas exotique. C’est une façon normale d’écrire une règle de routage.
Notez l’écart de sévérité. nginx classe celle-ci en major et Rift en medium, quand plusieurs trackers tiers ont noté Rift à 9,2 en CVSS. Les scores éditeur et tiers ne mesurent pas la même chose ; ce sur quoi agir, ce sont les plages de versions ci-dessus, pas le chiffre.

​
Mesurer votre exposition

La quatrième ligne mérite d’insister. Un nginx:1.30.1 épinglé dans un Dockerfile ne se met pas à jour tout seul : seule une reconstruction le fait bouger. La preuve de concept complète publiée était calibrée spécifiquement pour des déploiements Docker — image de base, instantané de paquets et révision des sources.

​
Vérifier et mettre à jour

Déterminez ce que vous exécutez réellement, qui n’est pas toujours ce que croit votre gestionnaire de paquets :
Debian, Ubuntu et dérivées :
AlmaLinux, Rocky Linux et RHEL :
Un rechargement ne suffit pas ici. nginx -s reload démarre de nouveaux workers, mais le processus maître continue d’exécuter l’ancien binaire. Utilisez restart pour que tout l’arbre de processus reprenne le code corrigé, puis confirmez avec nginx -v.
Pour les conteneurs, reconstruisez plutôt que de corriger sur place :

​
Si vous ne pouvez pas mettre à jour tout de suite

Aucun réglage de configuration ne désactive la faille. Ce que vous pouvez faire, c’est retirer le déclencheur : si un bloc map bâti sur une regex alimente une variable utilisée aux côtés d’une capture de regex dans la même directive, réécrire cette expression ferme le chemin en attendant le correctif. Repérez les candidats :
Considérez cela comme un palliatif qui se compte en jours, pas comme un correctif.

​
La leçon plus large

Deux failles de la même classe, dans le même moteur, à quelques mois d’écart, avec des plages de versions qui se chevauchent sans se confondre. Le mode de défaillance n’est pas « on n’a pas corrigé » — c’est « on a corrigé, et on a supposé que l’affaire était close ». Quand un avis nomme une version, la question utile n’est pas avons-nous mis à jour ? mais avons-nous dépassé la plage de cet avis-là ? Ce sont deux questions différentes, et seule la seconde a une réponse vérifiable. Notre guide pour auditer et durcir nginx sur un VPS décrit la routine qui attrape ce genre de chose avant qu’un avis ne vous y force. Une question sur un serveur hébergé chez nous ? Notre équipe est disponible depuis votre espace client.