CVE-2026-42945: waarom deze NGINX-kwetsbaarheid SOC-aandacht verdient

Het eerste wat ik dacht toen ik CVE-2026-42945 voorbij zag komen: alweer een NGINX-bug? Tot ik de details in dook. Dit is geen abstracte CVSS-kriebel, dit is het type kwetsbaarheid waar je als SOC-analist 's nachts wakker van wordt. Een heap overflow die achttien jaar lang stilletjes in de rewrite-module van NGINX heeft gezeten, van versie 0.6.27 tot en met 1.30.0. Achttien jaar. Het security-platform DepthFirst ontdekte de bug, F5 gaf op 13 mei een advisory uit, en het NCSC volgde met NCSC-2026-0164. CVSS 8.1, HIGH.

Wat maakt dit nou echt zorgelijk? Het antwoord heeft drie lagen, en als SOC vind ik laag twee en drie vaak het interessants.

Eerste laag: versie. Draait er ergens NGINX tussen 0.6.27 en 1.30.0? Dan is de technische kwetsbaarheid aanwezig. De meeste organisaties checken niet verder dan dit.

Tweede laag: configuratie. Staan er kwetsbare rewrite-patronen in de NGINX-configuratie? De bug treedt op bij een specifiek patroon: een rewrite-directive met een unnamed PCRE-capture ($1, $2), een replacement string met een vraagteken (?), gevolgd door nog een rewrite, if of set-directive in dezelfde scope. NGINX berekent de buffergrootte met de ene set escaping-aannames maar schrijft met een andere, deterministische heap corruption. Dit patroon is veelvoorkomend. Dit bepaalt de praktische blootstelling.

Derde laag: runtime hardening. Staat ASLR uit? Dan wordt DoS opeens RCE. NVD en F5 bevestigen dat code execution haalbaar is op systemen zonder Address Space Layout Randomization. Dit raakt Alpine Linux-containers, Raspberry Pi's, embedded deployments, oude Linux-images. Controleer het zelf: cat /proc/sys/kernel/randomize_va_space moet 2 teruggeven.

Alleen naar de versie kijken is dus niet genoeg, je moet de configuratie en de runtime-hardening erbij pakken om het echte risico te bepalen.

Wat platformteams moeten doen: Patch naar NGINX Open Source 1.30.1 of 1.31.0. Voor NGINX Plus: R32 P6 of R36 P4. Herstart NGINX na de upgrade. Het vervelende scenario is natuurlijk als patchen niet direct kan. Gebruik dan named captures in plaats van unnamed captures ($1 → $named). Dat is een configuratie-mitigatie, geen structurele fix, koop er tijd mee, meer niet. Inventariseer álle NGINX-assets: reverse proxies, ingress controllers, appliances, containers, Plesk-panelen. Scan de configuraties. Prioriteer internet-facing systemen.

Wat SOC-teams moeten doen: Check NGINX access logs op afwijkende URI-lengtes, ongebruikelijke querystrings, plotselinge 400/500/502-pieken. Check error logs op worker process exited, segmentation fault, malloc- of free-fouten. Systemd/logind: herhaalde restarts, crash loops, core dumps. EDR/XDR: NGINX-workers die childprocesses starten, shell execution. Containers: pod restarts, liveness probe failures zonder duidelijke load-verklaring. De detectiehypothese? Wanneer NGINX-versie ≤ 1.30.0 én asset is internet-facing én error logs tonen crashes én access logs tonen afwijkende patronen, dan raise je een onderzoek.

Per 22 mei is er nog geen bevestigde actieve exploitatie in CISA KEV of NVD. Maar dit is precies het type bug dat de komende weken exploit code gaat krijgen. Dus doe het nu: inventariseren, patchen, configuraties nalopen, ASLR valideren. Geen paniek, wel discipline.

---

Bronnen:

• NVD, CVE-2026-42945, CVSS 8.1 HIGH, CWE-122 Heap-based Buffer Overflow
• F5 Networks, K000161019, NGINX ngx_http_rewrite_module vulnerability, fixed versions
• DepthFirst, NGINX Rift, technische writeup en discovery
• NCSC-NL, NCSC-2026-0164

---

DjimIT adviseert organisaties over vulnerability management, SOC-processen, en BIO2/NIS2 compliance. Heeft uw organisatie hulp nodig bij de prioritering en afhandeling van CVE-2026-42945? Neem contact op.