Nginx stă în fața unei părți uriașe din aplicațiile web ale lumii — ca reverse proxy, load balancer sau ingress controller. Exact de aceea CVE-2026-42533, corectată de F5 pe 15 iulie, merită primul loc pe lista de patch-uri a acestei săptămâni: un atacator de la distanță, neautentificat, poate declanșa un heap buffer overflow în procesul worker nginx folosind doar cereri HTTP special construite.
F5 evaluează vulnerabilitatea la 9.2 pe CVSS v4. Impactul confirmat este denial of service — worker-ul se oprește sau se restartează — dar F5 precizează că acolo unde ASLR este dezactivat sau poate fi ocolit, este posibilă execuția de cod la distanță. Unul dintre cercetătorii care au raportat problema, Stan Shaw („cyberstan"), merge mai departe: susține că același bug scurge date neinițializate din heap, oferind atacatorului exact adresele de memorie de care are nevoie un payload — ceea ce ar face exploatabilă o instalare implicită de Ubuntu 24.04 cu un singur GET neautentificat. În cuvintele lui: „Cine citește advisory-ul F5 ar putea conchide, în mod rezonabil, că pe sisteme implicite e doar DoS. Nu este."
De ce e diferită: contează configurația, nu doar versiunea
Toate versiunile nginx de la 0.9.6 până la 1.31.2 conțin codul vulnerabil — un interval care merge înapoi până în 2011. Dar bug-ul devine accesibil doar într-un tipar de configurare specific: un map bazat pe regex a cărui variabilă de ieșire este folosită într-o expresie de tip string împreună cu o captură numerotată ($1, $2) dintr-un regex anterior, cu captura scrisă înaintea variabilei din map.
Cauza stă în motorul de scripting „în două treceri" al nginx. Prima trecere măsoară câți octeți are rezultatul și alocă un buffer; a doua trecere scrie octeții. Evaluarea regex-ului din map între cele două treceri suprascrie starea comună a capturilor — astfel bufferul este dimensionat pentru o valoare și umplut cu alta, controlată de atacator. Atât lungimea, cât și conținutul depășirii vin direct din cerere.
Este al treilea heap overflow în codul de evaluare a expresiilor din nginx în circa două luni, după Rift (CVE-2026-42945, exploatat activ la câteva zile după publicarea PoC-ului) și un bug de capturi suprapuse în modulul rewrite (CVE-2026-9256). Același motor, aceeași clasă de vulnerabilitate, trei declanșatoare diferite.
Ce faci acum
- Actualizează. Versiunile corectate sunt nginx 1.30.4 (stable), 1.31.3 (mainline) și NGINX Plus 37.0.3.1. Atenție: advisory-ul F5 listează ca afectate și NGINX Ingress Controller, Gateway Fabric, App Protect WAF și Instance Manager, pentru care la momentul publicării nu existau încă build-uri corectate — urmărește-le separat.
- Auditează configurațiile. Expunerea de căutat este îngustă și poate fi găsită cu grep: un
mapcu regex a cărui variabilă apare într-o expresie string alături de o captură numerotată dintr-un regex anterior. Cercetătorul care a raportat bug-ul a publicat un scanner de configurații care urmărește include-urile și semnalează doar ordinea exploatabilă. Verifică toate locurile unde trăiesc configurații nginx — containere, definiții de ingress și imagini de bază, nu doar/etc/nginxde pe serverele clasice.
- Dacă nu poți face patch imediat, mitigarea temporară recomandată de F5 este trecerea map-urilor regex afectate pe capturi numite (named captures). Există însă o notă importantă: cercetătorul raportează o a doua cale de cod care atinge același overflow atunci când un map definește același grup numit ca regex-ul din location. Singura remediere completă este actualizarea.
- Pune-ți un termen. PoC-ul va fi publicat la 21 de zile după patch. Cronologia lui Rift — exploit public în câteva zile, exploatare activă imediat după — este șablonul realist pentru ce urmează.
Perspectiva NIS 2
Dacă organizația ta intră sub NIS 2, această vulnerabilitate este un test perfect pentru două obligații deodată. Prima: gestionarea vulnerabilităților — reverse proxy-urile și ingress controllerele sunt expuse la internet prin definiție, deci o vulnerabilitate critică pre-autentificare la acest nivel intră pe banda cea mai rapidă de patching; a fi cu o versiune în urmă pe un echipament de margine este un risc fundamental diferit față de o aplicație internă. A doua: pregătirea pentru incidente — o flotă de workeri care se prăbușesc înseamnă întreruperea serviciului, iar dacă exploatarea duce la un incident semnificativ, pornește ceasul de 24 de ore pentru avertizarea timpurie. Să știi de azi ce sisteme rulează nginx, în ce versiuni și configurații, este ceea ce face ambele obligații realizabile.
Ar fi prins un pentest această problemă?
Zero-day-ul în sine, nu — dar nu asta e ideea. Ce prinde un test de penetrare pe infrastructură sau o evaluare de securitate web bine făcută este postura din jur, cea care transformă un astfel de bug într-un incident: interfețe de administrare expuse, versiuni vechi, reguli WAF lipsă, configurații nerevizuite din 2019 și lipsa unui inventar a ceea ce este efectiv expus la internet. Iar când apare un CVE ca acesta, o evaluare de vulnerabilități recentă este ceea ce îți permite să răspunzi la „suntem afectați?" într-o oră, nu într-o săptămână.
Dacă nu ești sigur că infrastructura ta nginx — sau restul perimetrului — nu ascunde tipare de configurare riscante, merită să afli înainte să apară PoC-ul. Contactează-ne și te ajutăm să verifici.
Acest articol este informare generală bazată pe raportări publice ale F5, nginx.org și The Hacker News, nu consultanță de răspuns la incidente pentru un mediu specific.