Säkerhetshål från 2010 i NGINX kan ge angripare fullständig kontroll – under vissa förutsättningar
Fjorton år gammalt säkerhetshål i NGINX ger angripare fullständig kontroll.
En tickande bomb i världens webbinfrastruktur
NGINX är inte vilken programvara som helst. Webbservern driver en stor del av internets infrastruktur – från gigantiska streamingtjänster till statliga myndigheter och nystartade techbolag. Det gör nyheten om sårbarheten CVE-2026-42945 särskilt allvarlig: ett fel som introducerades i kodbasen redan 2010 har nu fått sin exploateringskod publicerad öppet, vilket drastiskt sänker tröskeln för angrepp.
Enligt SecurityWeek har F5, företaget bakom NGINX, åtgärdat bristen i sin kvartalsvisa säkerhetsuppdatering. Men i det korta fönster mellan publicering av exploateringskoden och faktisk uppdatering hos alla berörda organisationer öppnas ett riskfönster som angripare gärna utnyttjar.
Vad är egentligen felet?
Tekniskt sett rör det sig om en så kallad heapbuffertöverskridning i modulen ngx_http_rewrite_module – den del av NGINX som hanterar URL-omskrivning. Riskpoängen är satta till 9,2 av 10 på CVSS-skalan, vilket placerar sårbarheten i kategorin kritisk.
Säkerhetsföretaget Depthfirst har analyserat rotorsaken i detalj. Problemet uppstår i serverns skriptmotor, som arbetar med ett tvåstegsförfarande: ett steg beräknar hur mycket minnesutrymme som krävs, och ett annat steg kopierar faktisk data till det utrymmet. Låter logiskt – men om ett omskrivningsmönster innehåller ett frågetecken förändras motorns interna tillstånd mellan de två stegen på ett sätt som koden inte hanterar korrekt. Resultatet: för lite minne avsätts, och bufferten skrivs över.
Konsekvenserna varierar beroende på systemkonfiguration:
- I grundläget kan en angripare tvinga servern att krascha och starta om – ett klassiskt angreppssätt för att sabotera tillgänglighet.
- Om minnesskyddsmekanismen ASLR är inaktiverad kan angriparen gå längre och uppnå fullständig fjärrkörning av godtycklig kod – det vill säga ta över systemet helt.
Sexton år av tyst risk
Det som verkligen stannar kvar är tidsperspektivet. Det här felet har funnits i NGINX sedan 2010. Det innebär att otaliga versionsuppgraderingar, säkerhetsgranskningar och kodinspektioner har genomförts under åren – utan att felet upptäcktes eller åtgärdades.
Det är inte unikt. Som systemutvecklare vet jag att den här typen av subtila minneshanteringsfel är notoriskt svåra att hitta. De uppstår inte alltid vid uppenbara indata, de kräver specifika förutsättningar för att triggas, och de lever gärna i moduler som anses vara stabila och välbeprövade. Precis av den anledningen granskas de sällan med samma skärpa som ny kod.
Detta är en strukturell utmaning i hur vi hanterar teknisk skuld i kritisk infrastrukturprogramvara. Äldre kodbaser bär på historiska antaganden som inte längre håller – och ju fler system som bygger ovanpå dem, desto svårare blir det att motivera djupa granskningar.
Vad behöver du göra nu?
Om din organisation kör NGINX är budskapet enkelt: uppdatera omedelbart. F5:s patch finns tillgänglig, och med exploateringskod ute i det fria är det inte längre ett teoretiskt hot.
Darefter är det värt att ställa bredare frågor:
- Hur ser ert patchningsförfarande ut för kritisk infrastrukturprogramvara?
- Har ni kontroll på vilka NGINX-moduler som faktiskt är aktiverade i produktion?
- Är minnesskyddsmekanismer som ASLR aktiverade på era servrar?
Det är också ett utmärkt tillfälle att påminna sig om värdet av automatiserad sårbarhetsskanning integrerad i driftsättningskedjan. Verktyg som kontinuerligt jämför era beroenden mot kända sårbarhetsregister hade i bästa fall flaggat för detta direkt när patchen släpptes – långt innan säkerhetsteamet hann läsa nyhetsbrevet.
En bransch som lär sig
Det positiva – och det finns ett – är att säkerhetsekosystemet runt öppen källkod har blivit betydligt mer moget de senaste åren. Initiativ som Googles Open Source Security Foundation och ökad finansiering till kritiska projekt har höjt ribban för proaktiv säkerhetsgranskning. Den här typen av djupanalys från företag som Depthfirst är ett tecken på att branschen tar sitt ansvar på allvar.
Men det räcker inte att hitta felen. Vi behöver också bli bättre på att faktiskt rulla ut patchar – snabbt, konsekvent och utan undantag.
Vår analys
Den här händelsen illustrerar en av de svåraste utmaningarna i modern systemsäkerhet: det vi inte vet att vi inte vet. NGINX är extremt välgranskad programvara med ett stort aktivt community, ändå låg det här felet orört i 16 år.
När exploateringskod publiceras öppet förändras hotbilden fundamentalt. Det som tidigare krävde avancerad teknisk kompetens blir tillgängligt för betydligt fler aktörer – inklusive sådana utan djup säkerhetsexpertis. Tidsmarginalen för att agera krymper från veckor till dagar, ibland timmar.
Framöver tror jag att vi kommer se AI-assisterad kodgranskning spela en allt viktigare roll för att hitta just den här typen av subtila minnesfel i äldre kodbaser. Stora språkmodeller tränade på säkerhetsmönster börjar visa lovande resultat för statisk analys. Det är inte en silverkula – men som komplement till mänsklig granskning kan det bli en spelväxlare för hur vi hanterar teknisk skuld i kritisk infrastruktur.