Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
nginx-map-risk-audit — 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. | Kitploit
Outils/GitHubGitHub/srkyn/nginx-map-risk-audit
Scanners de VulnérabilitésAnalyse des VulnérabilitésAudit de ConfigurationSécurité WebApprentissage et ÉducationRéponse aux IncidentsAnalyse de JournauxLabs et Pratique
GitHubsrkyn/nginx-map-risk-audit

nginx-map-risk-audit

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.

115il y a 2 moisPas encore vérifié
Voir le dépôt
Site web

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2026-42533 : Examen du risque Regex Map de NGINX

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.

Scanner demo

Pourquoi c'est important

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é.

Triage de l'exposition

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.

  1. Le binaire NGINX en cours d'exécution se trouve-t-il dans une plage amont affectée, en tenant compte des rétroportages de la distribution ?
  2. La configuration active utilise-t-elle map avec des entrées d'expressions régulières ?
  3. Les captures d'expressions régulières mappées alimentent-elles des expressions de chaîne ultérieures dans un ordre qui peut changer entre les phases de longueur et de copie ?
  4. Des redémarrages suspects de workers, des boucles de crash ou le signal d'erreur de la version corrigée 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.

Aperçu du workflow

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"]

Contenu du dépôt

  • 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.

Éléments probants

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

Workflow défensif

  1. Inventorier les versions de NGINX en cours d'exécution.
  2. Vérifier si votre fournisseur a rétroporté le correctif.
  3. Rechercher dans les configurations actives les blocs map avec regex.
  4. Examiner si les captures et les sorties de map apparaissent dans des expressions de chaîne ultérieures.
  5. Appliquer le correctif vers 1.30.4+ ou 1.31.3+, ou la version corrigée NGINX Plus correspondante.
  6. Redémarrer ou recharger les workers et confirmer que le binaire corrigé est bien en cours d'exécution.
  7. Surveiller les redémarrages de workers, les pics de requêtes et no buffer space in script copy après l'application du correctif.

Sources

  • NGINX security advisory page: https://nginx.org/en/security_advisories.html
  • NGINX changelog: https://nginx.org/en/CHANGES
  • NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-42533
  • Penligent technical explainer: https://www.penligent.ai/hackinglabs/cve-2026-42533/
Télécharger l’outil