O cerere HTTP aparent banală poate deveni o poartă către executarea de cod pe un server. Nu pentru că utilizatorul ar cunoaște parola administratorului și nici pentru că ar exista o problemă în formularul de autentificare. În cazul vulnerabilității Node2Shell (CVE-2026-111497), punctul slab se află într-o componentă care decomprimă datele primite de aplicație.
Credit imagine principală: The Hacker News.
Pe 21 octombrie 2026, proiectul Node.js a lansat actualizări de securitate pentru ramurile 22, 24 și 26. Pe 22 octombrie, cercetătorii Imperva au prezentat o demonstrație de executare a codului pe un build oficial Node.js 24.22.0 pentru Linux ARM64. Informația a fost relatată pe 23 octombrie și de The Hacker News.
Cea mai importantă întrebare pentru utilizatorii obișnuiți și pentru administratorii de site-uri este însă alta: cine poate lansa un astfel de atac și ce condiții trebuie îndeplinite?
Ce înseamnă, de fapt, „date Brotli”?
Atunci când un browser și un server comunică, informațiile pot fi comprimate pentru a circula mai repede și pentru a consuma mai puțină lățime de bandă. Brotli este un algoritm de compresie folosit în acest scop. Nu este un virus și nici un format de fișiere suspect: în mod normal, ajută internetul să funcționeze mai eficient.
Imaginează-ți un document mare împachetat într-un colet mic. Serverul primește coletul și trebuie să îl desfacă pentru a citi documentul. Operația de „desfacere” este decomprimarea.
Problema Node2Shell apare atunci când acel colet este construit intenționat cu o structură invalidă. Decoderul Brotli din anumite versiuni Node.js poate continua prelucrarea deși ar trebui să oprească procesul cu o eroare. În acel moment, poate scrie date în afara spațiului de memorie alocat, fenomen numit out-of-bounds write. În anumite condiții, coruperea memoriei poate fi transformată în remote code execution (RCE) — executarea de instrucțiuni alese de atacator pe server.
Nu discutăm despre un simplu text introdus într-un câmp de formular, ci despre conținutul binar al unui flux comprimat, fabricat special pentru a provoca eroarea decoderului.
Este necesar un cont sau autentificarea pe site?
Nu neapărat. Iar în configurațiile expuse, atacul poate avea loc înainte de autentificare.
Să luăm un exemplu obișnuit: o aplicație Node.js folosește Express 5 și primește date JSON de la vizitatori. Pentru a înțelege conținutul cererilor, dezvoltatorul a activat un parser precum express.json(). În Express 5, aceste parsere pot decomprima și corpuri de cereri HTTP transmise cu antetul Content-Encoding: br.
Dacă parserul este disponibil pe o rută accesibilă publicului și decomprimă mesajul înainte ca aplicația să verifice identitatea solicitantului, atacatorul poate ajunge la componenta vulnerabilă fără nume de utilizator, parolă sau sesiune autentificată.
Un exemplu de flux arată astfel:
- O persoană de pe internet trimite o cerere HTTP către un endpoint public care acceptă date.
- În locul unui corp obișnuit, cererea transportă date Brotli special construite.
- Aplicația, prin middleware-ul configurat, încearcă să decomprime conținutul înainte de prelucrarea propriu-zisă.
- Dacă este folosit un runtime vulnerabil și sunt îndeplinite condițiile exploitului, eroarea din decoder poate duce la coruperea memoriei și, potențial, la executarea de cod.
Atenție: acesta este un scenariu posibil, nu o afirmație că orice formular sau orice rută publică este vulnerabilă. Ordinea middleware-urilor, tipul de conținut acceptat, filtrele intermediare și configurarea aplicației influențează dacă datele ajung sau nu la decoder.
De asemenea, un simplu server HTTP scris în Node.js nu decomprimă automat orice cerere Brotli. Este necesar un mecanism care invocă decoderul — de exemplu un parser configurat, o bibliotecă sau un apel explicit.
Dar dacă serverul nu acceptă cereri Brotli de la utilizatori?
Există o a doua cale, mai puțin evidentă: răspunsurile primite de la alte servere.
Multe aplicații Node.js comunică în permanență cu servicii externe: API-uri, servicii de conversie, agregatoare de date, furnizori de informații sau alte componente ale aceleiași platforme. Funcția integrată fetch() poate primi un răspuns comprimat Brotli și îl poate decomprima.
Dacă un atacator controlează sursa răspunsului, reușește să compromită un serviciu apelat de aplicație sau poate determina aplicația să descarce conținut de la o adresă aflată sub controlul său, datele malițioase pot ajunge la decoder pe această cale.
În această situație, atacatorul nu trebuie neapărat să trimită direct o cerere specială către serverul victimă. Dar trebuie să existe o posibilitate reală de influențare a răspunsului consumat de aplicație. Vizitarea site-ului, de una singură, nu demonstrează această posibilitate.
Această distincție este importantă și pentru protecțiile de tip WAF: un filtru instalat în fața site-ului poate bloca anumite cereri de intrare, dar nu vede în mod necesar răspunsurile pe care aplicația le primește atunci când ea însăși face solicitări către internet.
Ce au demonstrat efectiv cercetătorii Imperva?
Echipa Imperva a testat vulnerabilitatea pe imaginea oficială Node.js 24.22.0 pentru Linux ARM64, fără să modifice binarul ca să faciliteze atacul.
Cercetătorii au trimis date Brotli special construite către aplicații de test și au urmărit un indicator simplu: apariția unui fișier pe care codul legitim al aplicației nu avea motiv să îl creeze. Fișierul a apărut, ceea ce a demonstrat executarea unui cod suplimentar în procesul Node.js.
Testele au acoperit două situații:
- răspunsuri HTTP comprimate, prelucrate prin funcția integrată fetch();
- cereri HTTP primite de aplicații configurate cu Express 5 și parsere de corpuri de cerere, inclusiv raw() și json().
Imperva a verificat configurații selectate din familiile Express 5.0.0–5.3.0 și body-parser 2.0.0–2.3.0. Nu fiecare versiune intermediară a fost testată separat. În același timp, experimentele au necesitat mai multe încercări pentru reușită.
Pe versiunea reparată, Node.js 24.22.1, același conținut Brotli a fost respins, fără executarea codului din experiment. Este o diferență relevantă între o ipoteză teoretică și un rezultat verificat pe un build oficial.
Trebuie păstrată și limita demonstrației: Imperva a confirmat exploatarea în configurațiile sale Linux ARM64, nu a demonstrat separat compromiterea tuturor arhitecturilor și tuturor aplicațiilor Node.js. Până la momentul cercetării publicate, nu era confirmată o campanie de exploatare activă în mediul real.
Ce poate obține un atacator dacă exploatarea reușește?
Expresia RCE înseamnă că atacatorul poate executa cod în contextul procesului vulnerabil. Din acel moment, consecințele depind foarte mult de permisiunile cu care rulează aplicația și de accesul ei către alte sisteme.
În funcție de configurație, impactul posibil include:
- Furt de informații: citirea fișierelor și a datelor la care procesul are acces, inclusiv, în anumite configurații, variabile de mediu, chei API și tokenuri.
- Acces la baze de date: utilizarea credențialelor aplicației pentru a citi, modifica sau șterge date, în limita drepturilor acordate.
- Modificarea aplicației: alterarea fișierelor sau a comportamentului serviciului, dacă procesul are permisiuni de scriere.
- Întreruperea funcționării: blocarea procesului, consum de resurse sau întreruperi ale serviciului.
- Deplasare în infrastructură: încercarea de a accesa alte servicii interne pe care serverul le poate contacta.
Într-un container Docker sau într-un pod Kubernetes, executarea codului are loc inițial în contextul acelui container sau proces. Nu înseamnă automat că atacatorul obține acces root pe host ori controlul întregului cluster. Totuși, un container care deține secrete sensibile, volume montate, permisiuni extinse sau acces larg în rețea poate amplifica semnificativ pagubele.
Și aici este diferența dintre risc și fapt demonstrat: cercetătorii au demonstrat executarea de cod, nu că au furat efectiv datele unei companii sau că au preluat un cluster real.
Sunt vulnerabile toate aplicațiile Next.js, Express sau NestJS?
Nu se poate spune asta numai pe baza numelui framework-ului. Problema este în decoderul Brotli inclus în anumite versiuni ale runtime-ului Node.js. Framework-ul și bibliotecile determină dacă inputul neîncrezut ajunge la acel decoder.
O aplicație Express 5 cu parser Brotli activ pe rute accesibile reprezintă un caz relevant, confirmat de testele publicate. Pentru Next.js, NestJS sau alte soluții care folosesc Node.js, trebuie examinate separat versiunea runtime-ului, middleware-urile, funcțiile de decomprimare și solicitările către servicii externe.
Nici instalarea unei versiuni noi de Express nu garantează corectarea problemei, dacă aplicația continuă să ruleze pe un Node.js vulnerabil. Corecția principală este în runtime.
De asemenea, faptul că un browser poate afișa un site Node.js nu înseamnă că acel browser trimite implicit payloadul necesar. Vulnerabilitatea nu se activează printr-o simplă vizită obișnuită.
Cât de gravă este vulnerabilitatea?
Node.js clasifică CVE-2026-111497 drept High. În baza de date europeană EUVD, scorul publicat pe baza evaluării CVSS 4.0 este 9,2 din 10 (Critical). Scorurile provin din sisteme de evaluare diferite și nu trebuie confundate cu dovada unei exploatări deja produse.
Vulnerabilitatea poate afecta și alte aplicații care includ versiuni vulnerabile ale bibliotecii Google Brotli, nu numai proiectele Node.js. Pentru biblioteca Brotli sunt disponibile corecții în versiunile 1.0.10, 1.1.1 și 1.2.1, în funcție de ramura utilizată.
Ce versiuni Node.js trebuie instalate?
| Ramura Node.js | Prima versiune care include corecția |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
| 20.x și mai vechi | Fără corecție pe ramurile ieșite din suport |
Aceste actualizări au fost anunțate pe 21 octombrie 2026. Pentru mediile de producție este recomandată instalarea celei mai recente versiuni de securitate suportate, nu neapărat doar a versiunii minime din tabel.
Ce trebuie să facă administratorii?
În primul rând, verificarea versiunii Node.js efectiv folosite de aplicație. Un server poate avea versiunea corectată instalată în sistem și poate continua totuși să ruleze o imagine Docker construită cu o versiune veche.
Pe mașina unde rulează aplicația, verificarea de bază este:
node -v
Într-un container Docker:
docker exec NUME_CONTAINER node -v
În Kubernetes, versiunea trebuie verificată în podul care rulează efectiv aplicația, iar imaginile afectate trebuie reconstruite cu runtime-ul corectat și redeployate. Actualizarea sistemului gazdă nu actualizează automat binarul Node.js inclus într-o imagine de container.
În paralel, administratorii ar trebui să inventarieze rutele care acceptă cereri comprimate, parserele Express/body-parser, utilizarea funcției fetch() și orice altă funcție care decomprimă date primite de la surse neîncrezute.
Dacă actualizarea imediată este imposibilă, se pot limita temporar cererile Brotli neîncrezute pe rutele afectate și se pot aplica reguli WAF, testând impactul asupra traficului legitim. Sunt însă măsuri de reducere a expunerii, nu soluții definitive. Mai ales vectorul prin răspunsuri de la servicii externe nu este rezolvat obligatoriu de un WAF pentru traficul de intrare.
Dacă există indicii de compromitere, verificarea trebuie extinsă la jurnalele aplicației, ieșirile neașteptate ale procesului, conexiunile de rețea și secretele accesibile runtime-ului. Un crash sau o eroare de decomprimare, luată separat, nu demonstrează un atac reușit.
Concluzie: autentificarea nu este întotdeauna prima barieră
Node2Shell este un exemplu despre cum o funcție aparent inofensivă — decomprimarea datelor pentru a economisi trafic — poate deveni un punct de intrare în server.
Pentru cititorul obișnuit, esențial este că atacatorul nu trebuie în toate cazurile să se autentifice, dar are nevoie de o cale prin care datele sale special construite să fie decomprimate de o aplicație vulnerabilă. Pentru administrator, concluzia este și mai practică: nu ajunge să securizezi formularele și parolele dacă runtime-ul poate executa cod înainte să ajungă la acele verificări.
Actualizarea Node.js rămâne intervenția principală. Segregarea privilegiilor, limitarea accesului containerelor, controlul secretelor și monitorizarea traficului sunt măsuri care pot reduce impactul unei eventuale compromiteri — dar nu substituie patch-ul.
Surse și documentare
- The Hacker News – Researchers Demonstrate Node2Shell RCE Exploit on Node.js Build Using Crafted Brotli Data (23 octombrie 2026)
- Imperva Threat Research – Node2Shell: From Brotli Data to Remote Code Execution (22 octombrie 2026)
- Node.js – Security Releases, 21 octombrie 2026
- Express.js – Documentația migrării la Express 5
- ENISA EUVD – CVE-2026-111497
- Vercel – Node.js Brotli decoder security advisory
CyberJurnal – material explicativ redactat pe baza comunicatelor tehnice și a cercetărilor publice. Scenariile de impact sunt posibilități condiționate de configurația sistemului, nu afirmații despre victime compromise.
