18-årigt RCE i nginx (CVE-2026-42945)

Den 13 maj åtgärdades en sårbarhet i den populära webbservern nginx för tunga system: CVE-2026-42945, som potentiellt kan leda till RCE. Sårbarheten uppstod för 18 år sedan (2008) i version 0.6.27.

För att utnyttja den krävs en viss kombination av direktiv i serverkonfigurationen, inte nödvändigtvis för alla, men förekommande ibland, till exempel:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;

Väsentliga detaljer:

• först kommer direktivet rewrite, där (den första argumentet) ett reguljärt uttryck med en markerad parameter (något inom parenteser) ersätts med (den andra argumentet) en väg som innehåller ett frågetecken;
• direktivet set (istället kan den andra rewrite eller if också användas), som använder den markerade parametern från den ursprungliga skrivna vägen (i det här fallet $1).

Sårbarheten fungerar så här:

• det första rewrite-direktivet, när det stöter på ett frågetecken, sätter en intern flagga is_args, vilket betyder "nu samlar vi in GET-parametrar för den skrivna URL:en, allt måste escaping", och (detta är kärnan i felet) glömmer att återställa denna flagga i slutet av sin bearbetning;
• det följande direktivet set, när det formar värdet för $myvar, tillämpar felaktigt den tidigare inställda is_args, och skriver in my_var det escaping-värde som den markerade parametern $1; problemet är att bufferten för $myvar tilldelas tidigare, redan före genomförandet av substitutionerna, och dess längd beräknas med is_args=0, vilket innebär att det escaping värdet blir längre än den tilldelade bufferten, vilket gör att skrivning sker utanför den tilldelade bufferten in i andra serverdatastrukturer. För att detta ska hända är det tillräckligt att skicka en begäran med tecken som ska escaping, till exempel plustecken, på platsen för den markerade parametern i det reguljära uttrycket.

Om det inte finns någon ALSR på värden kan denna sårbarhet utnyttjas för fjärrkodexekvering med rättigheterna för nginx-arbetsprocessen, det finns PoC (det är inte ett rent exploit, utan en demonstration i sandlådan).

Sårbarheten har åtgärdats i stabila grenen av nginx 1.30.1, och i den nya utvecklarversionen 1.31.0. länk till commit.

Anmärkningsvärt är att för 14 år sedan (2012) har ett liknande fel redan åtgärdats på ett annat ställe i närheten.

——-

På F5:s webbplats finns en rekommendation för tillfällig neutralisering av sårbarheten om det inte går att snabbt uppdatera versionen av nginx – man bör byta ut obenämnda parameterar till benämnda, och i det fallet, enligt deras uppgifter, kommer sårbarheten att inte uppträda. Exempel därifrån:
var: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
blev: rewrite ^/users/(?[0-9]+)/profile/(?