Vulnerabilitate Node.js: bug-ul Brotli CVE-2026-111497

Pe 21 octombrie 2026, proiectul Node.js a publicat versiunile 22.23.4, 24.22.1 și 26.12.1, cu zece vulnerabilități reparate. Cea mai gravă, CVE-2026-111497, e o vulnerabilitate Node.js în decodorul Brotli inclus în runtime: un stream comprimat construit special produce o scriere în afara buffer-ului (out-of-bounds write), pe care advisory-ul oficial o descrie ca permițând execuție de cod la distanță. Node.js 20 și versiunile mai vechi nu primesc fix.

Diferența față de majoritatea vulnerabilităților web e direcția atacului. Nu ești expus doar prin cererile pe care le primești. Ești expus și prin răspunsurile pe care aplicația ta le descarcă de la alte servere, iar acolo un WAF nu te ajută. Dacă rulezi un scraper, un agent AI care citește pagini web, un worker care procesează webhooks sau orice serviciu care face fetch() spre adrese pe care nu le controlezi, citește articolul până la capăt.

Ce a publicat Node.js pe 21 octombrie

Anunțul oficial acoperă toate cele trei linii suportate. Fiecare are cel puțin o vulnerabilitate de severitate ridicată, iar fix-urile vin doar ca versiuni noi. Nu există patch-uri separate și nici setări care să închidă problema fără upgrade.

Zece vulnerabilități, una cu impact de RCE

Pe lângă ele, release-ul actualizează dependențe incluse în runtime. Potrivit notelor de release pentru 24.22.1, linia 24 primește undici 7.30.1, c-ares 1.34.9, OpenSSL 3.5.9 și certificatele root din NSS 3.131.1. Mai multe despre restul release-ului găsești spre finalul articolului. Prima parte e despre Brotli.

Starea exploatării

Advisory-ul îl creditează pe Matteo Collina pentru raportare, iar fix-ul e un cherry-pick din codul upstream Brotli. Biblioteca Brotli a listat aceeași vulnerabilitate în changelog-ul versiunii 1.2.1, tot pe 21 octombrie.

Despre impactul demonstrat, sursele spun lucruri diferite, iar diferența contează:

• Potrivit The Hacker News, un proof of concept public publicat pe 22 octombrie a obținut execuție de cod doar pe un build slăbit intenționat. Pe un build Node.js standard, autorul a raportat un crash și o citire limitată din memoria procesului.
• Echipa Red Team de la Imperva, care a numit analiza „Node2Shell”, raportează execuție de cod pe imaginea oficială Node.js 24.22.0 pentru Linux arm64, în containere noi, fără debugger și fără binar instrumentat. A fost nevoie de mai multe încercări.

Pe 22 octombrie nu era raportată nicio exploatare în mediul real. Dar un PoC public plus o demonstrație de RCE pe imaginea oficială înseamnă că tot ce lipsește e un atacator care să le combine. Tratează vulnerabilitatea ca exploatabilă.

De ce Brotli e o problemă diferită

Brotli e un algoritm de compresie folosit masiv pe web. Serverele și CDN-urile trimit pagini comprimate cu Brotli când clientul îl acceptă, iar header-ul Content-Encoding: br îi spune clientului să decomprime. Node.js are propriul decodor Brotli, inclus în modulul zlib, iar multe biblioteci îl folosesc automat.

Mecanismul pe scurt

Un stream Brotli își declară structura pe parcurs, inclusiv tipurile de blocuri și trecerile între ele. Imperva descrie un stream care ajunge la o trecere între blocuri imposibilă pentru structura declarată. Decodorul vulnerabil trata situația ca pe o cerere de date suplimentare și continua cu o stare internă invalidă. De acolo, decodarea putea scrie dincolo de buffer-ul alocat.

Fix-ul upstream face ca decodorul să returneze o eroare de format pentru această tranziție, iar Node.js a expus noua eroare ca BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH în zlib.constants. Detaliul ăsta îți dă o metodă de verificare, descrisă mai jos.

Intrare: corpurile cererilor pe care le primești

Un server HTTP Node.js simplu nu decomprimă singur corpul unei cereri doar pentru că îl primește. Expunerea apare când un middleware o face pentru tine. Imperva a testat Express 5.0.0–5.3.0 cu body-parser 2.0.0–2.3.0 și a confirmat că parserele json() și raw() decodează corpuri Brotli trimise cu Content-Encoding: br. Opțiunea care controlează comportamentul e inflate, activă implicit.

Express 4, cu body-parser 1.x, nu acceptă corpuri Brotli și răspunde cu 415, potrivit unei analize publicate pe DEV. Asta nu înseamnă că aplicația e în siguranță: orice cod propriu care cheamă zlib.brotliDecompress() pe date primite de la client e un punct de intrare.

Ieșire: răspunsurile pe care le descarci

Aici e partea pe care majoritatea echipelor o ratează. fetch() din Node.js, construit pe undici, decomprimă automat răspunsurile cu Content-Encoding: br. Analiza de pe DEV arată că decizia se ia după header-ul de răspuns, nu după ce a cerut clientul, și că nu există o opțiune prin care să oprești decodarea.

Consecința practică: orice server către care aplicația ta face o cerere poate trimite un răspuns Brotli malformat. Dacă acel server e controlat de un atacator sau a fost compromis, decodorul vulnerabil rulează în procesul tău. Iar un WAF pus în fața aplicației vede doar traficul care intră, nu răspunsurile pe care aplicația le descarcă.

Cine e expus, concret

Întrebarea utilă nu e „folosesc Node.js?”, ci „decodează aplicația mea Brotli venit de la cineva în care nu am încredere?”.

Bibliotecile care decodează Brotli implicit

Tabelul combină analizele HOL și DEV. Toate aceste biblioteci folosesc decodorul din node:zlib, deci bug-ul nu e în ele, ci în runtime. Upgrade-ul lor nu repară nimic. Upgrade-ul Node.js repară toate căile deodată.

Scrapere, agenți AI, webhooks și preview-uri de linkuri

Profilul cu risc maxim e un serviciu care face cereri către adrese alese de altcineva:

• Scrapere și crawlere. Un pipeline de web scraping descarcă, prin definiție, pagini de pe servere pe care nu le controlezi. E suficient ca una dintre ele să fie ostilă.
• Agenți AI cu unelte de navigare. Un agent AI autonom care primește un URL de la utilizator, de la un email sau dintr-un document și îl citește cu fetch() lasă atacatorul să aleagă serverul.
• Webhooks și integrări. Un worker care urmează callback-uri sau descarcă fișiere de la URL-uri primite de la terți.
• Preview-uri de linkuri și importuri. Funcțiile care generează carduri pentru link-uri lipite în chat, importă un feed RSS sau descarcă un avatar de la o adresă dată de utilizator.

Un detaliu agravant: aceste servicii rulează adesea cu credențiale valoroase în variabilele de mediu, de exemplu chei pentru API-uri de modele AI, pentru proxy-uri sau pentru baza de date în care scriu rezultatele.

Next.js self-hosted și Image Optimization

Bulletin-ul Vercel face o precizare importantă pentru cine rulează Next.js pe propria infrastructură: Next.js nu blochează răspunsurile Brotli în Image Optimization. Dacă ai configurat images.remotePatterns, serverul tău descarcă imagini de pe domeniile permise, iar un domeniu compromis poate trimite un răspuns Brotli malformat. Pentru Next.js self-hosted, fix-ul e upgrade-ul de Node.js. Dacă ai citit despre vulnerabilitățile Next.js din 14 octombrie, ai acum două update-uri de aplicat pe același server, la nivele diferite: framework-ul și runtime-ul.

Versiunile reparate și ce faci pe fiecare linie

Datele vin din calendarul de release Node.js. Pentru proiectele noi sau migrările de acum, 24 e alegerea cu cel mai mult timp de suport rămas dintre liniile deja LTS.

Node.js 20 și mai vechi

Anunțul oficial e direct: versiunile end-of-life sunt mereu afectate când apare o lansare de securitate. Pentru Node.js 20 nu există și nu va exista fix. Ai două variante: migrarea la 22 sau 24, sau un furnizor de suport comercial extins, pe care proiectul Node.js îl menționează prin programul OpenJS Ecosystem Sustainability.

Migrarea de la 20 la 22 e de obicei mică pentru aplicațiile web. Problemele apar la modulele native compilate (driver-e de baze de date mai vechi, bcrypt, sharp vechi) care trebuie recompilate, și la pachetele care fixează un interval strict în engines.node. Rulează testele pe noua versiune înainte de deploy, dar nu lăsa migrarea pentru trimestrul următor.

Pe Vercel și alte platforme gestionate

Vercel spune în bulletin că:

• a activat reguli WAF pe 21 octombrie, automat, pentru toate proiectele, iar cererile blocate apar în dashboard-ul Firewall al fiecărui proiect;
• face rollout la versiunile reparate pe runtime-urile gestionate, iar pentru 22.x și 24.x nu trebuie să schimbi setarea de versiune;
• proiectele pe Node.js 20 trebuie mutate pe 22.x sau 24.x, din setările proiectului sau din engines.node, apoi redeployate.

Limita e scrisă explicit: regulile WAF acoperă doar traficul care trece prin rețeaua Vercel, nu răspunsurile pe care funcțiile tale le descarcă de la alte servere. Pe alte platforme gestionate, caută bulletin-ul furnizorului și verifică ce versiune rulează efectiv funcțiile tale, nu ce scrie în documentație.

Unde se ascunde Node.js în infrastructura ta

La PHP, întrebarea era „ce servere rulează PHP?”. La Node.js, inventarul e mai împrăștiat, pentru că runtime-ul vine la pachet cu multe lucruri.

Servere și version managers

Pe un server, node -v îți arată doar binarul din PATH-ul curent. Version managers precum nvm, fnm sau Volta pot selecta altă versiune per director, iar un serviciu systemd poate avea calea fixată la un binar vechi.

1# Every node binary visible in PATH
2which -a node
3
4# Versions installed by nvm (if used)
5nvm ls
6
7# The exact binary a systemd service runs
8systemctl cat my-api.service | grep ExecStart

1# Every node binary visible in PATH
2which -a node
3
4# Versions installed by nvm (if used)
5nvm ls
6
7# The exact binary a systemd service runs
8systemctl cat my-api.service | grep ExecStart

Dacă Node.js vine din pachetele distribuției Linux, situația e alta: potrivit analizei de pe DEV, acele build-uri pot folosi biblioteca Brotli a sistemului, nu copia inclusă în Node. Atunci contează advisory-ul distribuției pentru pachetul brotli, nu doar versiunea de Node.

Imagini Docker

Tag-urile oficiale node:22, node:24 și node:26 se actualizează după fiecare release, dar imaginea ta nu se schimbă până nu o reconstruiești. Un build cu cache poate păstra stratul de bază vechi.

1# Pull the updated base image and rebuild without stale layers
2docker build --pull --no-cache -t my-api:patched .
3
4# Confirm the runtime inside the image, not on the host
5docker run --rm my-api:patched node -v

1# Pull the updated base image and rebuild without stale layers
2docker build --pull --no-cache -t my-api:patched .
3
4# Confirm the runtime inside the image, not on the host
5docker run --rm my-api:patched node -v

Dacă Dockerfile-ul fixează imaginea de bază pe un digest (FROM node:24@sha256:...), trebuie actualizat manual digest-ul. Același lucru e valabil pentru imaginile construite din node:24-alpine sau node:24-slim.

CI runners și mașinile de dezvoltare

Un runner de CI care rulează testele de integrare face și el cereri HTTP, iar unele teste descarcă fixture-uri sau pachete de pe internet. În GitHub Actions, actions/setup-node cu node-version: 24 poate folosi o versiune din cache-ul runner-ului. Opțiunea check-latest: true forțează ultima versiune disponibilă pentru acea linie.

Laptopurile echipei contează mai puțin ca țintă directă, dar un nvm install 24 făcut săptămâna trecută a instalat o versiune vulnerabilă. Un mesaj în canalul echipei cu comanda de upgrade costă un minut.

Verificarea că patch-ul e în runtime

Numărul versiunii e un indicator bun pentru binarele oficiale. Există însă o verificare mai directă, bazată pe constanta adăugată de fix:

1# Patched runtimes expose the new decoder error code; vulnerable ones print undefined
2node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH"

1# Patched runtimes expose the new decoder error code; vulnerable ones print undefined
2node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH"

Pe 22.23.4, 24.22.1 și 26.12.1 comanda afișează un cod numeric de eroare. Pe versiunile vulnerabile afișează undefined. Comanda doar citește o constantă, deci o poți rula fără risc pe orice server, în orice container și în pipeline-ul de CI, ca pas care oprește build-ul.

Dacă nu poți actualiza azi

Advisory-ul nu oferă workaround pentru CVE-2026-111497. Măsurile de mai jos reduc suprafața de atac pe căile cunoscute. Folosește-le doar până termini upgrade-ul.

Pe partea de intrare

Dacă clienții tăi nu trimit niciodată corpuri comprimate cu Brotli (cazul aproape tuturor API-urilor publice), respinge-le la proxy, înainte să ajungă la Node:

1# Reject request bodies compressed with Brotli before they reach Node.js
2if ($http_content_encoding ~* "br") {
3    return 415;
4}

1# Reject request bodies compressed with Brotli before they reach Node.js
2if ($http_content_encoding ~* "br") {
3    return 415;
4}

În Express 5 poți dezactiva decomprimarea corpurilor cu express.json({ inflate: false }) și echivalentele pentru raw, text și urlencoded. Cererile cu corpuri comprimate vor fi respinse, deci verifică întâi dacă vreun client legitim le trimite.

Pe partea de ieșire

Aici opțiunile sunt mai slabe, pentru că fetch() nu are opțiune de dezactivare:

• Pentru axios, got sau node-fetch, oprește decomprimarea automată pe clienții care vorbesc cu servere externe. Vei primi octeții comprimați și trebuie să-i tratezi explicit, de exemplu respingând răspunsurile cu Content-Encoding: br.
• Pentru fetch(), cea mai sigură variantă temporară e un proxy de ieșire (egress) prin care trec cererile spre internet și care respinge răspunsurile cu Content-Encoding: br. Un scraper sau un agent care descarcă pagini oricum ar trebui să treacă printr-un astfel de punct de control.
• Restrânge lista de destinații unde se poate. Un worker care vorbește doar cu trei API-uri cunoscute nu are nevoie de acces la tot internetul.

Restul release-ului: TLS, DNS și certificatele eMudhra

Brotli a atras atenția, dar celelalte nouă vulnerabilități merită și ele câteva minute, mai ales dacă aplicația ta se conectează prin TLS la servicii interne.

Verificarea hostname-ului TLS

Trei dintre vulnerabilități (CVE-2026-106069, CVE-2026-105483 și CVE-2026-106072) țin de felul în care Node.js compară adresa la care te conectezi cu numele din certificat, atunci când adresa e un IP scris într-o formă neobișnuită. Notele de release le descriu ca fix-uri care resping adresele IP non-canonice. Riscul practic: un certificat emis pentru un nume DNS putea fi acceptat pentru o conexiune către un IP, deci verificarea TLS nu garanta că vorbești cu serverul pe care îl credeai. Contează mai ales pentru serviciile care se conectează la adrese IP primite din configurații sau de la utilizatori.

randomUUID() în snapshot-uri și binare SEA

CVE-2026-106074 afectează aplicațiile construite ca startup snapshot sau ca Single Executable Application (SEA). Cache-ul de entropie folosit de crypto.randomUUID() și randomInt() ajungea salvat în snapshot, așa că fiecare proces pornit din același snapshot genera aceleași valori. Dacă folosești UUID-uri ca identificatori de sesiune, token-uri sau chei de idempotență într-un binar SEA, verifică ce s-a generat până acum.

Blocarea certificatelor eMudhra

Release-ul introduce, pentru prima dată în Node.js, o listă compilată de chei publice blocate. Potrivit PR-ului care o adaugă, lista inițială conține opt certificate intermediare eMudhra și emSign ale căror chei private au fost raportate compromise în octombrie 2026. Un lanț de certificate care trece prin ele e respins ca revocat. Sesiunile TLS reluate din înainte de upgrade nu sunt reverificate până expiră, iar liniile end-of-life nu primesc blocarea.

Ce înveți din această lansare

Pe 21 octombrie 2026 au apărut, în aceeași zi, PHP2Shell pentru PHP și acest release pentru Node.js. Ambele sunt la nivel de runtime, sub framework-uri și sub codul aplicației. Câteva concluzii care rămân valabile și după.

Traficul de ieșire face parte din suprafața de atac

Majoritatea echipelor modelează amenințările pe trafic de intrare: formulare, API-uri, upload-uri. Aici, un răspuns descărcat de aplicație ajunge direct în decodor. Orice serviciu care face cereri către adrese neverificate (scrapere, agenți AI, integrări) trebuie tratat ca un serviciu care primește date nesigure, cu izolare, permisiuni minime și un punct de control pentru traficul de ieșire.

Inventarul de runtime trebuie să includă tot

Node.js nu stă doar pe serverul de producție. Stă în imagini Docker, în runner-ele de CI, în funcțiile serverless, în binarele SEA și pe fiecare laptop. Un inventar care listează doar „serverele de API” ratează jumătate din locurile unde trebuie aplicat patch-ul. Verificarea cu constanta din zlib, pusă ca pas în CI, transformă un inventar manual într-o regulă automată.

Liniile end-of-life sunt o datorie cu scadență

Node.js 20 a ieșit din suport pe 30 aprilie 2026. Șase luni mai târziu, fiecare serviciu rămas pe 20 a transformat un upgrade de patch într-o migrare de versiune majoră, făcută sub presiune. Pune data de end-of-life a runtime-ului în același calendar cu reînnoirea certificatelor și a domeniilor.

Întrebări frecvente

Ce este CVE-2026-111497?

E o vulnerabilitate în decodorul Brotli inclus în Node.js. Un stream Brotli malformat poate produce o scriere în afara buffer-ului, iar advisory-ul oficial o descrie ca permițând execuție de cod la distanță. E reparată în Node.js 22.23.4, 24.22.1 și 26.12.1, publicate pe 21 octombrie 2026.

Sunt afectat dacă aplicația mea nu folosește Brotli explicit?

Probabil da. fetch() decomprimă automat răspunsurile Brotli, la fel axios, got și node-fetch, iar Express 5 decomprimă corpurile cererilor. Nu trebuie să scrii cod Brotli ca să fii expus. Contează dacă aplicația primește sau descarcă date de la surse în care nu ai încredere.

Am Node.js 20. Ce fac?

Migrezi la 22 sau 24. Node.js 20 a ieșit din suport pe 30 aprilie 2026 și nu primește fix pentru această vulnerabilitate. Până la migrare, aplică măsurile temporare pe intrare și pe ieșire și prioritizează serviciile care descarcă date de la terți.

Mă protejează WAF-ul?

Doar pe partea de intrare. Un WAF filtrează cererile care ajung la aplicația ta, dar nu vede răspunsurile pe care aplicația le descarcă de la alte servere. Vercel spune explicit că regulile lui nu acoperă această direcție și nu înlocuiesc upgrade-ul.

Trebuie să actualizez undici, axios sau Express?

Nu pentru această vulnerabilitate. Toate folosesc decodorul Brotli din runtime-ul Node.js, deci fix-ul vine din upgrade-ul Node.js. Release-ul actualizează și undici-ul inclus în Node, dar pentru alte advisory-uri, de severitate medie.

Cum verific rapid dacă un server are patch-ul?

Rulează node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH". Pe versiunile reparate afișează un cod numeric, pe cele vulnerabile afișează undefined. Rulează comanda și în containere, nu doar pe host.

Următorul pas

Fă azi lista serviciilor care descarcă date de la adrese pe care nu le controlezi și începe upgrade-ul cu ele, apoi continuă cu restul inventarului. Adaugă verificarea cu constanta din zlib ca pas obligatoriu în CI, ca următorul release de securitate să fie o regulă care pică un build, nu o căutare manuală. Pentru alte analize de vulnerabilități și măsuri de protecție, vezi categoria Securitate aplicații web și eticheta Securitatea datelor, iar pentru felul în care construiești un scraper care izolează datele descărcate, ghidul despre alegerea uneltei de web scraping.