Failles critiques NGINX : trois CVE à corriger d'urgence sur votre VPS

Le 14 octobre 2026, F5 a publié un correctif hors cycle pour trois vulnérabilités critiques affectant NGINX Open Source, NGINX Plus, NGINX Ingress Controller et NGINX Gateway Fabric. Classées CVSS v4.0 9.2 (CVSS v3.1 8.1) chacune, ces failles exploitent des heap buffer overflows (CWE-122) et un use-after-free (CWE-416) dans le module HTTP core et la directive map. Un attaquant distant peut provoquer un crash du worker NGINX (déni de service) ou, dans certaines conditions, exécuter du code sur le serveur. Si vous administrez un VPS Linux ou un serveur dédié avec NGINX en reverse proxy ou en serveur web, la mise à jour est prioritaire.

Source : advisory F5 K000163408 (14 octobre 2026).

Le rôle de NGINX sur un VPS ou un serveur dédié

NGINX est le serveur web le plus déployé sur les machines virtuelles Linux. Sur un VPS typique, il assure plusieurs fonctions : servir les fichiers statiques d'un site, agir en reverse proxy devant une application PHP-FPM (WordPress, un CMS ou un script PHP personnalisé), ou relayer les connexions TCP vers une base de données MySQL, PostgreSQL ou un service interne. De nombreux administrateurs l'utilisent aussi pour la terminaison TLS de leur nom de domaine, la résolution DNS upstream, ou comme proxy SMTP devant un serveur d'emails Postfix. Sur les distributions Ubuntu, Debian ou CentOS, NGINX s'installe en un seul package via le gestionnaire de paquets, ce qui explique sa présence sur la majorité des VPS en production.

Les trois CVE publiées par F5 touchent le coeur du processus worker NGINX. Toute machine virtuelle ou serveur physique qui expose NGINX sur une adresse IP publique est potentiellement vulnérable, que le serveur héberge un site web, un panel d'administration, un serveur de jeu ou un service interne.

Les trois CVE critiques en détail

F5 a publié trois advisories distincts le 14 octobre 2026, tous notés Critical (CVSS v4.0 9.2). Voici ce que chacun exploite et dans quelles conditions.

CVE-2026-15176 : heap buffer overflow via alias et $request_filename

Cette faille se situe dans le module HTTP core (ngx_http_core_module). Lorsqu'une configuration NGINX combine la directive alias avec rewrite, set ou return en référençant la variable $request_filename, ou lorsque cette variable apparait dans une directive log_format, le worker NGINX écrit au-delà des limites d'un buffer alloué sur le tas (heap). Un paquet HTTP spécialement forgé déclenche le débordement, entrainant un crash du processus worker ou, potentiellement, l'exécution de code arbitraire sur le serveur. Les versions legacy depuis 0.1.29 jusqu'à 0.9.9 sont également affectées par cette CVE.

CVE-2026-93479 : heap buffer overflow via la directive map et les captures regex

Le problème apparait lorsqu'un bloc map utilise un matching par expression régulière et que la directive root ou le format des logs d'accès référence des captures regex non nommées ($1, $2) avant la variable de sortie du map. L'évaluation des expressions de chaines contenant ces variables provoque un heap buffer overflow dans le worker NGINX. Le crash est reproductible à distance par une requête HTTP ciblée.

CVE-2026-97205 : use-after-free avec AIO et SSI

Lorsque l'I/O asynchrone (aio) est activée et qu'une page contient des inclusions SSI (include virtual), le traitement de la réponse peut déclencher un use-after-free dans le worker NGINX. Le processus accède à une zone mémoire déjà libérée, ce qui corrompt la mémoire et provoque un crash. Cette faille nécessite une config spécifique (AIO + SSI actifs simultanément), mais cette combinaison existe dans de nombreux déploiements.

Produits et versions affectés

Les trois CVE touchent un large spectre de versions. Voici le récapitulatif par produit :

En pratique, si votre VPS ou serveur dédié fait tourner NGINX, il y a de fortes chances que la version installée soit concernée par au moins l'une des trois failles. Cela vaut aussi pour les serveurs gérés par un panel comme Plesk, qui utilise NGINX en frontal.

Vérifier votre version de NGINX en ligne de commande

Connectez-vous en SSH à votre serveur VPS et vérifiez la version installée :

nginx -v

Le résultat affiche la version de NGINX sous la forme nginx version: nginx/1.30.5. Comparez cette version avec le tableau ci-dessus. Si elle est antérieure à 1.31.7 (mainline) ou 1.30.6 (stable), votre serveur est vulnérable.

Pour les utilisateurs de NGINX Plus, vérifiez avec :

nginx -v 2>&1 | grep -i plus

Vérifiez également quels modules sont actifs dans votre configuration. La commande suivante liste les modules compilés :

nginx -V 2>&1 | tr ' ' '\n' | grep module

Mettre à jour NGINX sur votre VPS

La méthode dépend de la façon dont NGINX a été installé sur votre serveur Linux et de la distribution utilisée. Sur la majorité des VPS sous Ubuntu ou Debian, la mise à jour se fait via le gestionnaire de paquets APT.

Ubuntu et Debian (APT)

Mettez à jour la liste des paquets et installez la version corrigée :

sudo apt update && sudo apt upgrade -y nginx

CentOS, Rocky Linux et Fedora (DNF/YUM)

Sur les distributions basées sur Red Hat, le package NGINX se met à jour via dnf (ou yum sur CentOS 7) :

sudo dnf upgrade -y nginx

Si le dépôt par défaut de votre distribution ne propose pas encore la version corrigée, ajoutez le dépôt officiel NGINX. Les instructions sont disponibles dans la documentation officielle NGINX.

Vérification et rechargement

Après la mise à jour du package, vérifiez que la version installée correspond bien à la version corrigée, puis rechargez la config NGINX pour appliquer la mise à jour sans interrompre les connexions TCP actives :

nginx -v
sudo nginx -t && sudo systemctl reload nginx

La commande nginx -t valide la syntaxe des fichiers de configuration avant le rechargement. En cas d'erreur, corrigez le fichier config concerné (souvent dans /etc/nginx/conf.d/ ou /etc/nginx/sites-enabled/) avant de relancer.

Pour automatiser les futures mises à jour de sécurité sur votre VPS Ubuntu, configurez unattended-upgrades avec le dépôt NGINX inclus.

Mitigations temporaires par CVE

Si la mise à jour immédiate n'est pas possible (contrainte de compatibilité, environnement de production critique), des mitigations de configuration réduisent l'exposition. Chaque CVE a sa propre mitigation.

CVE-2026-15176 : éviter alias avec $request_filename

Remplacez les directives alias par root dans les blocs location concernés. Si alias est indispensable, supprimez toute référence à $request_filename dans les directives rewrite, set, return et log_format du même contexte :

# Avant (vulnérable)
location /static/ {
    alias /var/www/assets/;
    set $debug $request_filename;
}

# Après (mitigé)
location /static/ {
    root /var/www;
    # Plus de référence à $request_filename
}

CVE-2026-93479 : utiliser des captures regex nommées

Dans vos blocs map utilisant des expressions régulières, remplacez les captures non nommées ($1, $2) par des captures nommées ($nom). Cela empêche le débordement de buffer lors de l'évaluation des variables :

# Avant (vulnérable)
map $uri $backend {
    ~^/api/(.*)$ $1;
}

# Après (mitigé)
map $uri $backend {
    ~^/api/(?<path>.*)$ $path;
}

CVE-2026-97205 : désactiver AIO ou SSI

Si votre configuration active simultanément aio et ssi, désactivez l'un des deux dans les blocs concernés :

# Désactiver AIO
aio off;

# OU désactiver SSI
ssi off;

Après toute modification de configuration, validez la syntaxe et rechargez NGINX :

sudo nginx -t && sudo systemctl reload nginx

Ces mitigations sont des palliatifs. La mise à jour vers NGINX 1.31.7 ou 1.30.6 reste la solution définitive.

Impact sur les serveurs de jeu et services hébergés

Si vous utilisez NGINX comme reverse proxy devant un serveur de jeu (FiveM, Minecraft, Rust) ou devant un panel d'administration comme Pterodactyl ou txAdmin, votre serveur est exposé dès qu'il accepte des connexions HTTP. Un attaquant n'a pas besoin d'être authentifié : une requête HTTP forgée suffit pour déclencher le crash du worker.

Les conséquences concrètes :

• Déni de service : le crash du worker NGINX interrompt le reverse proxy. Les joueurs et administrateurs perdent l'accès au panel web et aux services exposés en HTTP/HTTPS. Les scripts de monitoring et les connexions FTP ou SSH ne sont pas directement affectés, mais le serveur web reste inaccessible.
• Exécution de code : dans le pire cas, un attaquant exploite le heap overflow pour exécuter du code avec les privilèges du processus NGINX (généralement www-data ou nginx). Combiné à une élévation de privilèges locale, cela peut compromettre l'ensemble du serveur, y compris les bases de données MySQL ou PostgreSQL, les scripts Python, les données utilisateur et les fichiers de config.

Protégez votre serveur avec un pare-feu nftables (firewall) pour limiter les ports exposés et filtrer le trafic entrant par adresse IP. Fail2ban peut compléter cette protection en détectant les requêtes HTTP anormales dans les logs NGINX.

NGINX ou Apache : ces failles concernent-elles les deux ?

Les trois CVE sont spécifiques à NGINX. Si votre VPS utilise le serveur web Apache plutôt que NGINX, vous n'êtes pas concerné par ces failles. Apache et NGINX couvrent des cas d'usage similaires (héberger un site, proxyer du PHP-FPM, terminer le TLS d'un nom de domaine), mais leurs architectures sont très différentes : Apache utilise un modèle à threads/processus par connexion, tandis que NGINX fonctionne en boucle événementielle asynchrone avec des workers. C'est précisément le traitement asynchrone des buffers dans les workers NGINX qui est à l'origine des heap overflows et du use-after-free. Cela ne signifie pas qu'Apache est plus sûr dans l'absolu : chaque serveur web a ses propres CVE. Maintenez à jour Apache comme NGINX, quelle que soit la distribution (Ubuntu, Debian, CentOS, Rocky Linux).

Bonnes pratiques de sécurité NGINX sur VPS

Au-delà de la mise à jour immédiate, ces failles rappellent l'importance d'une hygiène de sécurité rigoureuse pour tout admin de serveur NGINX en production :

• Mises à jour régulières : automatisez les mises à jour de sécurité pour appliquer les correctifs dès leur publication, sans dépendre d'une vérification manuelle.
• Accès SSH renforcé : sécurisez l'accès SSH avec une authentification par clé et la désactivation du login root. Un serveur compromis via NGINX peut être pivoté pour attaquer le SSH.
• Configuration minimale : désactivez les modules NGINX dont vous n'avez pas besoin. Moins de modules actifs signifie moins de surface d'attaque. SSI et AIO ne sont nécessaires que dans des cas spécifiques.
• Firewall : limitez les adresses IP autorisées à se connecter aux ports d'administration. Un pare-feu bien configuré empêche un attaquant externe de cibler directement l'adresse IP de votre VPS sur les ports NGINX non publics.
• Surveillance : surveillez les ressources (RAM, CPU) de votre serveur. Des redémarrages fréquents des workers NGINX dans les logs (/var/log/nginx/error.log) peuvent indiquer une tentative d'exploitation. Un crash worker consomme du CPU au redémarrage et peut saturer la RAM si les requêtes s'accumulent.
• Backup : sauvegardez vos configurations et données critiques avant toute mise à jour. Versionnez vos fichiers de config NGINX avec Git pour pouvoir revenir en arrière en cas de régression.
• TLS à jour : renouvelez vos certificats TLS automatiquement. Un certificat expiré combiné à une faille NGINX aggrave l'exposition.
• Ports et services : listez les ports en écoute sur votre serveur avec ss -tlnp. Désactivez tout service inutile (serveur FTP, SMTP non utilisé) pour réduire la surface d'attaque.

Cas particuliers : Plesk, hébergement mutualisé et infogérance

Si votre serveur utilise Plesk, sachez que le panel déploie NGINX en frontal par défaut. La mise à jour de NGINX se fait alors via Plesk Updates, pas directement en ligne de commande. Vérifiez dans l'interface admin de Plesk que la version NGINX proposée intègre bien les correctifs 1.31.7 ou 1.30.6.

Sur un hébergement mutualisé, c'est l'hébergeur qui gère la couche NGINX. Vous n'avez pas d'accès SSH ni de contrôle sur la version du serveur web. Contactez votre hébergeur pour confirmer que le correctif a été appliqué. Sur un VPS ou un serveur dédié, la responsabilité vous revient : c'est la contrepartie de la virtualisation et de l'accès root.

Si vous bénéficiez d'une infogérance, vérifiez que votre prestataire a bien déployé le correctif. Ces CVE étant critiques (CVSS 9.2), elles justifient une mise à jour hors cycle, même sur un serveur Unix en production stable.

Questions fréquentes

Retrouvez ci-dessous les réponses aux questions les plus courantes des administrateurs de serveurs concernant ces vulnérabilités NGINX.

Conclusion

Les trois CVE critiques publiées par F5 le 14 octobre 2026 (CVE-2026-15176, CVE-2026-93479, CVE-2026-97205) touchent la quasi-totalité des installations NGINX en production. Les versions corrigées sont NGINX Open Source 1.31.7 (mainline) et 1.30.6 (stable), et NGINX Plus 37.1.0.1 ou 37.0.5.1. Si vous administrez un VPS Linux avec NGINX, vérifiez votre version avec nginx -v et appliquez la mise à jour via votre gestionnaire de paquets. En attendant, les mitigations par CVE (remplacer alias, utiliser des captures nommées, désactiver AIO ou SSI) réduisent l'exposition. Aucun exploit public n'a été signalé à la date de publication de cet article, mais l'exploitation à distance est possible : ne tardez pas à corriger. Pour aller plus loin, consultez nos tutoriels d'administration de VPS Linux.