Kritisk nginx-hull rammer alle versjoner siden 2011
Oppgrader nginx til 1.30.4 eller 1.31.3 hvis konfigurasjonen din bruker en regex-basert map sammen med nummererte capture-variabler.
CVE-2026-42533 scorer 9,2 på CVSS v4, og hver eneste nginx-versjon fra 0.9.6 til og med 1.31.2 er sårbar. Det spennet går tilbake til 2011, da map fikk støtte for regulære uttrykk. F5 slapp rettelsen 15. juli i nginx 1.30.4 (stable), 1.31.3 (mainline) og NGINX Plus 37.0.3.1, skriver The Hacker News.
Feilen sitter i nginx sin script-motor, koden som setter sammen strenger fra direktiver mens forespørselen behandles. Motoren går to runder: første runde måler hvor mange byte resultatet trenger og allokerer en buffer, andre runde skriver bytene inn. Begge leser samme delte capture-tilstand, og hvis en map-regex evalueres mellom rundene, blir tilstanden overskrevet. Bufferen dimensjoneres for ett treff og fylles med et annet, og både lengden og innholdet på overskuddet kommer rett fra forespørselen.
Det betyr at sårbarheten ikke rammer alle nginx-servere. Eksponeringen avhenger av konfigurasjonen, ikke bare versjonsnummeret: du må ha en regex-basert map hvis variabel brukes i et strenguttrykk sammen med en nummerert capture ($1, $2) fra et tidligere regex-treff, med capturen skrevet før map-variabelen.
F5 beskriver konsekvensen som tjenestenekt, med kodekjøring som en mulighet dersom ASLR er slått av eller kan omgås. En av de over et dusin forskerne som meldte inn feilen uavhengig av hverandre, Stan Shaw, mener rådgivningen underdriver.
«En leser av F5s rådgivning kan med rimelighet konkludere med at dette bare er tjenestenekt på standardsystemer. Det er det ikke.» Stan Shaw, sikkerhetsforsker, til The Hacker News
Argumentet hans er at feilen leverer ASLR-omgåelsen selv: når den overskrevne capturen er mindre enn den opprinnelige, returnerer den for store bufferen uinitialisert heap-data, og på en standard Ubuntu 24.04-bygg skal én uautentisert GET være nok til å hente ut adressene et angrep trenger. Shaw holder tilbake både detaljer og proof-of-concept i 21 dager etter patchen, så påstanden kan foreløpig ikke etterprøves av andre. F5 takket på sin side forskerne for å ha «uavhengig gjort oss oppmerksom på dette problemet», og nginx sin egen changelog krediterer Mufeed VH i Winfunc Research og vedlikeholder Maxim Dounin for rettelsen.
Dette er den tredje heap-overflowen i nginx sin uttrykksevaluering på rundt to måneder, etter Rift (CVE-2026-42945) i mai og en feil med overlappende captures i rewrite-modulen (CVE-2026-9256) dager senere. Alle tre er samme feilklasse: to-pass-motoren måler i én runde og skriver i neste, og skrivingen løper fra målingen. Rift er også advarselen om tempo. Den fikk offentlig exploit-kode i løpet av dager, og aktiv utnyttelse kort tid etter.
Per 20. juli sto CVE-2026-42533 ikke på CISA sin KEV-katalog, og ingen offentlig exploit hadde dukket opp.
Hva bør du gjøre?
- Oppgrader til 1.30.4 eller 1.31.3, eller NGINX Plus 37.0.3.1. Shaw mener dette er den eneste komplette rettelsen.
- Søk gjennom konfigurasjonen etter mønsteret hvis du ikke kan patche i dag: en regex-basert
maphvis variabel opptrer i et strenguttrykk sammen med$1eller$2fra et tidligere regex-treff. - Behandle F5 sin midlertidige mitigering, å bytte til navngitte captures, som en delvis løsning. Shaw dokumenterer en variant der en map som definerer samme navngitte gruppe som location-regexen når fram til samme overflow gjennom en annen kodesti.
- Sjekk NGINX Ingress Controller, Gateway Fabric, App Protect WAF og Instance Manager separat. F5 lister dem som berørt, men hadde ikke oppgitt rettede bygg for dem da saken ble publisert.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.