Onderzoekers van Imperva hebben een proof of concept laten zien waarbij Node2Shell RCE Brotli mogelijk wordt: een applicatie kan op een officiële Node.js build uit zichzelf code laten uitvoeren door aanvaller-gedefinieerde Brotli-data. Het gaat om een kwetsbaarheid in de Brotli-decoder die standaard in Node.js is ingebouwd.
Belangrijk is dat Node.js de bug heeft gerepareerd en dat de fix inmiddels beschikbaar is. Als jouw software Brotli decodeert—bijvoorbeeld via HTTP-body parsing of via fetch—dan wil je snel controleren of je op een versie zit die nog kwetsbaar is.
Wat is er precies aangetoond met Node2Shell?
De onderzoekers lieten zien dat in hun testomgeving code kon worden uitgevoerd door “geknutselde” Brotli-data aan de decoder aan te bieden. Ze deden dit op een officiële Node.js 24.22.0 Linux arm64 image, zonder debugger en zonder een aangepaste build.
De uitvoering verliep niet in één keer: Imperva geeft aan dat code-executie meerdere pogingen vergde in hun specifieke setup. Tegelijk laat dit vooral zien dat de aanval niet alleen theoretisch is, maar afhangt van de manier waarop de fout in de decoder zich verhoudt tot de exacte runtime-omgeving en de gebruikte opbouw van de gegevens.
Welke Node.js releases en omgevingen zijn relevant?
De kwetsbaarheid zit in de Brotli-decoder die Node.js bundelt. Daardoor gaat het niet om één specifieke image, maar om toepassingen op meerdere Node.js “lijnen”. Imperva benoemt dat de issues samenhangen met versies in de 22.x-, 24.x- en 26.x-reeksen.
In hun tests werkte dezelfde aangeleverde data op de beveiligingsgebreken-versie (24.22.0) wel, terwijl op de gepatchte versie 24.22.1 de data werd geweigerd en er geen code werd uitgevoerd.
Daarnaast geldt een belangrijke beperking: Imperva’s demonstratie dekt niet alle architecturen en niet alle versies binnen die reeksen. Wel is het onderliggende principe hetzelfde: als jouw Node.js build kwetsbaar is en jouw applicatie onbetrouwbare Brotli verwerkt, is het risico reëel.
Hoe komt een aanval bij de Brotli-decoder?
De decoder kan bereikt worden via twee routes in Node.js-gestuurde webapplicaties:
- HTTP response-pad: via Node.js’ ingebouwde fetch() wanneer een applicatie een Brotli-gecomprimeerde respons verwerkt.
- HTTP request-body-pad: wanneer een middleware Brotli decodeert bij binnenkomende verzoeken.
Op een “kaal” Node.js HTTP-server ontvangt de applicatie niet automatisch een Brotli request body die vanzelf gedecodeerd wordt. De decoding komt vooral in beeld wanneer je middleware gebruikt die Brotli ondersteunt.
Concreet noemt Imperva dat Express 5 body parsers (zoals express.json(), express.urlencoded(), express.text() en express.raw()) Brotli-aanvragen kunnen decoderen op een route. Daarbij is Express 5.0.0 tot en met 5.3.0 in de tests betrokken, en ook body-parser 2.0.0 tot en met 2.3.0 op vastgepinde versies.
Wat gebeurt er technisch bij de bug?
Imperva beschrijft dat de oorzaak zit in hoe de decoder omgaat met een “onmogelijke” situatie in een Brotli-stream. Tijdens het decoderen kondigt de stream aan welke bloktypes gebruikt worden. De testdata bracht de decoder in een situatie waarin de stream zelf eigenlijk aangeeft dat die blokwijziging niet zou mogen plaatsvinden.
In plaats van correct af te breken, belandde de decoder in een ongeldig toestandsverloop. In een extra test met een memory sanitizer wees Imperva erop dat er vanuit die fout een out-of-bounds write kon optreden—dus een schrijfactie buiten een bedoeld bufferbereik.
Node.js heeft de fix doorgevoerd door een Brotli-patch van upstream te importeren. Die patch zorgt ervoor dat de decoder in die situatie stopt met een format error in plaats van door te gaan.
Is er al misbruik in het wild?
Volgens de onderzoekers is er geen exploitatie in het wild gemeld tot en met 22 oktober. Dat betekent niet dat je kunt wachten—RCE-achtige bugs worden vaak pas later massaal misbruikt, zeker wanneer er tooling en varianten verschijnen.
Daarom is het verstandig om de impact voor jouw omgeving nu te beoordelen en de correctie door te voeren.
Wat moet je doen: update en controleer je Brotli-decodering
De kernactie is simpel: upgrade naar een gepatchte Node.js release. Er is geen Node.js-runtime workaround genoemd die het probleem opvengt zonder te updaten.
Omdat het risico niet alleen in “je code” zit, maar ook in de container images en andere artifacts waar Node.js in zit, is het belangrijk om je deploy- en build-pipeline te checken. Een pakketinventaris mist soms precies die gebundelde binaries of image-lagen.
Praktische checklist
- Update Node.js naar de releases waarin de fix zit (Imperva noemt 24.22.1 als gepatchte versie binnen hun test).
- Vervang container images of andere deliverables waarin een Node.js binary is gebundeld.
- Controleer of je onbetrouwbare Brotli verwerkt op endpoints waar je request bodies decodeert (bijvoorbeeld met Express 5 body parsers).
- Let op de response-route als je fetch gebruikt om Brotli responsen te verwerken.
- Ondersteunde lijnen alleen: Imperva geeft aan dat end-of-life lijnen (bijvoorbeeld 20.x en ouder) geen fix ontvangen en dat je moet migreren naar een ondersteunde Node.js lijn.
Beperkingen waar je direct aan kunt werken
Voor situaties waarin je niet meteen kunt deployen, benoemen de onderzoekers een beperking van onbetrouwbaar Brotli-verkeer waar dat praktisch is. Dat is geen vervanging van de update, maar kan je exposure tijdelijk verlagen.
Imperva heeft zelf ook regels toegevoegd aan hun web application firewall en die regels getest tegen de aanval zoals ze die konden reproduceren. Ook Vercel gaf aan dat ze op 21 oktober regels hebben toegevoegd die de aanval in inbound requests blokkeren—met een nuance: die regels dekken niet per se Brotli responses die jouw applicatie ophaalt met fetch.
Met andere woorden: netwerk- en WAF-regels kunnen helpen als extra laag, maar de echte oplossing blijft de gepatchte Node.js versie.
Waarom dit ook raakt aan supply chain security
Deze demonstratie benadrukt dat “officiële builds” en “standaard decoders” ook kwetsbaar kunnen zijn. Omdat Node.js de Brotli-decoder bundelt, komt de impact bij veel applicaties terecht zonder dat ontwikkelaars zelf extern Brotli-code toevoegen.
Dat maakt deze case relevant binnen Software Supply Chain Security: je moet niet alleen naar je eigen dependencies kijken, maar ook naar de runtimes en binaries die in je images en deployment artifacts terechtkomen.
Als je bredere supply chain-risico’s rondom kwetsbaarheden in web- en buildketens wilt vergelijken, kan ook dit artikel je helpen: UpdraftCentral backdoors via gestolen sleutels.
Extra context: vergelijkbare RCE-risico’s
RCE-achtige bugs verschijnen regelmatig in de vorm van “net genoeg parsing” die verkeerd afloopt. Daardoor is het nuttig om aandacht te hebben voor patronen rond decoderingslogica en parsing in runtimes en libraries—zeker wanneer input van buiten komt.
Daarom is het ook interessant om te lezen hoe andere actuele kwetsbaarheden in applicatiecomponenten doorwerken in exploiteerbaarheid, zoals in dit overzicht: SQL-injectie in VeloCloud Orchestrator: zero-day misbruikt.
Conclusie
Node2Shell RCE Brotli is een duidelijke waarschuwing voor teams die Node.js gebruiken in combinatie met Brotli-decodering. Imperva heeft aangetoond dat speciaal vervaardigde Brotli-data in een kwetsbare Node.js build kan leiden tot code-executie, waarna Node.js de bug heeft gepatcht.
De juiste volgende stap is daarom: update naar de gepatchte Node.js releases, vervang images en artifacts waarin Node.js is ingebouwd, en beperk—als tijdelijke maatregel—onbetrouwbaar Brotli-verkeer op relevante routes. Zo voorkom je dat een decoderfout uitgroeit tot een serieuze aanval op je productieomgeving.
Bron: https://thehackernews.com/2026/10/researchers-demonstrate-node2shell-rce.html
