nginx corrige cinq failles en octobre : vérifier et mettre à jour le serveur web

Le 14 octobre 2026, le projet nginx a publié les versions 1.30.6 (stable) et 1.31.7 (mainline), qui corrigent cinq vulnérabilités de sécurité. Le 26 octobre, Ubuntu a diffusé les paquets corrigés avec l’avis USN-8955-1 ; Debian a fait de même pour Debian 13 avec DSA-6575-1.

nginx est le serveur web, ou le proxy, qui répond aux requêtes d’un très grand nombre de sites, de logiciels de gestion et d’applications hébergés sur des serveurs Linux. Pour une PME tessinoise disposant d’un VPS ou d’un serveur dédié, la question pratique est simple : la version installée est-elle la version corrigée ? Y répondre demande un peu d’attention, car le numéro de version affiché par les distributions Linux est facilement trompeur.

Ce qui a été corrigé

Selon les avis de sécurité de nginx, les cinq failles concernent des fonctions ou des combinaisons de configuration précises, et non chaque installation :

Les évaluations divergent, et il est utile de comprendre pourquoi :

• nginx classe les cinq failles en gravité moyenne, car des configurations particulières sont nécessaires.
• F5, l’entreprise qui développe nginx et a attribué les CVE, donne à trois d’entre elles un score CVSS 3.1 de 8.1 (élevé), selon la base NVD : dans les pires cas, un attaquant sans identifiants peut faire planter les processus de nginx et, si les protections mémoire du système (ASLR) sont désactivées ou contournées, parvenir à exécuter du code.
• La faille sur les tickets TLS (CVE-2026-97629) peut permettre de contourner la vérification des certificats client, un mécanisme utilisé surtout pour des accès réservés et des interfaces entre systèmes.

Selon les données du NVD, l’évaluation de la CISA du 15 octobre ne signalait aucune exploitation connue et, au 9 novembre, aucune des cinq failles ne figure au catalogue des vulnérabilités exploitées. Il n’y a donc pas lieu de s’alarmer, mais pas non plus d’attendre : c’est une mise à jour à planifier rapidement.

Un chiffre aide à situer le sujet : en 2026, nginx a déjà publié 26 avis de sécurité. Mettre à jour le serveur web est une tâche récurrente, pas une intervention exceptionnelle.

Le détail à connaître : le numéro de version

Les distributions Linux n’installent pas la dernière version de nginx : elles corrigent la version choisie au début du cycle de vie du système. Sur Ubuntu 24.04, par exemple, la commande nginx -v affiche toujours 1.24.0 après la mise à jour : la correction figure dans le numéro complet du paquet. Pour savoir si un serveur est corrigé, il faut donc comparer la version du paquet avec celle indiquée dans l’avis de sa distribution.

Versions du paquet nginx indiquées comme corrigées (extrait) :

Les panneaux d’hébergement et les images de conteneurs (Docker) incluent souvent leur propre copie de nginx : dans ce cas, c’est la version du panneau ou de l’image qui compte, pas celle du système d’exploitation.

Que faire avec son serveur

1. Savoir où tourne nginx. Pas seulement sur le serveur du site : nginx est souvent utilisé comme proxy devant des logiciels de gestion, des applications web ou des conteneurs. Dressez la liste des systèmes concernés.
2. Vérifier la version du paquet. Sur Ubuntu et Debian avec apt policy nginx ou en demandant au prestataire, puis la comparer avec le tableau ci-dessus ou avec l’avis de la distribution.
3. Mettre à jour et redémarrer le service. Installer la mise à jour de sécurité de la distribution, ou la 1.30.6 ou ultérieure si nginx provient des paquets officiels de nginx.org, et vérifier que le service a bien été redémarré. Pour les images de conteneurs : mettre à jour l’image et recréer le conteneur.
4. Si la mise à jour n’est pas encore disponible (par exemple sur Debian 12 au moment de la publication) : faire vérifier la configuration par qui gère le serveur. Les failles dépendent de fonctions précises (HTTP/3, SSI avec entrées-sorties asynchrones, certificats client, certaines combinaisons d’alias et de rewrite) : désactiver ce qui n’est pas nécessaire réduit l’exposition en attendant le correctif.
5. Contrôler les journaux. Dans le journal d’erreurs de nginx, des redémarrages inattendus des processus worker peuvent signaler des tentatives avortées ou un problème à approfondir.

Nous ne publions pas de détails sur l’exploitation de ces failles : l’objectif est de mettre à jour et de vérifier les systèmes. Nous avons aussi traité les mises à jour des serveurs Ubuntu et Debian à propos de la faille dans APT.

Si le serveur a été compromis : signalements

• Protection des données (nLPD). Si le serveur contient des données personnelles (clients, formulaires, comptes) et que la violation entraîne vraisemblablement un risque élevé pour les personnes concernées, l’article 24 de la loi sur la protection des données prévoit l’annonce au PFPDT dans les meilleurs délais. Le guide du PFPDT explique comment évaluer le cas.
• OFCS. Pour la plupart des PME, signaler un cyberincident à l’OFCS est volontaire mais utile. Depuis le 1er avril 2025, les exploitants d’infrastructures critiques ont en revanche l’obligation de signaler les cyberattaques dans les 24 heures suivant leur découverte.
• Dommage financier. En cas de dommage, déposer plainte auprès de la police cantonale.

Questions fréquentes

Notre site est sur un hébergement mutualisé : devons-nous faire quelque chose ?

Le serveur est géré par le prestataire, qui doit appliquer les mises à jour. Il reste utile de demander par écrit si le serveur web utilise nginx et si les mises à jour d’octobre ont été installées.

Notre serveur utilise Apache : sommes-nous concernés ?

Ces failles ne concernent que nginx. Beaucoup d’installations utilisent toutefois nginx comme proxy devant Apache ou d’autres applications : cela vaut la peine de le vérifier.

nginx -v affiche une ancienne version : le serveur est-il vulnérable ?

Pas forcément. Sur les distributions Linux, c’est le numéro complet du paquet qui compte, car il inclut les correctifs reportés par la distribution. S’il correspond à celui de l’avis, le serveur est corrigé.

Nous n’utilisons ni HTTP/3 ni SSI : pouvons-nous ignorer la mise à jour ?

Non. Les failles touchent des fonctions différentes et il est facile de sous-estimer ce que contient une configuration qui a évolué au fil des ans. La mise à jour est le moyen le plus simple de corriger les cinq failles à la fois.

Notre approche

ElaraTeq Sagl aide les PME et cabinets au Tessin à gérer et mettre à jour leurs serveurs Linux et serveurs web, à héberger en Suisse et à configurer TLS (hébergement, conseil ; sur TLS, voir aussi les certificats à 100 jours). Pour faire contrôler votre serveur, vous pouvez nous contacter.

Sources

• nginx, nginx security advisories
• nginx, Changes with nginx 1.30.6, 14 octobre 2026
• NIST NVD, CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205
• Ubuntu, USN-8955-1: nginx vulnerabilities, 26 octobre 2026
• Debian, DSA-6575-1 nginx – security update et suivi CVE-2026-15176
• OFCS, Obligation de signaler les cyberattaques contre des infrastructures critiques
• PFPDT, Guide sur la notification des violations de la sécurité des données