Ah, NGINX. Ce fidèle serveur web qui alimente discrètement Internet, tel un ami fidèle toujours prêt à apporter des pizzas… jusqu'au jour où, par inadvertance, il inonde votre cuisine de code malveillant parce que quelqu'un a chuchoté le mauvais nom de variable. Mesdames et messieurs, bienvenue dans CVE-2026-8711, le dernier épisode du feuilleton sans fin intitulé « Comment avons-nous pu laisser les clients contrôler tout ça ? » Dans ce volet palpitant, des attaquants distants non authentifiés peuvent déclencher un dépassement de tampon basé sur le tas dans le module JavaScript (njs) de NGINX. Oui, vous avez bien lu. Votre proxy inverse sophistiqué, censé tout protéger, est désormais vulnérable à un classique « oups, j'ai dépassé le tas », pouvant entraîner de délicieuses attaques par déni de service et, sur les systèmes mal configurés (coucou les détracteurs de l'ASLR !), l'exécution de code à distance complète dans le processus worker.
Imaginez la scène : un administrateur bien intentionné active js_fetch_proxy avec des variables contrôlées par le client. Des petites choses innocentes comme $http_x_user ou $http_x_password. Parce que rien n'est plus « sécurisé » que de laisser des inconnus sur Internet contribuer à la construction de vos URL de proxy. Ensuite, ils connectent cela à une fonction NJS qui appelle ngx.fetch(). Et voilà ! C'est comme donner un lance-flammes à un enfant en bas âge en lui disant : « Surtout, ne le pointe pas vers les rideaux ! » Un attaquant conçoit une requête HTTP spéciale, et soudain, le processus NGINX rencontre de sérieux problèmes : la mémoire est corrompue, le processus plante, redémarre, plante à nouveau… C'est l'équivalent numérique de cet ami qui n'arrête pas de rafraîchir la page « par accident » pendant votre réunion Zoom importante. Une attaque par déni de service (DoS) menée avec panache.
Et si l'ASLR est désactivé ou mal configuré ? Félicitations ! Vous pourriez bien décrocher le gros lot : l'exécution de code arbitraire. Car pourquoi se contenter de serveurs en panne quand on peut les pirater avec des logiciels malveillants ?
CVE : CVE-2026-8711 (on dirait une chambre d’hôtel de luxe où le minibar regorge de failles de sécurité)
CWE : 122 – Dépassement de tampon basé sur le tas (le cas particulier du « je n’ai pas revérifié la taille »)
Concernées : les versions 0.9.4 à 0.9.8 de njs
Corrigé dans : njs 0.9.9 (oui, ils ont enfin compté jusqu'à 9 correctement)
F5, les fiers créateurs de NGINX, ont confirmé que la vulnérabilité est limitée au plan de données. Le plan de contrôle est hors de danger, probablement tranquillement installé dans son coin à siroter un café et à observer tout le monde. D'autres produits F5 importants, comme BIG-IP, ne semblent pas être concernés par cette faille de sécurité.
NGINX est réputé pour sa légèreté, sa rapidité et sa stabilité. Pourtant, en 2026, nous constatons encore que mélanger JavaScript, variables côté client et proxy est aussi risqué que de mélanger Red Bull, tequila et mauvaises décisions. Qui aurait pu prédire que laisser des inconnus influencer vos appels fetch() se terminerait si mal ? On dirait que les serveurs web oublient sans cesse la règle d'or : ne jamais faire confiance au client. Pas même un peu. Même s'il vous supplie de l'aider.
Que faire ? (À part rire ou pleurer)
Mettez à jour immédiatement votre version de NGINX JavaScript vers la version 0.9.9 ou une version plus récente. Oui, maintenant. Laissez tomber les mèmes et appliquez le correctif.
Si la mise à niveau est impossible (pour diverses raisons), vérifiez la configuration de `js_fetch_proxy` avec les variables client. Refactorisez ou supprimez ces éléments avant qu'une refonte complète de votre infrastructure ne soit entreprise.
Activez correctement l'ASLR. On est en 2026, les amis. Arrêtez de vivre comme en 1999.
En résumé, une nouvelle journée, une nouvelle erreur de dépassement de tampon qui nous rappelle que les logiciels ne sont qu'une façon élégante de dire « un tas de failles qui ne demandent qu'à être exploitées ». NGINX reste génial… quand il n'est pas en train de se détruire par une explosion de mémoire. Restez à jour, les amis. Et peut-être devriez-vous arrêter de laisser des en-têtes aléatoires construire vos URL. Ce n'est pas « dynamique », c'est « géré de manière dynamique ».
