Den 15 juli kom en rättning för kod skriven 2011

Den 15 juli 2026 släppte nginx-projektet versionerna 1.30.4 och 1.31.3, och den utgåvan stängde en heap-överskrivning som gick att nå i varje version tillbaka till 0.9.6. Den versionen är från 2011. Sårbarheten är registrerad som CVE-2026-42533 och bedöms till 9,2 på CVSS-skalan version 4.0. F5 publicerade rådet K000162097 för NGINX Plus-kunder, rättat i 37.0.3.1.

Listan över rapportörer är ovanlig. Fler än ett dussin forskare rapporterade samma problem oberoende av varandra, däribland Mufeed VH från Winfunc Research, och den mångårige underhållaren Maxim Dounin skötte rättningen. När ett fel hittas av så många samtidigt är det rimliga antagandet att det inte var svårt att hitta och att andra hittade det utan att lämna in någon rapport.

Vad som måste stå i din konfiguration för att det ska gälla

Felet sitter i skriptmotorn, som utvärderar de stränguttryck nginx bygger vid varje förfrågan. Den utvärderingen sker i två pass. Det första mäter hur stor en buffert behöver vara utifrån infångningsläget i det ögonblicket. Det andra skriver i bufferten med infångningsdata som förfrågan kan påverka. Där de två passen skiljer sig är skrivningen större än det utrymme som reserverats.

Utlösaren är snävare än versionsspannet antyder. Det krävs ett regex-baserat map-direktiv vars utdatavariabel refereras i ett stränguttryck efter en infångning från en tidigare regex-träff, de numrerade infångningarna skrivna som dollar-ett och dollar-två. Innehåller din konfiguration ingen regex-mapp av den formen placerar versionsnumret ensamt dig inte i den drabbade gruppen. Det är det mest användbara faktumet i hela publiceringen.

Utan inloggning, men ännu inte beväpnat

Där mönstret finns behöver förfrågan som utlöser det inga inloggningsuppgifter. En konstruerad HTTP-förfrågan från vilken punkt som helst på internet räcker. Det tillförlitliga utfallet är krasch och omstart av en arbetsprocess, alltså ett överbelastningsangrepp vid ytterdörren till det servern publicerar. Fjärrkörning av kod är det svårare fallet, möjligt där slumpmässig adressrymd är avstängd eller går att kringgå, och forskaren Stan Shaw hävdar att felet självt levererar vägen runt det skyddet.

Per den 20 juli finns ingen offentlig exploitkod och CVE:n står inte i den amerikanska katalogen över kända utnyttjade sårbarheter. Det är nuläget, inte en prognos. Shaw har aviserat en proof of concept 21 dagar efter att rättningen kom, vilket placerar den i augustis första vecka. En outnyttjad kritisk sårbarhet med ett publicerat datum är ett annat planeringsproblem än en utan.

Tre överskrivningar i ett delsystem på två månader

CVE-2026-42533 står inte ensam. Det är den tredje heap-överskrivningen som publicerats i nginx kod för utvärdering av uttryck på ungefär två månader, efter CVE-2026-42945 i maj och CVE-2026-9256 kort därefter. Tre fynd i ett delsystem på ett kvartal är ett mönster och inte en slump, och mönstret säger att tvåpasskonstruktionen just nu synas av folk som numera vet var de ska leta.

Följden för planeringen är tydlig. Den som behandlar detta som ett enskilt versionshopp och går vidare har en påtagligt skild från noll sannolikhet att stå här igen inom kvartalet. På bevakningslistan hör delsystemet hemma, inte CVE-numret, och det som varaktigt går att minska är de konfigurationsformer som når fram till det.

Kontrollen innan du ringer din leverantör

De flesta kritiska publiceringar om webbservrar lämnar en företagare beroende av andra. Denna gör inte det, eftersom utlösaren går att läsa i en fil du kan öppna. Be om din nginx-version och fråga sedan om något map-block i konfigurationen använder ett reguljärt uttryck och matar en variabel som senare kombineras i en sträng tillsammans med numrerade infångningar. Två frågor, ett svar, och du vet om början av augusti är en tidsfrist eller en anteckning.

För företag inom tillämpningsområdet för direktivet om nät- och informationssäkerhet i Europeiska unionen, och för dem som följer motsvarande brittiska vägledning, väger dokumentationen lika tungt som rättningen. Anteckna vilken version du körde, vilket datum du granskade konfigurationen och vilken åtgärd du tillämpade. En tillsynsmyndighet som frågar om en kritisk sårbarhet publicerad i juli vill ha datumet för din bedömning, inte bara datumet för den senare uppgraderingen.

Läs vidare: Fyra kodagenter tog sig ut utan att bryta sig ut  |  ServiceNow patchade sitt eget moln först, dig 103 dagar senare