w5m1n9/nginx-ngx_http_rewrite_module-heap-buffer-overflow-cve-2026-9256
Preuve de concept pour CVE-2026-9256, un débordement de tampon de tas dans le module ngx_http_rewrite_module de NGINX. Démontre le crash du worker et le déni de service via une URI conçue avec des groupes de capture PCRE qui se chevauchent. Inclut une vérification en plusieurs étapes et un sondage keep-alive.
Champ d'application : à utiliser uniquement sur des environnements de test locaux, des environnements de reproduction autorisés, pour la validation de vulnérabilités et l'analyse de règles de protection. Ne pas utiliser sur des cibles non autorisées. Le principe du PoC présenté dans ce document ne valide que le comportement de crash du worker NGINX observable à distance ; il n'inclut pas de RCE, de contournement d'ASLR ni de chaîne d'exploitation stable.
CVE-2026-9256 est une vulnérabilité de débordement de tas (heap buffer overflow) dans ngx_http_rewrite_module de NGINX. Le déclenchement de la vulnérabilité ne consiste pas simplement à accéder à un URI fixe, mais dépend d'un modèle de configuration rewrite spécifique : la regex de rewrite contient des groupes de capture PCRE se chevauchant, et la partie replacement référence plusieurs variables de capture, par exemple $1, $2.
Lorsqu'un attaquant construit un URI spécial qui fait entrer la logique de rewrite dans le chemin concerné, NGINX peut présenter une incohérence entre le calcul de longueur et l'écriture effective lors du traitement du contenu capturé, de la concaténation du résultat de rewrite ou de l'échappement URI/paramètres, ce qui finit par provoquer une corruption de la mémoire tas du processus worker.
Par conséquent, le point clé de cette vulnérabilité n'est pas le chemin /api en lui-même, mais l'existence ou non, dans la configuration NGINX cible, de règles rewrite vulnérables pouvant être atteintes par une requête. Le /api utilisé par défaut dans le PoC n'est qu'un chemin d'exemple de l'environnement de reproduction actuel ; lors des tests réels, le chemin de requête doit être ajusté en fonction des règles rewrite de la configuration NGINX qui contiennent des groupes de capture se chevauchant et référencent plusieurs variables de capture.
L'objectif du PoC actuel est de valider le comportement de crash du worker / déni de service. Il ne tente pas de construire un agencement précis du tas, ne tente pas d'écraser l'adresse de retour ou des pointeurs de fonction, et ne prouve pas l'exécution de code à distance. Les preuves stables observables côté distant sont principalement : la connexion de la requête de déclenchement est interrompue anormalement, puis le service NGINX reprend ses réponses, et les connexions keep-alive sont coupées par le crash du worker après le déclenchement.
Après le déclenchement de cette vulnérabilité, le résultat ne se manifeste pas nécessairement par un code de statut HTTP fixe 500, 502 ou 400. La raison est que le modèle master-worker de NGINX fait que, lorsqu'un processus worker plante, le master relance un nouveau worker. Le phénomène observé côté distant par l'attaquant n'est généralement pas une indisponibilité totale du service, mais plutôt une connexion soudainement interrompue, un dépassement de délai de lecture, une connexion réinitialisée, puis un nouvel accès à / qui renvoie une réponse normale.
Par conséquent, le PoC ne peut pas déterminer l'existence de la vulnérabilité uniquement à partir du code de statut HTTP d'une seule requête. Si l'on envoie une seule fois un URI long, que l'on voit la connexion s'interrompre et que l'on conclut directement « vulnérabilité présente », le risque de faux positif est élevé. Une interruption de connexion peut également provenir d'une instabilité réseau, d'un dépassement de délai du proxy, d'une requête bloquée par un équipement intermédiaire, d'une limitation de débit côté backend ou d'une fermeture proactive de la connexion par le serveur.
Par conséquent, le PoC doit être conçu comme une validation en plusieurs étapes :
Ce n'est que lorsque « connexion de déclenchement anormale + reprise du service ensuite + plusieurs interruptions keep-alive » apparaissent simultanément que l'on peut conclure de manière plus fiable à l'existence d'un comportement de crash du worker de type CVE-2026-9256.
Le chemin de déclenchement central du PoC actuel est :
GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1:19321
/api/ est la route d'exemple utilisée dans l'environnement de test actuel pour atteindre la règle rewrite ; un grand nombre de caractères + y est concaténé. Le nombre par défaut est de 4096.
Le choix de + repose principalement sur trois raisons.
Premièrement, + est un caractère URI valide ; lorsqu'il est envoyé via un client HTTP ordinaire, il n'est généralement pas tronqué ou réécrit de force comme le seraient des caractères tels que l'espace ou #. Par conséquent, le PoC actuel n'a pas besoin, contrairement à certaines vulnérabilités de contournement du request-target, d'utiliser un raw socket pour construire une ligne de requête invalide.
Deuxièmement, une longue répétition de caractères permet aux groupes de capture de rewrite d'obtenir une entrée suffisamment longue, ce qui amplifie la taille de sortie de la concaténation ou du traitement d'échappement du replacement ultérieur, rendant ainsi plus facile le déclenchement d'une incohérence entre le calcul de longueur et l'écriture effective.
Troisièmement, la structure du payload constitué de + répétés est simple, ce qui facilite son observation dans les captures de paquets, les journaux et les règles IDS, et permet aussi d'ajuster la longueur pour effectuer des tests de seuil.
Il faut toutefois noter que + n'est pas le seul caractère de déclenchement théorique de la vulnérabilité. La véritable condition de déclenchement reste « atteindre une configuration rewrite vulnérable + entrée pouvant entrer dans les groupes de capture concernés + traitement de la sortie de rewrite déclenchant le débordement de tas ». Selon l'environnement, la route de déclenchement, le type de caractères et le seuil de longueur peuvent tous devoir être ajustés.
Le PoC actuel choisit par défaut une grande quantité de + comme caractère de déclenchement, mais cela ne signifie pas que seul + peut déclencher le problème. + est simplement le caractère le plus adapté à un PoC générique, car il est relativement stable dans un URI, facilement envoyé par un client HTTP ordinaire, et sa signature dans les captures de paquets est claire.
D'un point de vue théorique, dès lors qu'un caractère entre dans la logique d'échappement NGX_ESCAPE_ARGS lors du traitement de rewrite par NGINX et passe de 1 octet original à 3 octets sous forme %XX, cela peut créer une différence où « la valeur de longueur calculée est inférieure à la valeur réellement écrite ». En d'autres termes, le point de déclenchement n'est pas essentiellement + lui-même, mais « l'apparition dense de caractères pouvant être échappés en mode args ».
Outre +, les caractères qui méritent théoriquement une attention particulière sont :
空格：0x20
#：0x23
%：0x25
&：0x26
?：0x3F
控制字符：0x00-0x1F
高位字节：0x7F-0xFF
Ces caractères, s'ils entrent dans la capture concernée et sont traités comme contenu args lors de l'échappement dans le replacement de rewrite, produiront tous un effet d'expansion similaire. Par exemple :
+ -> %2B
& -> %26
% -> %25
# -> %23
? -> %3F
空格 -> %20