Den 13. maj blev en sårbarhed rettet i den populære webserver nginx, der anvendes til belastede systemer: CVE-2026-42945, som potentielt kunne føre til RCE. Sårbarheden opstod for 18 år siden (2008) i version 0.6.27.
For at udnytte den, skal der være en bestemt kombination af direktiver i serverkonfigurationen; ikke alle har dem, men nogle steder kan de forekomme, for eksempel:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Vigtige detaljer:
- først kommer direktivet rewrite, hvor (den første argument) det regulære udtryk med den udvalgte parameter (noget i parentes) bliver erstattet med (det andet argument) en sti, der indeholder et spørgsmålstegn;
- direktivet set (i stedet kan også den anden rewrite eller if bruges), som anvender den valgte parameter fra den omdannede sti (i dette tilfælde $1).
Sårbarheden fungerer sådan:
- det første rewrite-direktiv, når det støder på et spørgsmålstegn, indstiller en intern flag is_args, der betyder "nu samler vi GET-parametre til den erstattede URL, alt skal escapes", og (det er kernen i fejlen) glemmer at nulstille dette flag ved slutningen af sit arbejde;
- det efterfølgende direktiv set, når det danner værdien for $myvar, anvender fejlagtigt det tidligere etablerede is_args og skriver den escaped værdi af den udvalgte parameter $1 i my_var; problemet er, at bufferen for $myvar allokeres tidligere, endnu før erstatningerne udføres, og dens længde beregnes med is_args=0, hvilket betyder, at den escaped værdi bliver længere end den allokerede buffer, hvilket skaber en skrivning uden for den afsatte buffer i andre datastukturer på serveren. For at dette kan ske, er det tilstrækkeligt at sende en forespørgsel med tegn, der skal escapes, for eksempel “plus”-symbolet, i området for den regulære udtryk parameter.
Hvis der ikke er ALSR på værten, kan denne sårbarhed udnyttes til fjernudførelse af kode med rettighederne til nginx-arbejdsprocessen, der er PoC (der er ikke en ren exploit, men en demonstration i en sandkasse).
Sårbarheden er blevet rettet i den stabile version af nginx 1.30.1 og den nye udviklingsversion 1.31.0. link til commit.
Det er bemærkelsesværdigt, at en lignende fejl for 14 år siden (2012) allerede blev rettet et andet sted i nærheden. в другом месте рядом.
——-
På F5's hjemmeside er der en anbefaling til midlertidigt at neutralisere sårbarheden, hvis det ikke er muligt at opdatere nginx-versionen hurtigt — det kræver, at anonyme parametre udskiftes med navngivne. I dette tilfælde vil sårbarheden ifølge dem ikke manifestere sig. Eksempel derfra:
var: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
blev: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
Information om sårbarheden blev givet af Zhenpeng (Leo) Lin fra DepthFirst. Desuden rapporterede han også om følgende problemer, som også er blevet løst:
- CVE-2026-40701 (commit) use-after-free ved brug af ssl_verify_client+ssl_ocsp (tilsyneladende uden RCE)
- CVE-2026-42934 (commit) læsning uden for buffer i utf-8 parseren under specifikke omstændigheder, som kan føre til en mindre datalækage eller crash af arbejdsprocessen
- CVE-2026-42946 (commit) overflødig hukommelsesallokering og læsning uden for bufferen ved brug af scgi/uwsgi moduler, problemet opstår ved tilstedeværelsen af en ondsindet backend (upstream) via de angivne protokoller, eller ved et man-in-the-middle angreb på kommunikationen med backenden, som kan føre til læsning af nginx's hukommelse eller crash af arbejdsprocessen
Kilde: linux.org.ru
