Node.js-beveiligingsupdates zijn beschikbaar: dit moet je controleren

De aangekondigde beveiligingsupdates voor Node.js zijn op 11 november 2026 daadwerkelijk verschenen. Voor de drie ondersteunde versielijnen zijn de beveiligingsreleases 22.23.5, 24.22.3 en 26.13.1 beschikbaar. Daarmee is de belangrijkste vraag voor organisaties niet langer wanneer de patches uitkomen, maar waar Node.js draait en of de nieuwe runtime ook echt in productie is uitgerold.

De officiële release-informatie noemt meerdere kwetsbaarheden met de ernst *High*. Een deel betreft de verwerking van HTTP/2-verkeer; andere fouten raken TLS, HTTPS en geheugenbeheer. Voor een klein bedrijf met een webshop, klantportaal of eigen API is dit vooral een onderhoudsvraag: wie kan aantonen welke versie de applicatie daadwerkelijk gebruikt?

Welke beveiligingsupdates zijn uitgekomen?

Het Node.js-project publiceerde begin november een vooraankondiging. Op 11 november volgden de definitieve beveiligingsreleases voor 22.x, 24.x en 26.x, met technische details en CVE-identificaties. Die nieuwe informatie vervangt de eerdere onzekerheid over de exacte patchnummers.

De juiste update is afhankelijk van de bestaande hoofdversie. Een toepassing op Node.js 22 kan naar 22.23.5, een toepassing op 24 naar 24.22.3, en een toepassing op 26 naar 26.13.1. Controleer altijd of inmiddels een latere officiële beveiligingsrelease binnen dezelfde lijn beschikbaar is. Direct overstappen naar een andere hoofdversie is niet nodig om alleen deze fixes te installeren en kan extra compatibiliteitstests vereisen.

De reparaties omvatten ook bijgewerkte ingebouwde dependencies. Het project noemt onder meer llhttp voor alle drie de versielijnen, Undici voor 24.x en 26.x en SQLite voor 22.x en 24.x. Dat zijn wijzigingen aan onderdelen die applicaties direct of indirect gebruiken. Het is dus niet voldoende om uitsluitend in het eigen package.json naar gewijzigde versienummers te zoeken.

Wat is de daadwerkelijke impact?

De officiële beschrijvingen maken duidelijk waarom niet alle Node.js-installaties precies hetzelfde risico lopen. CVE-2026-123863 beschrijft een procescrash bij het opruimen van een HTTP/2-sessie; deze kwetsbaarheid komt volgens de officiële release notes voor in de 22.x-, 24.x- en 26.x-lijnen. CVE-2026-123875 betreft een andere HTTP/2-crash, die bij het annuleren van bepaalde bestandsdownloads kan ontstaan en volgens het project alle drie de actieve lijnen raakt.

Er zijn daarnaast kwetsbaarheden in de omgang met HTTPS- en TLS-verbindingen. CVE-2026-123864 raakt bijvoorbeeld het samenspel van TLS en HTTP-parseruitvoering. CVE-2026-123872 betreft TLS-beleid rond sessies, hostnamen en clientcertificaten. CVE-2026-126051 is een op afstand uit te lokken TLS-servercrash en wordt in de release-informatie van 24.x en 26.x genoemd.

Welke van deze fouten exploiteerbaar is bij jouw applicatie, hangt af van de gebruikte runtime, protocollen en configuratie. Een statische website waarvan Node.js alleen tijdens het bouwen wordt gebruikt, heeft een ander aanvalsoppervlak dan een publiek bereikbare API die zelf HTTP/2-verzoeken verwerkt.

Een hoge CVSS-ernst of openbaar CVE-nummer vormt bovendien geen bewijs van daadwerkelijk misbruik. De veiligheidsprioriteit volgt uit de combinatie van technische impact, blootstelling van de toepassing en beschikbare informatie over exploitatie. Verwar deze novemberpatches niet met de afzonderlijke Brotli-kwetsbaarheid uit oktober die eerder in CISA's catalogus van daadwerkelijk misbruikte kwetsbaarheden werd opgenomen.

Waarom 'de update is uitgevoerd' soms niet klopt

Een ontwikkelaar kan lokaal node --version uitvoeren en een gepatchte versie zien, terwijl de productieomgeving nog een oudere runtime gebruikt. Dat gebeurt bijvoorbeeld wanneer de applicatie in een container draait waarvan het image niet opnieuw is gebouwd. Een nieuwe Dockerfile of succesvolle CI-run bewijst niet dat de actuele container vervangen is.

Hetzelfde geldt voor servers van externe leveranciers. Een webbouwer beheert mogelijk de frontend, de hostingpartij de infrastructuur en een andere leverancier een intern dashboard. Zonder duidelijke afspraken kan iedere partij denken dat een ander de runtime bijwerkt.

Inventariseer daarom de werkelijk draaiende versies in productie, staging, achtergrondtaken, containerimages en buildomgevingen. Controleer in de relevante uitvoeromgeving welke Node.js-binary actief is. Bij managed hosting kan de leverancier die informatie moeten aanleveren.

Een praktisch en controleerbaar updateproces

Begin bij de diensten die vanaf internet bereikbaar zijn of gevoelige data verwerken. Leg per toepassing de verantwoordelijke, hoofdversie en huidige runtimeversie vast. Vraag vervolgens welke van de drie officiële beveiligingsreleases nodig is en of de toepassing nog op een ondersteunde lijn draait.

Test de gepatchte runtime eerst in een representatieve omgeving. Controleer vooral de functies die afhankelijk zijn van HTTP/2, TLS, verbindingen met externe services en de gebruikte frameworks. Bouw daarna containers opnieuw of voer de officiële runtime-update via het juiste beheerproces uit. Een geslaagde test is waardevol, maar de reparatie telt pas wanneer de nieuwe versie draait.

Controleer na deployment opnieuw node --version in de draaiende service, verifieer belangrijke gebruikersroutes en let op onverwachte herstarts of verbindingsproblemen. Documenteer eventuele achterblijvers met een concrete eigenaar en herstelactie.

Voor toepassingen op end-of-life-versies is een apart migratieplan nodig. Een verouderde hoofdversie ontvangt niet automatisch dezelfde beveiligingsreparaties. Zet productie ook niet alleen vanwege een hoger nummer over op de experimentele Node.js 27-alpha.

Wat een ondernemer aan zijn IT-partner moet vragen

Een kleine organisatie hoeft niet elke HTTP/2-fout technisch te onderzoeken. Maar zij moet wel kunnen aantonen dat essentiële applicaties worden onderhouden. Dat betekent zicht op de runtime, een toegewezen beheerder en verificatie na de update.

Vraag daarom niet alleen of Node.js is bijgewerkt. Vraag welke versies per applicatie daadwerkelijk in productie draaien, wanneer de patches zijn uitgerold en hoe dat is gecontroleerd. Met zo'n antwoord wordt een algemene belofte over veiligheid een verifieerbare beheertaak.

Bronnen: Node.js · Release 22 · Release 24 · Release 26