Ce que corrigent nginx 1.30.6 et 1.31.7
Les deux versions sont parues le même jour, le 14 octobre 2026, sur la page d'actualités de nginx.org. Elles corrigent cinq failles du processus worker : trois corruptions mémoire, une injection de données dans le corps des requêtes HTTP/3 et une falsification de session TLS. Une version mainline 1.31.8 est sortie le 21 octobre 2026 ; son annonce ne mentionne aucune faille, mais elle succède à la 1.31.7 et en contient donc les correctifs.
Sur la gravité, deux lectures coexistent, et il faut les citer telles quelles. La page des avis de sécurité de nginx.org classe les cinq failles en sévérité « medium ». Les fiches CVE publiées par F5, l'éditeur de nginx, attribuent un score CVSS 3.1 de 8,1 à trois d'entre elles. Elles précisent le scénario : le worker plante et redémarre, et une exécution de code reste possible si l'ASLR est désactivé ou contourné. Toutes demandent une configuration précise pour être exploitables. C'est ce qui rend l'inventaire rentable : sur un parc, une partie des serveurs n'est simplement pas concernée.
Les cinq failles et ce qui vous expose
- CVE-2026-15176, alias et rewrite — débordement de tas dans le worker quand une
locationcombinealias,rewriteet une directivesetoureturnqui lit$request_filename, ou quand$request_filenamefigure dans unlog_format. Plage vulnérable : de 0.1.29 à 1.31.6. - CVE-2026-93479, chaînes avec variables — débordement lors du calcul de la racine ou de la journalisation, typiquement un
mapà regex dont les captures$1,$2sont lues parrootou unlog_formatavant la variable de sortie. Plage vulnérable : 1.30.0 à 1.30.5 et 1.31.2 à 1.31.6. - CVE-2026-95101, corps de requête HTTP/3 — une partie d'une trame inconnue peut être lue comme corps de requête : contournement de
client_max_body_sizeou injection dans la requête relayée, avecproxy_request_buffering on, la valeur par défaut. Plage vulnérable : de 1.25.0 à 1.31.6. - CVE-2026-97629, tickets de session TLS — avec
ssl_session_cache shared:…et sansssl_session_ticket_key, nginx fait tourner ses clés lui-même ; l'une restait non initialisée, ce qui permet de forger une session et, selon F5, de contourner la vérification d'un certificat client. Plage vulnérable : de 1.23.2 à 1.31.6. - CVE-2026-97205, SSI avec AIO — use-after-free quand
aioest actif et qu'une page SSI contient des commandesinclude virtual. Plage vulnérable : de 0.8.11 à 1.31.6. - Sévérité publiée — « medium » pour les cinq sur nginx.org. Selon les fiches CVE de F5, le score CVSS 3.1 est de 8,1 pour CVE-2026-15176, CVE-2026-93479 et CVE-2026-97205, de 6,5 pour CVE-2026-97629 et de 5,3 pour CVE-2026-95101.
Versions touchées et versions corrigées
Faites défiler le tableau
| Faille ou paquet | Versions vulnérables | Corrigé dans |
|---|---|---|
| CVE-2026-15176 — alias et rewrite | 0.1.29 à 1.31.6 | 1.30.6 et 1.31.7 |
| CVE-2026-93479 — chaînes avec variables | 1.30.0 à 1.30.5, 1.31.2 à 1.31.6 | 1.30.6 et 1.31.7 |
| CVE-2026-95101 — HTTP/3 | 1.25.0 à 1.31.6 | 1.30.6 et 1.31.7 |
| CVE-2026-97629 — tickets TLS | 1.23.2 à 1.31.6 | 1.30.6 et 1.31.7 |
| CVE-2026-97205 — SSI avec AIO | 0.8.11 à 1.31.6 | 1.30.6 et 1.31.7 |
| Paquet Debian 13 (trixie) | Paquets antérieurs à `1.26.3-3+deb13u10` | `1.26.3-3+deb13u10` (DSA-6575-1) |
| Paquet Debian 12 (bookworm) | Marqué vulnérable au 22 octobre 2026 | Pas encore publié |
| Paquets Ubuntu | « Needs evaluation » au 22 octobre 2026 | Pas encore publié |
Paquet de distribution ou Docker : le numéro ne suffit pas
C'est l'objection la plus fréquente sur un parc hétérogène : nginx -v affiche 1.26.3 ou 1.22.1, bien en dessous de 1.30.6, et pourtant la machine peut être corrigée. Les distributions rétroportent les correctifs de sécurité dans leur propre branche sans changer le numéro amont : seul le suffixe du paquet bouge. Debian l'a fait pour trixie avec l'avis DSA-6575-1, qui couvre les cinq CVE. À l'inverse, au 22 octobre 2026, le suivi de sécurité Debian marquait encore bookworm comme vulnérable, et Ubuntu affichait « Needs evaluation » pour toutes ses versions suivies.
La seule vérification fiable est donc le changelog du paquet installé : zgrep -l CVE-2026-15176 /usr/share/doc/nginx*/changelog.Debian.gz sur Debian ou Ubuntu, rpm -q --changelog nginx | grep CVE-2026-15176 sur RHEL, AlmaLinux ou Rocky. Une ligne trouvée signifie que le correctif est rétroporté ; rien du tout signifie qu'il ne l'est pas encore. Pour Docker, c'est le tag qui compte : les images officielles nginx:1.30.6 et nginx:1.31.7 sont en ligne sur Docker Hub, et une image figée sur un tag antérieur reste vulnérable tant qu'elle n'est pas remplacée.
Inventorier l'exposition d'un serveur en dix minutes
Relever la version et la provenance
nginx -vdonne la version du binaire. La provenance du paquet décide de la procédure de mise à jour :apt-cache policy nginxsur Debian ou Ubuntu (dépôt nginx.org ou distribution)rpm -qi nginx | grep -E 'Version|Release|Vendor'sur RHEL et ses dérivées
Si nginx tourne dans un conteneur :docker ps | grep -i nginx.Lister les modules compilés
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|ssi|threads|file-aio'
Sans--with-http_v3_module, CVE-2026-95101 ne vous concerne pas. Le module SSI est compilé par défaut : seule l'option--without-http_ssi_modulel'exclut.Exporter la configuration effective
sudo nginx -T > /root/nginx-conf.txt 2>&1nginx -Tteste la configuration et l'imprime en entier, fichiers inclus. Interrogez ce fichier plutôt que/etc/nginxà la main : unincludeoublié suffit à rater une directive.Chercher alias et $request_filename (CVE-2026-15176)
grep -nE '^\s*(alias|rewrite)\s' /root/nginx-conf.txtgrep -n 'request_filename' /root/nginx-conf.txt
Vous êtes exposé si une mêmelocationcombinealias,rewriteet unsetoureturnqui lit$request_filename, ou si unlog_formatcontient cette variable.Chercher les map à regex (CVE-2026-93479)
grep -nA8 '^\s*map ' /root/nginx-conf.txt
Repérez les entrées qui commencent par~, puis cherchez$1,$2dans les directivesrootetlog_format. Cette faille ne touche que les branches 1.30 et 1.31 : un serveur en 1.28 ou en dessous n'est pas concerné.Vérifier HTTP/3 (CVE-2026-95101)
grep -nE 'listen\s.*quic|http3' /root/nginx-conf.txtgrep -n 'proxy_request_buffering' /root/nginx-conf.txt
HTTP/3 actif devant unproxy_pass, sansproxy_request_buffering off: exposé.Vérifier les tickets TLS (CVE-2026-97629)
grep -nE 'ssl_session_cache\s.*shared|ssl_session_ticket_key|ssl_session_tickets' /root/nginx-conf.txt
Exposé sishared:est présent sansssl_session_ticket_keynissl_session_tickets off. L'impact décrit par F5 porte surtout sur les sites qui authentifient leurs clients par certificat (ssl_verify_client).Vérifier SSI et AIO (CVE-2026-97205)
grep -nE '^\s*(ssi|aio)\s' /root/nginx-conf.txt
Exposé sissi onetaio(valeuronouthreads) s'appliquent aux mêmes pages, et que ces pages contiennent des commandesinclude virtual.
Dans quel ordre traiter un parc de serveurs
Avec ces huit contrôles, chaque serveur tombe dans l'une de trois cases. Première case : une condition d'exposition est présente et le serveur reçoit du trafic public. Il se patche aujourd'hui, ou reçoit une parade dans l'heure. Les reverse proxies qui servent HTTP/3 et les sites qui authentifient par certificat client y figurent en tête, parce que l'impact décrit touche la requête relayée ou l'authentification elle-même.
Deuxième case : aucune condition n'est présente, mais la version est dans la plage vulnérable. Le risque immédiat est faible, la mise à jour se planifie dans la semaine. Une configuration change, et un alias ajouté demain par un développeur suffit à rouvrir CVE-2026-15176.
Troisième case : version déjà corrigée, ou paquet de distribution dont le changelog cite les CVE. Rien à faire, sinon noter la date du contrôle. Gardez ce tableau par client : c'est aussi la réponse à donner quand un client vous demande s'il était concerné.
Mettre à jour environnement par environnement
Dépôt nginx.org sur Debian ou Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
Puisnginx -vdoit afficher 1.30.6 sur la branche stable, 1.31.7 ou plus récent sur la mainline.Dépôt nginx.org sur RHEL, AlmaLinux ou Rocky
sudo dnf upgrade nginx
Même contrôle avecnginx -v. Sur les deux familles, la procédure d'installation du dépôt est décrite sur la page Linux packages de nginx.org.Paquet de la distribution
Sur Debian 13,
sudo apt update && sudo apt install --only-upgrade nginxdoit amener1.26.3-3+deb13u10ou plus récent. Ailleurs, appliquez les mises à jour de sécurité dès leur parution et contrôlez le changelog comme indiqué plus haut. Si votre distribution tarde, la bascule vers le dépôt nginx.org est possible ; vérifiez d'abord que les modules dynamiques dont vous dépendez y existent.Conteneurs Docker
Dans le fichier compose, fixez
image: nginx:1.30.6(ounginx:stable), puis :docker compose pull && docker compose up -d
Une image construite à partir deFROM nginx:…se reconstruit :docker compose build --pull && docker compose up -d.Serveur géré par un panneau ou un hébergeur
Si nginx a été installé par un panneau d'administration ou par votre hébergeur, c'est leur canal de mise à jour qui livre le correctif. Contrôlez
nginx -vet le changelog du paquet après leur mise à jour, et, dans le doute, demandez à l'hébergeur à quelle date le correctif a été appliqué.Tester la configuration
sudo nginx -t
La réponse attendue contientsyntax is okettest is successful. Ne redémarrez jamais sans ce test : une configuration invalide laisse le service arrêté.Remplacer le binaire en mémoire
Mettre à jour le paquet ne remplace pas le processus maître déjà lancé.
sudo ls -l /proc/$(cat /run/nginx.pid)/exeaffiche(deleted)tant que l'ancien binaire tourne (chemin du fichier PID à adapter).sudo systemctl restart nginxcoupe quelques secondes ; le remplacement à chaud par le signalUSR2, documenté par nginx, évite cette coupure mais demande de bien connaître sa configuration systemd.Contrôler, puis surveiller
Relancez
nginx -vet la commande/proc: plus de(deleted). Testez un site aveccurl -sI https://votre-domaine.com. Ajoutez ensuite une alerte sur les redémarrages de workers, comme dans notre guide monitoring et alertes proactives sur VPS.
Impossible de patcher aujourd'hui : les parades publiées par F5
Les fiches CVE de F5 décrivent une parade pour chacune des cinq failles. Elles retirent la condition d'exposition sans corriger le code : ce sont des mesures d'attente.
CVE-2026-15176 : ne pas utiliser alias dans la location concernée, ou ne pas utiliser $request_filename.
CVE-2026-93479 : remplacer les captures non nommées par des captures nommées, du type (?<site>…), et limiter leur usage au bloc où la regex s'applique.
CVE-2026-95101 : proxy_request_buffering off;. Le corps des envois part alors en flux vers l'application, ce qui change son comportement sur les gros fichiers.
CVE-2026-97629 : retirer ssl_session_cache shared:…, ou charger des clés statiques avec ssl_session_ticket_key (fichier créé par openssl rand 80 > /etc/nginx/ticket.key). Les serveurs en ssl_session_tickets off; ne sont pas concernés.
CVE-2026-97205 : désactiver aio, ou ne plus servir de pages SSI.
Chaque parade se valide par nginx -t puis systemctl reload nginx. Un rechargement suffit ici, puisque le binaire ne change pas.
Détection : des indices, pas des preuves
Un worker qui plante laisse une ligne du type worker process 12345 exited on signal 11 dans le journal d'erreurs. Comptez-les avec grep -c 'exited on signal' /var/log/nginx/error.log et comparez avec les semaines précédentes. Des plantages répétés sur un serveur exposé sont un indice à creuser, pas une preuve de compromission ; leur absence n'est pas non plus une preuve d'innocuité. Mesure générale, hors avis de l'éditeur : restreignez au pare-feu les vhosts qui n'ont pas à être publics, comme le détaille notre checklist de durcissement d'un VPS Linux.
Dépannage : les erreurs qui suivent la mise à jour
nginx -v affiche 1.30.6, mais rien n'a changé. Le binaire sur disque est neuf, le processus maître est l'ancien. La commande ls -l /proc/<pid>/exe le montre avec la mention (deleted). Remède : redémarrage du service, ou remplacement à chaud par USR2.
nginx: [emerg] "/etc/nginx/ticket.key" must be 48 or 80 bytes. Le fichier de clé de tickets n'a pas la bonne taille, souvent parce qu'il a été créé en base64 ou avec un retour à la ligne. Remède : openssl rand 80 > /etc/nginx/ticket.key, sans option d'encodage, puis nginx -t.
nginx is already the newest version. Le dépôt de votre distribution ne propose pas encore de paquet corrigé. Remède : appliquer les parades ci-dessus et suivre le tracker de sécurité de la distribution, ou passer au dépôt nginx.org.
Le conteneur répond toujours avec l'ancienne version. L'image a été tirée, mais le conteneur n'a pas été recréé, ou le service pointe vers un tag figé. Remède : docker compose up -d --force-recreate, puis docker compose exec <service> nginx -v.
Cinq failles sur vingt serveurs : la charge d'une agence
Pour une agence, ce correctif n'est pas une commande : c'est un tour du parc. Un serveur par client, des provenances différentes (paquet Debian ici, dépôt nginx.org là, image Docker ailleurs), des configurations écrites par plusieurs personnes. Chaque machine demande l'inventaire, la mise à jour, le redémarrage, le contrôle, puis la réponse au client qui s'inquiète.
La façon la plus durable de réduire cette charge est de réduire le nombre de serveurs web que vous administrez vous-même. Avec l'hébergement revendeur ServOrbit.com, les sites de vos clients tournent dans des comptes cPanel que vous gérez depuis WHM, en marque blanche : vous gardez la relation client et vos prix, nous tenons l'infrastructure. Pour les machines qui doivent rester en accès root, l'option d'administration est proposée sur nos VPS Cloud. Et si vous hésitez encore sur le reverse proxy de ces machines, notre comparatif Caddy, Traefik et nginx pose les critères.
