
Audit défensif des risques liés aux regex map NGINX CVE-2026-42533 avec scanner de configuration, notes Splunk/Defender et preuves de laboratoire.
Note de recherche défensive sur CVE-2026-42533, un débordement de tas dans le traitement des requêtes de NGINX lié aux directives map avec des captures d'expressions régulières et certains modèles d'évaluation de variables.
En termes simples : NGINX est un serveur web et un logiciel de proxy inverse. Il se place souvent devant les sites web et les API, accepte les requêtes web et décide où les envoyer. Une règle map est une fonctionnalité de configuration NGINX qui dit « si cette valeur de requête ressemble à X, définit cette variable sur Y ». Les captures d'expressions régulières sont les morceaux de texte extraits d'une correspondance de motif.
Cette CVE est importante car certaines versions plus anciennes de NGINX peuvent traiter incorrectement un type spécifique de combinaison de map et de variables. Cela ne signifie pas que chaque serveur NGINX est exposé. La version importe, mais la configuration active aussi.
Ce projet est intentionnellement sûr : il n'inclut pas de trafic d'exploitation, de charges utiles de crash ou de sondage en production. L'objectif est de montrer comment je trierais l'exposition, d'expliquer le risque et de fournir aux défenseurs un chemin de validation reproductible.

NGINX liste le problème comme un avis de sécurité majeur : les versions vulnérables sont 0.9.6-1.31.2, les versions corrigées sont 1.30.4+ et 1.31.3+. Le journal des modifications de NGINX décrit un débordement de tas dans un processus worker lorsqu'une directive map utilise une correspondance regex et que la variable map est incluse dans une expression de chaîne après une capture affectée par cette map.
Le NVD enregistre la description F5 : un attaquant non authentifié peut déclencher le problème avec des requêtes HTTP malveillantes, mais seulement lorsque la configuration et les conditions d'exécution s'alignent. L'impact direct attendu est le redémarrage du worker NGINX et un déni de service, avec une possible exécution de code si ASLR est désactivé ou contourné.
Les défenseurs doivent répondre à quatre questions avant de considérer un déploiement NGINX comme exposé. En résumé : d'abord confirmer la version, puis confirmer si le motif de configuration risqué est effectivement présent.
map avec des entrées d'expressions régulières ?no buffer space in script copy sont-ils visibles dans les journaux ?Si ces termes sont nouveaux : un worker est le processus NGINX qui gère les requêtes. Une boucle de crash ou un signal de redémarrage signifie que le processus peut échouer et redémarrer. Un rétroportage de distribution signifie que les fournisseurs Linux corrigent parfois une version d'apparence ancienne sans changer le numéro de version pour la dernière version amont.
flowchart LR
advisory["Read advisory and changelog"] --> version["Check NGINX version"]
version --> config["Review active config"]
config --> scanner["Run safe map-pattern scanner"]
scanner --> validate["Validate fixed build or vendor patch"]
validate --> hunt["Hunt restart and diagnostic signals"]
hunt --> remediate["Patch, reload, and document"]
scripts/audit_nginx_map_risk.py
Un scanner heuristique défensif pour les fichiers de configuration NGINX. Il recherche les blocs map avec regex, les captures et les expressions de chaîne ultérieures qui référencent les captures et les sorties de map. Il ne prouve pas qu'un serveur est exploitable. Il trouve des configurations méritant un examen humain.
scripts/render_demo_gif.py
Reconstruit le petit GIF de démonstration du README à partir de la sortie réelle du scanner.
detections/splunk_nginx_cve_2026_42533.spl
Recherches Splunk pour l'inventaire des versions, les symptômes de crash/redémarrage et les chaînes de diagnostic post-patch.
detections/defender_hunting_notes.kql
Notes de chasse Microsoft Defender pour les hôtes Linux où les journaux NGINX et l'activité des processus sont collectés.
detections/sigma_nginx_worker_restart_symptoms.yml
Règle de chasse Sigma pour les symptômes de redémarrage ou de crash de worker NGINX. C'est une piste pour examen, pas une preuve d'exploitation.
samples/nginx_map_patterns.conf
Exemples de configuration schématiques et sûrs pour expliquer le motif de risque. Ce ne sont pas des charges utiles d'exploitation.
SECURITY.md
Note de périmètre pour le dépôt. Cela maintient le projet clairement défensif et sûr à examiner.
lab/windows-quickstart.ps1
Exécuteur d'éléments probants adapté à Windows qui exécute le scanner et enregistre la sortie dans evidence/.
lab/windows-nginx-validation.ps1
Télécharge la version officielle corrigée de NGINX pour Windows, valide une configuration locale de laboratoire avec nginx -t, exécute le scanner et enregistre les éléments probants.
lab/vmware-lab-notes.md
Parcours de laboratoire plus complet optionnel pour une VM Linux jetable si une procédure pas à pas basée sur des captures d'écran est nécessaire ultérieurement.
La validation locale actuelle est stockée dans evidence/. Le démarrage rapide Windows exécute le scanner sur l'exemple de configuration inclus et enregistre la transcription. La validation Windows NGINX télécharge la version officielle corrigée de NGINX, confirme la configuration de laboratoire avec nginx -t, et exécute le scanner. La validation Kali VM exécute le même scanner dans une invite Kali VMware jetable. Cela prouve que le dépôt est exécutable et révisable sous Windows et Linux tout en maintenant le projet dans une limite défensive.
powershell -ExecutionPolicy Bypass -File .\lab\windows-quickstart.ps1
powershell -ExecutionPolicy Bypass -File .\lab\windows-nginx-validation.ps1
python .\scripts\self_check.py
map avec regex.1.30.4+ ou 1.31.3+, ou la version corrigée NGINX Plus correspondante.no buffer space in script copy après l'application du correctif.