> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# nginx (CVE-2026-42533) : deux débordements de tas, et pourquoi corriger le premier n'a pas corrigé le second

> Un débordement de tampon dans la gestion map et regex de nginx touche quinze ans de versions. Si vous avez corrigé Nginx Rift en mai, vous êtes encore exposé.

*Publié le 12 août 2026*

<Warning>
  **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.
</Warning>

## 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**.

|                   | Nginx Rift                | Celle-ci             |
| ----------------- | ------------------------- | -------------------- |
| CVE               | CVE-2026-42945            | **CVE-2026-42533**   |
| Composant         | `ngx_http_rewrite_module` | `map` + regex        |
| Versions touchées | 0.6.27 → 1.30.0           | **0.9.6 → 1.31.2**   |
| Corrigé en        | 1.30.1+, 1.31.0+          | **1.30.4+, 1.31.3+** |
| Sévérité nginx    | medium                    | **major**            |

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.

<Info>
  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.
</Info>

## Mesurer votre exposition

| Profil                                                   | Exposition             | Action                                                              |
| -------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------- |
| nginx 1.30.4+ ou 1.31.3+                                 | Nulle                  | Rien à faire                                                        |
| nginx entre 1.30.1 et 1.31.2, « déjà corrigé pour Rift » | **Critique**           | Mettre à jour maintenant — c'est le piège                           |
| nginx sous 1.30.1, aucun `map` avec regex                | Modérée                | Les deux failles s'appliquent ; corriger à la prochaine fenêtre     |
| Images conteneur avec un tag nginx épinglé               | **Souvent oubliées**   | La chaîne d'exploitation publiée visait justement les images Docker |
| Hébergement mutualisé où vous ne gérez pas nginx         | Traité par l'hébergeur | Rien à faire de votre côté                                          |

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 :

```bash theme={null}
# La version du binaire lui-même
nginx -v

# Tous les processus nginx de la machine, au cas où un ancien tourne encore
ps -eo pid,etime,cmd | grep "[n]ginx: master"
```

Debian, Ubuntu et dérivées :

```bash theme={null}
sudo apt update && sudo apt install --only-upgrade nginx
sudo systemctl restart nginx
nginx -v
```

AlmaLinux, Rocky Linux et RHEL :

```bash theme={null}
sudo dnf upgrade nginx
sudo systemctl restart nginx
nginx -v
```

<Warning>
  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`.
</Warning>

Pour les conteneurs, reconstruisez plutôt que de corriger sur place :

```bash theme={null}
# Récupérer l'image de base reconstruite et recréer le conteneur
docker compose pull
docker compose up -d

# Confirmer ce que le conteneur exécute vraiment
docker compose exec web nginx -v
```

## 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 :

```bash theme={null}
# Blocs map dont la source est une regex
grep -rn "^\s*map\s" /etc/nginx/ -A 3 | grep -E "~\*?\s"

# Directives combinant une capture ($1..$9) et une autre variable
grep -rnE '\$[1-9].*\$[a-z_]+|\$[a-z_]+.*\$[1-9]' /etc/nginx/
```

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](/fr/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](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.