NGINX en 2026
control API, njs 1.0 et cinq CVE en une sortie

Où en est NGINX en 2026

Deux branches cohabitent, comme depuis toujours : 1.30.x en stable et 1.31.x en mainline. Au 30 octobre 2026, la dernière stable est nginx-1.30.6 (14 octobre) et la mainline nginx-1.31.8 (21 octobre). Une production qui n'a pas de raison particulière de bouger reste sur la stable ; la mainline sert à tester ce qui arrivera dans six mois.

Les trois nouveautés qui changent l'exploitation

• La control API (mainline 1.31.5, septembre), reconfigurer un serveur d'instance sans le couper ni réécrire un fichier. Sur un parc, cela remplace la génération de configuration suivie d'un reload par un appel surveillé, avec un retour en arrière immédiat si le changement est mauvais.
• Les predicate locations exprimer une condition directement dans la déclaration d'un emplacement, au lieu d'empiler des if et des variables intermédiaires. Toute personne qui a maintenu une configuration de 600 lignes sait ce que cela enlève comme source d'erreur.
• Le module ngx_http_json_module produire du JSON depuis la configuration elle-même, sans passer par un script. Utile pour les points de santé et les métriques internes, qui étaient jusqu'ici le prétexte à un module tiers.

njs passe en version 1.0

Le moteur de script embarqué de NGINX, celui qui permet d'écrire des règles en JavaScript sans sortir de la configuration, atteint la version 1.0 (1.0.1 puis 1.0.2 en octobre). C'est une étape symbolique : le langage est considéré comme stable. Il reste que toute logique embarquée est du code exécuté à chaque requête : elle se teste, se versionne et se limite à ce qui ne peut pas être fait autrement.

HTTP/3 : mature, mais à surveiller

QUIC et HTTP/3 sont désormais des options de production chez la plupart des hébergeurs. La contrepartie est la même que pour tout protocole jeune : la surface d'attaque bouge. La sortie du 14 octobre corrige ainsi une injection de corps de requête en HTTP/3 (CVE-2026-95101), en même temps que quatre autres failles.

La cadence de sécurité, en une ligne de temps

Source : nginx.org/2026.html et les avis de sécurité de l'éditeur.

Cinq CVE en une seule sortie, ce n'est pas un signe de faiblesse : c'est le rythme normal d'un logiciel exposé à Internet, maintenu par une petite équipe et audité par beaucoup de monde. Ce qui compte, c'est la vitesse à laquelle on applique, et le fait de savoir qu'on a appliqué.

Ce que nous faisons d'un NGINX en production

• Une version épinglée, jamais la mainline on suit la stable de la distribution ou du dépôt officiel, et on note la version dans le dossier du client.
• TLS durci et HSTS protocoles et suites explicitement listés, redirection permanente, en-têtes de sécurité. Un frontal web qui parle encore TLS 1.0 est un problème avant d'être une performance.
• Limitation de débit et taille de requête limit_req, client_max_body_size, délais courts : trois directives qui évitent beaucoup d'incidents.
• Des journaux exploitables un format qui permet de compter les erreurs par service, pas seulement de les afficher. Sans cela, la supervision ne peut rien dire.
• Un reload, pas un restart recharger la configuration ne coupe pas les connexions en cours ; redémarrer le service, si.

Ce que nous ne faisons pas

Nous n'ajoutons pas de module tiers non suivi sur un frontal exposé, nous ne compilons pas un NGINX à la main pour gagner « quelques pour cent », et nous ne laissons pas une configuration générée par un outil atterrir en production sans relecture. Un frontal web est la porte d'entrée : il doit être ennuyeux, prévisible et à jour.