Node.js repară 16 CVE-uri: crash-uri HTTP/2 și un bug HTTPS care expune chei TLS

Pe 11 noiembrie, proiectul Node.js a publicat versiuni de securitate pentru toate cele trei linii suportate: 22.23.5 (Jod), 24.22.3 (Krypton) și 26.13.1 (Lithium). Lotul acoperă 16 CVE-uri. Șapte sunt clasificate High, șase Medium și trei Low, iar dependențele incluse llhttp, undici și sqlite au fost actualizate pe parcurs.

Problemele serioase se află în codul propriu al serverului Node pentru HTTP/2, HTTPS și TLS. Un bug permite unui client fără credențiale să oprească un server HTTP/2 cu configurare implicită. Altul permite unui client să citească memorie ce aparține altor conexiuni, inclusiv chei private TLS. Proiectul nu raportează atacuri cunoscute, iar CISA nu a adăugat niciunul dintre ele în lista KEV. Nici avizul nu menționează vreo soluție alternativă. Fie faceți upgrade, fie rămâneți expuși.

Bug-urile pe care le-am citi primele

CVE-2026-123863 (CVSS 8,2, High) este o aserțiune accesibilă în închiderea sesiunii HTTP/2. Ce o declanșează este destul de banal: un server http2 standard al cărui handler trimite un răspuns înainte ca clientul să termine de trimis corpul cererii. Un client la distanță poate astfel doborî întregul proces, iar asta funcționează atât prin TLS, cât și în clar. Este o variantă a CVE-2024-27983 care a scăpat de remedierea anterioară. Afectate: 24.x începând cu 24.22.0 și 26.x începând cu 26.9.0.

CVE-2026-123864 este cel care m-a făcut să las cafeaua jos. Este un bug de reintrare în stratul HTTPS al Node, iar un atacator care nu se autentifică niciodată îl poate folosi pentru a citi date din conexiunile altor persoane. Pot fi cererile lor sau cheia privată TLS a serverului dvs. Afectează 22.x, 24.x și 26.x. Atacatorul are nevoie de un anumit tipar de handler: res.flushHeaders() apelat înainte caPcorpul cererii să se termine, apoi res.end() cu un fragment nevid mai târziu. În plus, o rută trebuie să returneze sau să stocheze corpul cererii, pentru că așa ajung octeții scurși înapoi la atacator. node:http simplu, fără TLS, nu este afectat.

CVE-2026-123866 este un use-after-free în închiderea stream-urilor HTTP/2. Poate trimite către parteneră memorie eliberată sau datele de răspuns ale altei conexiuni. Toate cele trei linii sunt afectate.

CVE-2026-123872 este mai discret, dar neplăcut dacă folosiți mTLS. În timpul renegocierii TLS 1.2, un client poate schimba servername-ul și poate transfera o autentificare existentă cu certificat de client către o gazdă cu reguli mai stricte pentru certificatele de client. Dacă un singur proces Node servește mai multe nume de gazdă cu cerințe diferite, citiți-l de două ori.

Apoi mai este CVE-2026-126051, un crash al serverului TLS care poate fi declanșat de la distanță. Afectează serverele 24.x și 26.x care folosesc SNICallback, OCSPRequest, newSession, resumeSession sau server.addContext().

Liniile ajunse la sfârșitul vieții nu primesc nimic. Dacă încă folosiți 20.x sau 25.x, această lansare nu vă remediază nimic.

Cine a găsit toate astea? Chris Rohlf, în colaborare cu Claude și Anthropic Research, a raportat 123863, 123864 și alte probleme din lansare, iar Matteo Collina a scris majoritatea remedierilor. Bănuiala mea este că vânătoarea de bug-uri asistată de AI va aduce mai multe astfel de loturi mari cu multe CVE-uri, nu mai puține. Planificați-vă procesul de patching în consecință.

Cine este de fapt expus

Grupul la risc este format din echipele care termină HTTP/2 sau HTTPS chiar în Node. E un grup mai mic decât „toți cei care rulează Node”, dar mai mare decât cred majoritatea.

Când construim aplicații cloud-native pentru clienți enterprise, Node stă de obicei în spatele unui load balancer sau reverse proxy care se ocupă de TLS și vorbește HTTP/1.1 simplu cu aplicația. În acea configurație, bug-ul de scurgere a cheilor nu vă atinge, fiindcă node:http în clar nu e vizat. Dar în lucrul nostru cu Docker dăm mereu și peste celălalt tip de serviciu: un API de administrare, un receptor de webhook-uri, o mică unealtă internă unde cineva a apelat direct https.createServer sau http2.createSecureServer pentru că era mai rapid decât să configureze un proxy. Pe acestea nu și le amintește nimeni când vine vremea upgrade-urilor.

Rețineți și că 123863 funcționează prin HTTP/2 în clar. Dacă serviciile dvs. comunică între ele prin h2c într-un cluster, faptul că TLS e gestionat în amonte nu vă protejează de crash.

Echipele mobile ar trebui să fie atente și ele. În proiectele noastre native iOS și Android, backend-ul e adesea un API Node, și am văzut echipe care activează HTTP/2 direct în Node pentru traficul aplicației, ca să reducă latența. Dacă acel proces poate fi doborât de la distanță, utilizatorii văd spinnere și cereri eșuate, iar raportarea de crash-uri nu arată nimic greșit pe partea dispozitivului. E un incident derutant de depanat la 2 noaptea.

Din perspectiva securității, bug-urile de divulgare a memoriei mă îngrijorează mai mult decât crash-urile. Un crash apare în monitorizare în câteva minute. O scurgere nu alertează pe nimeni. În testele noastre de penetrare pentru studiouri de gaming, cele mai grave descoperiri au fost rareori cele zgomotoase. Au fost citirile discrete pentru care nimeni nu avea o linie de log. Iar din munca noastră anti-DDoS cu clienți din zona platformelor de travel: când configurăm Cloudflare sau Akamai în fața unui origin, primul lucru pe care îl testăm este dacă origin-ul mai poate fi accesat direct. Deseori da. Configurația edge nu vă ajută dacă un atacator poate vorbi cu procesul Node fără să treacă prin ea.

Ce să faceți astăzi

1. Inventariați fiecare proces Node, nu doar aplicația principală. Rulați node -v în fiecare imagine de container pe care o publicați, inclusiv cron job-uri și sidecar-uri. Un tag de imagine de bază fixat nu se actualizează singur, deci reconstruiți și redeployați.
2. Faceți upgrade la 22.23.5, 24.22.3 sau 26.13.1, în funcție de linia dvs. Nu există niciun flag de configurare care să rezolve problema.
3. Căutați în cod tiparul de scurgere HTTPS: grep -rn "flushHeaders" . Dacă găsiți rezultate într-un handler HTTPS și o rută returnează sau stochează corpuri de cerere, mutați acel serviciu în fruntea cozii. Dacă era expus la internet, rotirea cheii TLS vă costă puțin, chiar fără atacuri raportate.
4. Dacă folosiți 20.x sau 25.x, puneți migrarea pe tabla sprintului curent. Amânarea pe trimestrul viitor nu mai e o opțiune.
5. Verificați că origin-urile dvs. acceptă trafic doar de la CDN sau load balancer.

Nimic din toate acestea nu e muncă spectaculoasă și, sincer, upgrade-ul în sine e de obicei partea ușoară. Găsirea serviciului uitat care își termină singur TLS durează mai mult. Dacă vreți să aflați cum abordăm acest tip de audit, prezentarea serviciilor și proiectele anterioare vă dau o idee, iar echipa noastră de dezvoltare face astfel de upgrade-uri de runtime non-stop.

Dacă un serviciu Node cu propria configurare TLS, neatins de la lansare, vi se pare cunoscut, hai să vorbim.