Faille nginx : comment savoir si votre site web est concerné ?

Le 15 juillet, pendant que les bureaux se vidaient pour l'été, un correctif critique est sorti pour nginx. Ce nom ne vous dit peut-être rien. Pourtant, ce logiciel fait tourner plus d'un site web sur trois dans le monde, et probablement le vôtre. C'est l'employé modèle de votre présence en ligne : il accueille chaque visiteur, jour et nuit, sans jamais poser de congés. La faille CVE-2026-42533 vient de montrer qu'il avait, lui aussi, un point faible. Cet article vous explique comment vérifier en quelques minutes si votre site est concerné, et comment appliquer la mise à jour sans interrompre votre activité.

Nginx : l'employé modèle que personne ne remarque

Un site web, c'est une vitrine. Derrière la vitrine, il y a quelqu'un qui ouvre la porte à chaque visiteur, lui apporte la bonne page et gère la file d'attente aux heures de pointe. Ce quelqu'un, dans plus d'un cas sur trois, s'appelle nginx (prononcez "engine-x").

Concrètement, nginx est un serveur web : le logiciel installé sur la machine qui héberge votre site. Il reçoit les demandes des navigateurs et renvoie les pages. Il est libre, robuste et discret : c'est précisément pour cela qu'on l'oublie. Beaucoup de dirigeants découvrent son existence le jour où il tombe.

Et c'est exactement ce que permet la faille corrigée le 15 juillet.

CVE-2026-42533 : ce que cette faille change concrètement

Derrière ce numéro se cache un défaut de gestion de la mémoire dans nginx : en envoyant des requêtes web spécialement construites, un attaquant peut provoquer un dépassement de mémoire (heap buffer overflow) dans le processus qui traite les visites.

Trois points la rendent sérieuse :

1. Aucun mot de passe n'est nécessaire. L'attaquant n'a besoin d'aucun accès préalable : il lui suffit de pouvoir joindre votre site, comme n'importe quel visiteur.
2. La conséquence immédiate est la panne. Le processus qui sert vos pages plante ou redémarre en boucle. Vu de vos clients : votre site ne répond plus.
3. Dans certains cas, l'attaquant peut aller plus loin et exécuter du code sur votre serveur. Autrement dit, transformer une panne en intrusion.

L'éditeur F5 a publié les versions corrigées le 15 juillet : nginx 1.30.4, nginx 1.31.3 et NGINX Plus 37.0.3.1. Toute version antérieure est potentiellement exposée.

Pas de panique pour autant : une faille corrigée est une faille qui se gère. À condition de savoir où on en est.

Comment savoir si votre site utilise nginx

Deux minutes, vraiment.

Si vous gérez vous-même votre serveur. Connectez-vous et tapez la commande nginx -v. Elle affiche la version installée. Si elle est inférieure à 1.30.4 (branche stable) ou 1.31.3 (branche principale), notez-le : il y a une mise à jour à faire.

Si votre site est hébergé chez un prestataire. C'est le cas le plus fréquent. Depuis n'importe quel ordinateur, on peut interroger les en-têtes techniques que votre site renvoie, par exemple avec la commande curl -I https://votresite.fr. Si la réponse contient la mention "nginx", vous savez qu'il est en première ligne. La version exacte, elle, est souvent masquée : il faudra poser la question à votre hébergeur.

Un piège classique à connaître. Sur les serveurs Debian ou Ubuntu, le numéro de version peut être trompeur : ces distributions corrigent parfois les failles sans changer le numéro principal. Un nginx affiché "1.24" peut donc être corrigé... ou pas. La seule preuve fiable : le journal des modifications du paquet, ou la confirmation écrite de votre hébergeur.

Mettre à jour sans couper votre site

Bonne nouvelle : nginx est conçu pour être mis à jour sans interruption visible. La procédure, dans les grandes lignes :

1. Sauvegardez la configuration, c'est-à-dire le dossier /etc/nginx sur la plupart des serveurs. Deux minutes qui évitent des heures.
2. Installez la version corrigée via le gestionnaire de paquets de votre système, ou depuis les dépôts officiels de nginx si vous voulez la version 1.30.4 exacte.
3. Testez la configuration avec nginx -t avant tout redémarrage. Cette commande vérifie que rien ne bloquera au démarrage.
4. Rechargez en douceur avec nginx -s reload : nginx sait passer le relais aux nouveaux processus sans fermer les connexions en cours. Vos visiteurs ne voient rien.

Deux pièges méritent le détour :

• Les modules complémentaires. Si votre nginx embarque des modules tiers (pare-feu applicatif, géolocalisation, cache avancé), ils doivent être compatibles avec la nouvelle version. C'est le point qui transforme une mise à jour de dix minutes en chantier d'une journée quand on le découvre trop tard.
• Les conteneurs. Si votre site tourne dans Docker, mettre à jour le serveur hôte ne suffit pas : c'est l'image du conteneur qu'il faut reconstruire avec la version corrigée, puis redéployer.

Combien coûte l'inaction : un exemple chiffré

Prenons une entreprise réaliste : une boutique en ligne qui réalise 600 000 euros de chiffre d'affaires annuel, soit environ 1 650 euros par jour.

Son site tombe un vendredi soir d'août, mis KO par un simple script qui balaie le web à la recherche de versions vulnérables : ces balayages automatisés commencent en général quelques jours après la publication d'une faille. Le prestataire habituel est en congés, le remplaçant met deux jours à diagnostiquer puis corriger.

Le calcul est vite fait : deux jours de ventes perdues (3 300 euros), une dizaine d'heures d'intervention en urgence (environ 1 200 euros), et des clients partis chez un concurrent dont personne ne mesurera jamais le nombre exact. Total : plus de 4 500 euros, sans compter l'image.

La mise à jour préventive, elle, représente une à deux heures de travail planifié. Le rapport est de un à vingt. Et encore : c'est le scénario où l'attaquant s'est contenté de faire tomber le site, sans chercher à entrer.

Les trois questions à poser à votre prestataire informatique

Vous n'avez pas besoin d'être technicien pour piloter ce sujet. Trois questions suffisent, et les réponses vous en diront long :

1. "Quelle version de nginx fait tourner notre site, et est-elle corrigée contre la CVE-2026-42533 ?" Une réponse précise sous 48 heures est bon signe. Un silence prolongé l'est moins.
2. "Comment êtes-vous informés des failles critiques sur les logiciels que vous gérez pour nous ?" Un prestataire sérieux suit les bulletins de sécurité et n'attend pas votre appel pour agir.
3. "À quelle fréquence appliquez-vous les mises à jour de sécurité, et est-ce prévu dans notre contrat ?" C'est souvent là que les surprises se cachent : la maintenance est parfois une option du contrat, jamais relue, rarement souscrite.

Si ces trois réponses arrivent vite et par écrit, vous êtes bien entouré. Sinon, vous venez d'apprendre quelque chose d'utile.

Faire de l'été un allié plutôt qu'un angle mort

Les failles ne prennent pas de vacances : celle-ci est justement tombée un 15 juillet. Mais l'été reste la bonne saison pour s'en occuper, précisément parce que l'activité ralentit : moins de trafic sur le site, moins de pression sur les équipes, une fenêtre idéale pour planifier les mises à jour et relire ce que couvre vraiment votre contrat de maintenance avant la rentrée.

Chez Autensai, nous aidons les entreprises françaises à faire ce point : vérifier l'exposition de leurs sites et serveurs, appliquer les correctifs sans coupure, et mettre en place le suivi qui évite de revivre la même histoire à chaque nouvelle faille. Si vous voulez en parler posément, prenons trente minutes ensemble : prendre rendez-vous.

Votre employé modèle ne demandera jamais d'augmentation. Accordez-lui au moins sa mise à jour : c'est sa façon à lui de partir en vacances.