CVE-2026-60005 : Fuite mémoire liée au module slice

En 30 secondes

  • Qui : nginx Open Source (1.15.8 → 1.31.2) et NGINX Plus, avec une gravité « moyenne » côté nginx. nginx
  • Quoi : un accès à de la mémoire non initialisée dans un worker, qui permet de faire fuiter un peu de mémoire ou de le faire redémarrer, sans authentification. OSV
  • Condition clé : le module ngx_http_slice_module n'est pas actif par défaut, il faut nginx compilé avec --with-http_slice_module. Ubuntu
  • Correctif : nginx 1.30.4 (stable) ou 1.31.3 (mainline), publiées le 15 juillet 2026. nginx

Ce qui se passe réellement

Le module slice sert à découper une grosse réponse en morceaux (des requêtes Range), ce qui est pratique pour mettre en cache de gros fichiers, comme des vidéos ou des archives. Dans certains cas, le worker lit alors une zone mémoire qu'il n'a pas initialisée. Deux scénarios déclenchent le problème : la directive slice combinée à des captures regex non nommées dans un même location, ou une mise à jour de cache en arrière-plan. IONIX

Les conséquences restent limitées. C'est un problème du plan de données uniquement, sans exposition du plan de contrôle. Aucune exécution de code n'est annoncée. Ubuntu

Sur la gravité, le score varie selon la source : nginx dit « moyenne », tandis qu'un agrégateur affiche un CVSS 3.1 de 8.2. Red Hat souligne que l'impact est réduit puisque le module n'est pas activé par défaut. Le risque réel dépend donc surtout de ta configuration. IONIXRed Hat

Chronologie

Date Événement
15 juillet 2026 nginx publie 1.30.4 et 1.31.3 avec le correctif
20 juillet 2026 La CVE est publiée dans les bases publiques
21 septembre 2026 Cette fiche

Un script pour tester mon serveur

Plutôt que trois commandes séparées, voici un petit script qui affiche les faits utiles. Car les paquets de distribution rétroportent les correctifs sans changer le numéro de version.

bash

#!/usr/bin/env bash
# check-cve-2026-60005.sh : exposition d'un nginx au module slice

echo "== Version =="
nginx -v 2>&1

echo "== Module slice compilé ? =="
if nginx -V 2>&1 | grep -q -- '--with-http_slice_module'; then
  echo "oui"
else
  echo "non -> pas concerné"; exit 0
fi

conf="$(sudo nginx -T 2>/dev/null)"

echo "== Directive slice utilisée ? =="
echo "$conf" | grep -nE '^\s*slice\s' || echo "non"

echo "== Cache en arrière-plan ? =="
echo "$conf" | grep -nE 'proxy_cache_background_update\s+on' || echo "non"

echo "== Locations regex (à relire à la main) =="
echo "$conf" | grep -nE 'location\s+~'

Comment lire le résultat :

  • Module absent : tu n'es pas concerné.
  • Module présent mais aucune directive slice et pas de cache en arrière-plan : exposition très faible.
  • slice dans un location ~ ...(.*)... (regex avec parenthèses non nommées), ou proxy_cache_background_update on : corrige rapidement.

Corriger

1. Mettre à jour (la vraie solution)

bash

# Dépôt nginx.org (Debian/Ubuntu)
sudo apt update && sudo apt install --only-upgrade nginx

# Famille Red Hat
sudo dnf upgrade nginx

2. Paquet de distribution : chercher le correctif dans le changelog

bash

apt changelog nginx | grep -i CVE-2026-60005          # Debian/Ubuntu
rpm -q --changelog nginx | grep -i CVE-2026-60005     # Red Hat

3. Atténuer en attendant. Red Hat conseille de désactiver le module s'il est inutile ; sinon, d'éviter les captures non nommées avec slice et de désactiver proxy_cache_background_update. Red Hat

nginx

# Avant : capture non nommée
location ~ ^/(.+)$ { slice 1m; ... }

# Après : capture nommée
location ~ ^/(?<fichier>.+)$ { slice 1m; ... }

proxy_cache_background_update off;

Dans tous les cas, on teste puis on redémarre pour être sûr de charger le nouveau binaire :

bash

sudo nginx -t && sudo systemctl restart nginx

À retenir

  • Une CVE nginx ne concerne pas toutes les installations : version, modules compilés et configuration comptent autant que le numéro de version.
  • Relire ses location en regex de temps en temps est une bonne hygiène, car ces blocs vieillissent mal.
  • Mettre à jour à chaque publication de sécurité : ce mois-ci, c'est déjà la 1.31.6 qui est sortie.

Sources

Projet VPS - Hébergement de mon portfolio et de mon dotclear

Introduction : De l'hébergement gratuit au VPS personnel

Tout a commencé avec InfinityFree, un hébergement gratuit qui nous a permis de faire nos premiers pas et de créer nos premiers portfolios, que ce soit sous WordPress ou en HTML.

Par la suite, nous sommes passés à l'étape supérieure avec le projet VPS. Nous avions le choix entre migrer notre site WordPress existant ou créer un portfolio autonome tout en migrant Dotclear. C'est cette seconde option que j'ai choisie.

 

Continue reading

Stage - Intervention réseau au KHUB Karting

Contexte 

Durant mon stage chez I Tech Informatique à Sainte-Catherine (réalisé du 26 mai au 4 juillet 2026), j’ai eu l'opportunité de participer à plusieurs interventions sur le terrain. L'une d'elles m'a particulièrement marqué : un déplacement avec mon tuteur au KHUB Karting.

Continue reading

Page top