NGINX corrige des failles permettant d'exécuter du code sur un serveur sans s'authentifier

NGINX a publié le 14 octobre les versions 1.30.6 (stable) et 1.31.7 (mainline), qui corrigent cinq vulnérabilités. Trois d'entre elles sont des erreurs de mémoire qu'un attaquant peut déclencher avec des requêtes HTTP spécialement forgées, sans s'authentifier. Dans le pire des cas, cela permet d'exécuter du code sur le serveur. F5, qui développe NGINX, note ces trois failles 9,2 sur 10 (critique) selon CVSS 4.0. Chacune n'est toutefois exploitable qu'avec une configuration précise : un serveur qui tourne sous NGINX n'est donc pas exposé d'office. F5 affirme ne connaître ni exploit public ni attaque.

Ce qui a été corrigé

Les trois failles graves dépendent de directives très courantes dans les configurations réelles :

Dans les trois premiers cas, le débordement fait planter un processus worker de NGINX, qui redémarre ensuite. Des requêtes répétées peuvent le provoquer en boucle : il s'agit donc au minimum d'un déni de service. Selon F5, l'exécution de code est possible sur les systèmes où la randomisation de l'espace d'adressage (ASLR) est désactivée, ou quand l'attaquant parvient à la contourner. Le bug lié à alias est présent dans le code depuis la version 0.1.29, sortie en 2005.

La faille des tickets de session est d'une autre nature. L'une des clés renouvelées n'était pas initialisée, et F5 indique qu'un attaquant pourrait forger une session TLS pour passer outre la vérification des certificats clients. C'est important pour les serveurs qui admettent des utilisateurs par certificat, comme les panneaux d'administration et les services internes.

Critique ou moyenne ?

Les deux évaluations semblent se contredire. Sur la page des avis de sécurité de nginx.org, les cinq failles sont classées « medium ». Dans les fiches CVE de F5, les trois erreurs de mémoire obtiennent 9,2 en CVSS 4.0 et 8,1 (élevée) en CVSS 3.1. L'écart vient des conditions. Le vecteur CVSS indique que l'attaque n'exige aucun compte mais présente une complexité élevée, puisqu'elle ne fonctionne que sur une configuration donnée. Security Affairs a publié le 16 octobre un article sur onze problèmes corrigés. Ce chiffre plus élevé dépasse NGINX lui-même : le même jour, F5 a livré des mises à jour pour des produits liés, dont le module de script njs, Ingress Controller et Gateway Fabric.

Comment vérifier votre propre serveur

NGINX se place devant de nombreux services auto-hébergés sur des serveurs loués : panneaux VPN et proxy, partages de fichiers, petits sites. Si vous en gérez un, deux commandes suffisent pour commencer. nginx -v affiche la version, et nginx -T | grep -nE 'alias|request_filename|aio|ssi |ssl_session_cache|ssl_session_ticket|map ' liste les directives du tableau dans toute la configuration chargée.

Le numéro de version seul peut tromper. Debian et Ubuntu conservent d'anciennes versions de NGINX et y ajoutent des correctifs de sécurité : « 1.22 » ou « 1.26 » sur un serveur ne dit donc rien sur la présence des corrections d'octobre. Le 17 octobre, le suivi de sécurité de Debian donnait encore les paquets bookworm et trixie comme vulnérables. Consultez le suivi de votre distribution et mettez à jour avec apt update && apt upgrade dès qu'un paquet corrigé paraît. Avec les paquets officiels de nginx.org, les versions corrigées sont 1.30.6 et 1.31.7.

En attendant un correctif, F5 recommande de modifier la configuration : éviter alias et $request_filename dans les blocs concernés, utiliser des captures nommées dans map à la place de $1 et $2, désactiver aio ou cesser de servir des pages SSI, et soit charger les clés de tickets depuis un fichier avec ssl_session_ticket_key, soit couper les tickets avec ssl_session_tickets off. Notre guide sur le durcissement d'un VPS traite le reste de l'hygiène de base d'un serveur.