Node.js a corectat zece vulnerabilități, una cu execuție de cod la distanță. Ce versiune instalezi, ce verifici în producție și ce faci cu aplicațiile pe Node 16, 18 sau 20.
Pe 21 octombrie 2026, proiectul Node.js a publicat actualizări de securitate pentru toate liniile suportate: v22.23.4, v24.22.1 și v26.12.1. Sunt corectate zece vulnerabilități, dintre care patru de severitate mare. Cea mai gravă, CVE-2026-111497, este o scriere în afara limitelor de memorie în decodorul Brotli, pe care anunțul oficial o descrie ca permițând execuția de cod la distanță. A fost raportată de echipa OpenAI Codex Security.
Dacă firma ta are o aplicație web, un API, un panou de administrare sau un serviciu intern scris în JavaScript ori TypeScript pe server, aproape sigur rulează pe Node.js. Articolul e pentru managerul acelei aplicații și pentru echipa care o întreține: ce s-a corectat, ce verificați, ce capcane apar la actualizare și ce faceți dacă aplicația e pe o versiune veche.
Ce s-a corectat
Lista oficială are zece CVE-uri. Pe scurt, cele care contează pentru majoritatea aplicațiilor:
- CVE-2026-111497 (severitate mare): defect în decodorul Brotli, formatul de compresie folosit pe web, care poate permite execuția de cod la distanță. Afectează liniile 22, 24 și 26.
- CVE-2026-105483 și CVE-2026-106069 (severitate mare): două moduri de a ocoli verificarea numelui din certificatul TLS, legate de felul în care sunt scrise sau interpretate adresele IP. Verificarea certificatului e cea care garantează că aplicația vorbește cu serverul corect, nu cu un impostor.
- CVE-2026-105482 (severitate mare): funcția de rezolvare DNS trunchiază numele care conțin un caracter nul.
- Vulnerabilități medii și mici: o problemă cu conexiunile keep-alive, validarea certificatelor pentru adrese IPv4 scrise neobișnuit, generatorul de identificatori aleatori care repetă valori în snapshot-urile de pornire și în aplicațiile împachetate ca executabil unic (SEA), plus câteva probleme în modelul de permisiuni și în citirea arhivelor ZIP.
Au fost actualizate și componentele incluse în Node.js: c-ares, OpenSSL, SQLite, Undici (clientul HTTP folosit de fetch) și lista de autorități de certificare. Ultima a fost actualizată după compromiterea autorității eMudhra din aceeași săptămână.
Un lucru important: anunțul oficial nu detaliază ce funcții sau ce configurații expun defectul Brotli. Până nu știți sigur că aplicația voastră nu e atinsă, tratați orice aplicație pe liniile 22, 24 sau 26 ca afectată și actualizați-o.
Ce versiune trebuie să rulați
- linia 22: v22.23.4 sau mai nouă;
- linia 24: v24.22.1 sau mai nouă;
- linia 26: v26.12.1 sau mai nouă.
Node.js recomandă, în ordine:
- actualizarea la versiunea corectată a liniei folosite;
- prioritate pentru defectul Brotli și pentru ocolirile TLS;
- reconstruirea snapshot-urilor de pornire și a aplicațiilor SEA după actualizare, altfel ele păstrează valorile repetate de la CVE-2026-106074;
- mutarea aplicațiilor de pe versiunile ieșite din suport.
Ce verificați, concret
- Versiunea care rulează efectiv în producție. Nu cea din package.json și nici cea de pe laptopul unui programator. Comanda node -v, rulată în containerul sau pe serverul de producție, e singurul răspuns sigur.
- Imaginea de bază, dacă folosiți Docker. Versiunea Node.js vine din imaginea pe care e construită aplicația. Dacă ea nu e reconstruită, aplicația rămâne pe versiunea veche.
- Platformele administrate. Pe un serviciu serverless sau PaaS, runtime-ul îl actualizează furnizorul, dar uneori trebuie să alegeți voi versiunea sau să refaceți deploy-ul. Verificați în panoul lor ce versiune folosește funcția sau aplicația voastră și ce au anunțat după 21 octombrie.
- Dependențele. Dacă aplicația folosește Undici instalat separat, ca pachet, actualizați-l și pe el. Versiunea inclusă în Node.js nu îl înlocuiește pe cel din node_modules.
- După actualizare: reconstruire, deploy, teste de fum pe fluxurile importante (autentificare, plăți, formulare, integrări) și verificarea jurnalelor de erori.
O capcană frecventă: eticheta „22-alpine” nu înseamnă „ultima versiune”
Multe proiecte construiesc imaginea pornind de la o etichetă mobilă, de tipul node 22 alpine. Pare că aduce mereu ultima versiune din linia 22, dar nu e garantat: pe mașina sau serverul de build poate exista o copie mai veche a acelei imagini, păstrată în cache, iar build-ul o folosește fără să o descarce din nou. Rezultatul: o imagine construită azi, după patch, care rulează tot versiunea vulnerabilă.
Soluția e simplă. Fixați explicit versiunea în fișierul de build, de exemplu node 22.23.4 alpine în loc de node 22 alpine. Apoi verificați cu node -v în containerul care rulează, nu doar în cel de build. Când apare următoarea actualizare de securitate, schimbarea versiunii fixate e vizibilă și ușor de urmărit.
Dacă aplicația rulează pe Node.js 16, 18 sau 20
Linia 18 a ieșit din suport pe 30 aprilie 2025, iar linia 20 pe 30 aprilie 2026. Nu primesc corecturile din octombrie. Proiectul Node.js precizează că versiunile ieșite din suport sunt considerate afectate la fiecare lansare de securitate.
Opțiunile, pe scurt:
- Portarea la linia 22 sau 24. Linia 22 e suportată până pe 30 aprilie 2027, linia 24 până pe 30 aprilie 2028. Linia 26 devine LTS pe 28 octombrie 2026 și e suportată până pe 30 aprilie 2029. Pentru aplicațiile noi sau pentru o portare mare, 24 sau 26 dau mai mult timp până la următoarea mutare.
- Ce înseamnă portarea în muncă: dependențe actualizate (unele pot fi abandonate și trebuie înlocuite), funcții eliminate sau schimbate între versiuni, module native recompilate și, mai ales, teste. Fără teste automate, portarea se face mai lent și mai atent, pe o copie a aplicației.
- O punte temporară. Proiectul Node.js trimite, pentru versiunile ieșite din suport, la partenerii comerciali din programul OpenJS. Între timp, aplicația poate fi izolată: accesibilă doar din rețeaua internă sau prin VPN, în spatele unui filtru. Nu e o soluție finală, doar timp câștigat pentru migrare.
Pe scurt
- Aflați versiunea Node.js care rulează efectiv în producție.
- Actualizați la v22.23.4, v24.22.1 sau v26.12.1.
- Fixați versiunea în imaginea de bază și reconstruiți toate imaginile.
- Refaceți snapshot-urile și aplicațiile SEA, dacă le folosiți.
- Actualizați dependențele, inclusiv Undici instalat separat, apoi testați fluxurile importante.
- Pentru aplicațiile pe 16, 18 sau 20, planificați portarea și izolați-le până atunci.
La ME Digital rulăm noi înșine aplicații pe Node.js și le-am actualizat în aceeași săptămână. Facem același lucru pentru clienți: verificăm versiunea reală din producție, actualizăm și reconstruim imaginile și portăm aplicațiile rămase pe versiuni vechi, ca parte din serviciile de securitate și actualizări. Dacă vrei să ne uităm la aplicația ta, scrie-ne.
