Pe 21 octombrie 2026, Node.js a publicat corecții pentru zece vulnerabilități. Una dintre ele, CVE-2026-111497, a fost numită Node2Shell după ce un cercetător a demonstrat execuție de cod prin ea și a fost relatată peste tot ca o vulnerabilitate Node.js.
Nu este o vulnerabilitate Node.js. CVE-ul este atribuit de Google împotriva Brotli, o bibliotecă de compresie. Lista produselor afectate conține exact o intrare — github.com/google/brotli — și nimic altceva. Node.js încorporează acea bibliotecă, așa că utilizatorii de Node au primit o corecție și un titlu de știre. Toți ceilalți care o încorporează nu au primit niciuna, nici alta.
Asimetria aceasta este întreaga problemă de guvernanță și merită examinată, nu doar depășită printr-un patch.
La ce nu poate răspunde un inventar la nivel de produs
Majoritatea inventarelor de active consemnează produse: serverul acesta rulează Node.js 24, acela rulează .NET 9, parcul de stații rulează Chrome, echipamentul acela rulează o imagine de firmware de la producător. Se atribuie criticitate, se atașează cicluri de actualizare, iar documentul trece un audit.
Acum pune întrebarea pe care o ridică acest CVE: care dintre sistemele noastre decodează Brotli și ce copie a decodorului folosesc?
O listă de produse nu poate răspunde. Răspunsul, într-un parc obișnuit, acoperă lucruri pe care nimeni nu le-a pus vreodată în aceeași categorie:
- Node.js, Bun și orice este construit pe ele
- Runtime-ul .NET, ale cărui
BrotliStreamșiBrotliDecoderse sprijină pe o copie încorporată - Chromium și Firefox, care decodează
Content-Encoding: brși fonturi WOFF2 curlcu--compressed, oriunde îl apelează un script sau o aplicație- FreeType, care decodează tabele de font comprimate și, prin urmare, orice randează text
- Extensii de limbaj în PHP, Ruby și Perl care împachetează biblioteca C
- Proxy-uri și software de edge, dintre care unele decodează Brotli chiar în timpul negocierii TLS, pentru compresia certificatelor
- Biblioteca
libbrotlideca sistemului de operare, partajată de tot ce o leagă dinamic în loc să o încorporeze
Niciunul nu este exotic. Toate sunt invizibile pentru un inventar care se oprește la numele produsului.
Aproape nimeni nu a spus că este afectat
Aceasta este partea care ar trebui să schimbe felul în care citești tăcerea unui furnizor.
Dintre numeroasele proiecte care încorporează acest decodor, numărul celor care au declarat public „suntem afectați" este foarte aproape de zero. Un singur pachet Python a numit CVE-ul în propriul jurnal de modificări. Node.js a publicat o avertizare. Bun a livrat corecția actualizând o referință de dependență, în tăcere, fără nicio mențiune în notele de versiune.
Toți ceilalți nu au spus nimic — inclusiv câțiva care sunt afectați și câțiva care nu sunt. Microsoft nu a publicat nicio avertizare, iar runtime-ul .NET încorporează o versiune vulnerabilă. Debian listează Brotli ca vulnerabil și necorectat, marcând în același timp propriul pachet Node.js drept „neimportant", pentru că folosește biblioteca de sistem. Ubuntu nu are nicio notificare. SUSE urmărește Node.js, dar nu și Brotli.
Tăcerea nu înseamnă aici siguranță și nici expunere. Înseamnă că nimeni nu a verificat în locul tău.
Automatizarea nu îl prinde pe acesta
Trei mecanisme pe care organizațiile se bazează eșuează la acest CVE, iar motivul este mai util decât cazul în sine.
Avertizarea nu are identificatori de pachet. Avertizarea de securitate GitHub pentru acest CVE este marcată ca neverificată, cu o listă goală de pachete afectate — zero pachete, zero ecosisteme. OSV conține doar un interval de commit-uri Git. Prin urmare, npm audit, Dependabot, pip-audit, cargo audit și govulncheck nu îl vor semnala pentru nicio dependență declarată. O scanare curată a dependențelor nu spune nimic aici.
Șirurile de versiune mint în ambele sensuri. Corecția din amonte a intrat în februarie 2026, iar versiunile etichetate care o conțin au apărut în octombrie. Un proiect care fixează un commit de după februarie este deja corectat, deși raportează numărul vechi de versiune. Un proiect care fixează eticheta publicată a aceluiași număr este vulnerabil. Analiza compoziției software bazată pe versiuni greșește în ambele cazuri.
Copiile încorporate sunt invizibile pentru managerul de pachete. O bibliotecă compilată într-un binar nu apare în niciun manifest. Singurele moduri de a o vedea sunt un SBOM generat la build, o scanare de compoziție binară sau citirea codului sursă al proiectului.
Ce cere efectiv NIS 2 aici
Articolul 21 din NIS 2, transpus în România prin OUG nr. 155/2024, cere politici de analiză a riscului și de securitate a sistemelor informatice, gestionarea și divulgarea vulnerabilităților și — explicit — securitatea lanțului de aprovizionare, inclusiv securitatea relațiilor cu furnizorii direcți și cu prestatorii de servicii.
Directiva nu impune un SBOM. Ce cere este ca măsurile să fie proporționale cu riscul, iar episodul acesta demonstrează curat că un inventar la nivel de produs nu poate stabili care este riscul.
Două consecințe pentru o evaluare:
- Gestionarea vulnerabilităților trebuie să accepte intrări care nu sunt avertizări de la furnizori. Dacă procesul tău pornește atunci când un furnizor îți trimite un buletin, în cazuri ca acesta nu pornește niciodată, pentru că majoritatea furnizorilor nu au trimis nimic.
- Securitatea lanțului de aprovizionare trebuie să ajungă sub nivelul furnizorului. Întrebarea nu este doar dacă furnizorul tău are un program de securitate. Este ce conține produsul lui și dacă îți va spune când o componentă din el devine vulnerabilă.
Patru întrebări la care trebuie să răspundă un inventar de componente
Nu un proiect de tooling. Patru întrebări, cu răspuns pentru sistemele care contează.
- Ce componente terțe sunt compilate în fiecare produs pe care îl rulăm? Pentru software-ul pe care îl construiești, răspunsul vine din sistemul de build. Pentru cel pe care îl cumperi, vine din a cere furnizorului un SBOM — iar răspunsul pe care îl primești, sau nu îl primești, este el însuși o constatare de consemnat.
- Care dintre acele componente sunt partajate între produse fără legătură între ele? Bibliotecile de compresie, de parsare, de criptografie și de prelucrare a imaginilor sau a fonturilor sunt cele care reapar peste tot și tocmai ele transformă o singură vulnerabilitate din amonte în zece sarcini separate de remediere.
- Pentru fiecare componentă, o luăm din sistemul de operare sau produsul își poartă propria copie? Asta decide dacă o actualizare de distribuție o repară sau dacă aștepți o recompilare de la producător. Este și diferența dintre un patch și douăzeci.
- Cine află când o componentă pe care nu o instalăm direct are o vulnerabilitate? Numește persoana sau sursa. Pentru majoritatea organizațiilor, răspunsul onest astăzi este „nimeni", iar acesta este golul pe care îl scoate la iveală acest CVE.
Ce faci concret cu acesta
Actualizează Node.js la 22.23.4, 24.22.1 sau 26.12.1; Node 20 și versiunile anterioare au ieșit din suport și nu primesc corecție. Actualizează biblioteca Brotli la 1.0.10, 1.1.1 sau 1.2.1 oriunde o ai. Reconstruiește imaginile de container, în loc să presupui că o recompilare a imaginii de bază a ajuns la tine.
Apoi fă partea care valorează mai mult decât patch-ul: ia lista produselor din parcul tău, alege-le pe cele zece care procesează date nesigure din internet și află ce încorporează fiecare. Nu vei termina săptămâna aceasta. Vei găsi două-trei lucruri despre care nimeni nu știa că sunt acolo, iar acesta este scopul.
Nu există dovezi de exploatare a acestei vulnerabilități, nu figurează în catalogul CISA al vulnerabilităților exploatate cunoscute, iar singura demonstrație publică a reușit doar intermitent, pe o singură arhitectură. Urgența este mică. Lecția, nu.
Acolo unde inventarul în sine este lipsa, un audit de conformitate sub NIS 2 stabilește ce așteaptă un evaluator și ce dovezi îl satisfac. Acolo unde întrebarea este la ce ajunge un atacator pornind de la o componentă compromisă, răspunde un test de penetrare intern. Iar acolo unde nu ești sigur ce publici în internet, o evaluare a suprafeței externe de atac construiește lista din exterior.
Surse: Lansările de securitate Node.js din octombrie 2026 · Commit-ul de corecție Brotli din amonte, 27 februarie 2026 · Versiunea Brotli 1.2.1 · Imperva: Node2Shell · Tracker-ul de securitate Debian
Consumatorii din aval menționați mai sus au fost stabiliți prin citirea versiunii fixate în sursa fiecărui proiect, nu prin testare, iar exploatarea niciunuia dintre ei nu a fost demonstrată. Situația furnizorilor și a distribuțiilor se schimbă zilnic. CVE-ul are un scor de 9,2 atribuit de Google în calitate de CNA; Node.js îl evaluează drept „ridicat", fără număr, iar NVD nu îl analizase la momentul redactării.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.