srkyn/nginx-map-risk-auditAudit difensivo dei rischi della regex map NGINX CVE-2026-42533 con scanner di configurazione, note Splunk/Defender ed evidenze di laboratorio.
Nota di ricerca difensiva su CVE-2026-42533, un heap buffer overflow nell'elaborazione delle richieste NGINX legato alle direttive map con catture regex e ad alcuni schemi di valutazione delle variabili.
In parole semplici: NGINX è un software di web server e reverse proxy. Si trova spesso davanti a siti web e API, accetta richieste web e decide dove inviarle. Una regola map è una funzionalità di configurazione NGINX che dice «se questo valore della richiesta assomiglia a X, imposta questa variabile su Y». Le catture regex sono i frammenti di testo estratti da una corrispondenza di pattern.
Questa CVE è importante perché alcune versioni meno recenti di NGINX possono gestire in modo errato un tipo specifico di combinazione tra map e variabili. Ciò non significa che ogni server NGINX sia esposto. La versione conta, ma anche la configurazione attiva conta.
Questo progetto è intenzionalmente sicuro: non include traffico di exploit, payload di crash o sondaggi su ambienti di produzione. L'obiettivo è mostrare come farei il triage dell'esposizione, spiegare il rischio e fornire ai difensori un percorso di validazione ripetibile.
NGINX segnala il problema come advisory di sicurezza importante: le versioni vulnerabili sono 0.9.6-1.31.2, le versioni corrette sono 1.30.4+ e 1.31.3+. Il changelog di NGINX descrive un heap buffer overflow in un processo worker quando una direttiva map utilizza il matching regex e la variabile della mappa viene inclusa in un'espressione stringa dopo una cattura influenzata da quella mappa.
NVD riporta la descrizione di F5: un attaccante non autenticato può innescare il problema con richieste HTTP appositamente create, ma solo quando configurazione e condizioni di runtime combaciano. L'impatto diretto atteso è il riavvio del worker NGINX e il denial of service, con possibile esecuzione di codice se ASLR è disabilitato o aggirato.
I difensori dovrebbero rispondere a quattro domande prima di considerare esposta una distribuzione NGINX. In parole semplici: prima confermare la versione, poi confermare se il pattern di configurazione rischioso è effettivamente presente.
map con voci regex?no buffer space in script copy sono visibili nei log?Se questi termini sono nuovi: un worker è il processo NGINX che gestisce le richieste. Un crash loop o un segnale di riavvio significa che il processo potrebbe fallire e ripartire. Un backport di distribuzione significa che i vendor Linux a volte applicano patch a una versione dall'aspetto meno recente senza portare il numero di versione alla più recente release upstream.
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
Uno scanner euristico difensivo per file di configurazione NGINX. Cerca blocchi map regex, catture e successive espressioni stringa che fanno riferimento a catture e output delle mappe. Non dimostra che un server sia sfruttabile. Individua configurazioni che meritano una revisione umana.
scripts/render_demo_gif.py
Ricostruisce la piccola GIF demo del README a partire dall'output reale dello scanner.
detections/splunk_nginx_cve_2026_42533.spl
Ricerche Splunk per inventario versioni, sintomi di crash/riavvio e stringhe diagnostiche post-patch.
detections/defender_hunting_notes.kql
Note di hunting per Microsoft Defender su host Linux in cui vengono raccolti i log NGINX e l'attività dei processi.
detections/sigma_nginx_worker_restart_symptoms.yml
Regola di hunting Sigma per sintomi di riavvio o crash dei worker NGINX. È uno spunto per la revisione, non una prova di sfruttamento.
samples/nginx_map_patterns.conf
Esempi di configurazione sicuri e schematici per spiegare il pattern di rischio. Non sono payload di exploit.
SECURITY.md
Nota sull'ambito del repository. Mantiene il progetto chiaramente difensivo e sicuro da revisionare.
La validazione locale corrente è archiviata in evidence/. Il quickstart Windows esegue lo scanner sulla configurazione di esempio inclusa e salva la trascrizione. La validazione NGINX Windows scarica la build ufficiale corretta di NGINX, conferma la configurazione di laboratorio con nginx -t ed esegue lo scanner. La validazione su VM Kali esegue lo stesso scanner all'interno di una guest VMware Kali usa e getta. Questo dimostra che il repository è eseguibile e revisionabile sia su Windows sia su Linux, mantenendo il progetto entro un confine difensivo.
powershell -ExecutionPolicy Bypass -File .\lab\windows-quickstart.ps1
powershell -ExecutionPolicy Bypass -File .\lab\windows-nginx-validation.ps1
python .\scripts\self_check.py
map regex nelle configurazioni attive.1.30.4+ o 1.31.3+, oppure alla corrispondente release corretta di NGINX Plus.no buffer space in script copy dopo la patch.lab/windows-quickstart.ps1
Runner di evidenze per Windows che esegue lo scanner e salva l'output in evidence/.
lab/windows-nginx-validation.ps1
Scarica la build ufficiale corretta di NGINX per Windows, valida una configurazione di laboratorio locale con nginx -t, esegue lo scanner e salva le evidenze.
lab/vmware-lab-notes.md
Percorso di laboratorio opzionale più completo per una VM Linux usa e getta se in seguito servirà una procedura basata su screenshot.