Node.js-beveiligingsupdate oktober 2026: Brotli-RCE en TLS-bypasses

Op 21 oktober 2026 bracht het Node.js-project de versies 22.23.4, 24.22.1 en 26.12.1 uit. Ze verhelpen tien kwetsbaarheden, waarvan vier met de classificatie hoog. De ernstigste, CVE-2026-111497, is een out-of-bounds write in de Brotli-decoder van Node: misvormde gecomprimeerde data kan geheugen beschadigen, en hostingbedrijf Vercel meldt dat onderzoekers hiermee procesgeheugen konden uitlezen en commando's konden uitvoeren met de rechten van het Node.js-proces. Twee andere kwetsbaarheden met de classificatie hoog laten een TLS-certificaat de hostnaamcontrole passeren terwijl dat niet zou mogen. Node.js 20 en 25 zijn end-of-life en krijgen geen fix.

Welke versies zijn opgelost

Wat de tien kwetsbaarheden zijn

De releases werken ook meegeleverde componenten bij: c-ares, Undici, de lijst met vertrouwde CA's (waarbij de gecompromitteerde tussen-CA van eMudhra is verwijderd), OpenSSL op 24 en 22, en SQLite op 22.

Wie loopt risico door de Brotli-kwetsbaarheid

Node.js decodeert Brotli niet uit zichzelf. U loopt risico wanneer uw code, of een bibliotheek die u gebruikt, Brotli-data decomprimeert die door iemand anders wordt bepaald. Dat gebeurt vaker dan het klinkt:

• De ingebouwde fetch() decodeert antwoorden met Content-Encoding: br automatisch. Een dienst die URL's ophaalt die gebruikers, webhooks of API's van derden kiezen, kan een kwaadaardig antwoord ontvangen.
• axios, got en node-fetch decoderen gecomprimeerde antwoorden standaard ook.
• Express 5 (body-parser 2) decodeert Brotli-requestbodies standaard, waardoor een API de data rechtstreeks van een aanvaller kan ontvangen.
• Elke aanroep van zlib.brotliDecompress, zlib.createBrotliDecompress of DecompressionStream op uploads of data van derden.

Patch eerst waar dit het internet raakt: publieke API's die gecomprimeerde bodies accepteren, diensten die door gebruikers aangeleverde URL's ophalen en alles wat geüploade bestanden uitpakt.

De TLS-kwetsbaarheden spelen vooral wanneer een aanvaller een certificaat kan bemachtigen van een CA die uw client vertrouwt en dat een DNS-naam in de vorm van een IP-adres bevat, en de DNS-kwetsbaarheid wanneer uw code invoer van buitenaf aan dns.resolve doorgeeft. Volgens de fixcommit zijn de TLS-problemen niet gemakkelijk te misbruiken, maar dezelfde update sluit ze.

Stap 1: vind elke Node.js-runtime

Toon op Linux elke node-binary met de bijbehorende versie:

sudo find / -xdev -type f -name node -perm -u+x 2>/dev/null | while read -r n; do echo "$n: $("$n" --version 2>/dev/null)"; done

Controleer welke runtime de draaiende processen gebruiken:

for p in $(pgrep -x node); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

Controleer bij Docker elke draaiende container:

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" node --version 2>/dev/null)"; done

Kijk ook naar versiebeheerders (nvm, fnm, Volta, asdf), CI-runners, build-images, Electron-apps en serverless-functies, waar de runtimeversie in de projectconfiguratie is ingesteld.

Stap 2: werk bij

Ubuntu en Debian met de NodeSource-pakketten:

sudo apt update && sudo apt install --only-upgrade nodejs && node --version

Met nvm:

nvm install 24.22.1 && nvm alias default 24.22.1

Containers: wijzig de basisimage naar een vaste versie, bijvoorbeeld node:24.22.1-alpine of node:22.23.4-bookworm-slim, bouw opnieuw en implementeer opnieuw. Het bijwerken van de host verandert niets aan wat in een container draait.

Serverless- en hostingplatforms: op Vercel worden projecten op 22.x en 24.x door Vercel gepatcht, en Vercel voegde firewallregels toe tegen de binnenkomende aanval; projecten die nog op 20.x draaien, moeten overstappen op 22.x of 24.x en opnieuw worden geïmplementeerd. Controleer bij andere platforms het bericht van de provider en implementeer opnieuw zodra de gepatchte runtime beschikbaar is.

Distributiepakketten zoals het eigen nodejs-pakket van Ubuntu lopen vaak achter. Toont node --version niet 22.23.4, 24.22.1 of 26.12.1 (of een distributiebuild die deze CVE's noemt), gebruik dan de officiële releases.

Stap 3: herstart en controleer

Een draaiend proces behoudt de oude runtime tot het opnieuw wordt gestart. Na een pakketupdate op Linux toont dit de node-processen die nog de vervangen binary draaien:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'node.*(deleted)'

Herstart die services (bijvoorbeeld met systemctl restart, pm2 reload all of een nieuwe implementatie) en voer de commando's uit stap 1 opnieuw uit.

Als u vandaag niet kunt bijwerken

Geen van deze maatregelen vervangt de update, maar ze verlagen het risico voor een paar dagen:

• Weiger Brotli-requestbodies voordat ze de applicatie bereiken, bijvoorbeeld in NGINX met if ($http_content_encoding ~* br) { return 415; }, of in een middleware die vóór de bodyparsers draait.
• Schakel automatische decompressie uit voor verzoeken naar niet-vertrouwde servers: decompress: false in axios en got, compress: false in node-fetch, of de request() van undici, die niet decomprimeert. De ingebouwde fetch() kunt u niet uitschakelen.
• Voer het ophalen van door gebruikers aangeleverde URL's uit in een apart proces met zo min mogelijk rechten.
• Weiger namen met een NUL-teken voordat u invoer van buitenaf aan dns.resolve doorgeeft.

Weet u niet zeker welke van uw diensten onbetrouwbare data decoderen, of hebt u hulp nodig bij het bijwerken van een productiesysteem zonder downtime, dan kunnen onze teams voor veilige software en beheerde beveiliging u helpen.