Bug in Node.js maakte op afstand uitvoeren van code mogelijk

Node.js heeft een patch uitgebracht voor een ernstige bug die het mogelijk maakte op afstand code uit te voeren. De kwetsbaarheid zat in compressielibrary Brotli. Het Nationaal Cyber Security Centrum (NCSC) schat de kans op misbruik niet heel hoog in, maar áls de bug wordt uitgebuit, kan de schade ernstig zijn.

De bug wordt ook wel Node2Shell genoemd door Aikido, dat de kwetsbaarheid als eerste ontdekte en dat bij Node.js aandroeg. De bug wordt getrackt onder CVE-2026-111497. De kwetsbaarheid stelt een aanvaller in staat om op afstand zonder authenticatie een bufferoverflow te veroorzaken. Daardoor is het mogelijk om informatie uit het geheugen te achterhalen, een dienst geforceerd te stoppen en in ernstige gevallen zelfs code uit te voeren op een systeem. Andere beveiligingsonderzoekers hebben inmiddels een proof-of-concept van de bug getoond.

De bug zit specifiek in de Brotli-decoder. Dat is een compressiebibliotheek van Google, waarvan Node.js een eigen versie gebruikt. De kwetsbare library zit in versies 22.x, 24.x en 26.x van Node.js. In versies 22.23.4, 24.22.1 en 26.12.1 zijn de library's gepatcht. Versies 20.x, 23.x en 25.x van Node.js zijn al langer end-of-life en krijgen geen updates meer.

Inmiddels waarschuwt ook het Nederlandse Nationaal Cyber Security Centrum voor de bug. "Het Nationaal Cyber Security Centrum (NCSC) beoordeelt de kans op misbruik als 'gemiddeld', maar de mogelijke schade als 'groot'. Het advies is om de nieuwste beveiligingsupdates zo snel mogelijk te installeren", schrijft de instantie.

Correctie, zaterdag – In de tekst stond aanvankelijk dat de bugs zijn gepatcht in Node.js-versie 24.11.1, maar dat moest 24.22.1 zijn. Het artikel is hierop aangepast.

Hack cyber malware hacker hackers ransomware. Beeld: Getty Images/Cultura RF

Door Tijs Hofmans

Nieuwscoördinator

23-10-2026 • 20:59

71

Submitter: tekken4111

Reacties (71)

Moderatie-faq

Sorteer op:

Weergave:

Is closed source juist nu niet veiliger dan open source in the age of ai (die razendsnel miljoenen lines of code kan doorspitten op programmeerfouten).

[Reactie gewijzigd door FrostHex op 23 oktober 2026 21:50]

Je hebt gemist dat Windows per patch-tuesday tegenwoordig 1000+ bugs fixed? Meerendeel daarvan is door AI gevonden.

Het gebeurt ook vrij regelmatig dat een exploit door AI wordt gemaakt door de oude en de nieuwe binaries te vergeljiken en op basis daarvan te achterhalen wat er lek was.
Je hebt gemist dat Windows per patch-tuesday tegenwoordig 1000+ bugs fixed? Meerendeel daarvan is door AI gevonden.
...door een AI gevonden die Microsoft gebruiktte om die bugs te vinden door het de source code van Windows te geven. Niet door een AI gevonden die willekeurige mensen konden gebruiken en loslaten op Windows' binaries en dat is juist het punt van de vraag hier.
Het gebeurt ook vrij regelmatig dat een exploit door AI wordt gemaakt door de oude en de nieuwe binaries te vergeljiken en op basis daarvan te achterhalen wat er lek was.
...wat dus een probleem is dat al opgelost was.

[Reactie gewijzigd door Kallik op 23 oktober 2026 22:17]

wat niet betekend dat iedereen die patches al geinstalleerd heeft, waardoor misbruik nog steeds mogelijk blijft
Net zoals bij opensource. Dat mensen niet patchen is geen argument, en windows ramt ze tegenwoordig door je strot, waar ik moet toegeven dat veel van mijn Linux systemen minder up to date zijn.

Anyway, ik denk dat de vraag hier is: jarenlang is er geclaimd dat opensource veiliger is dan closed source, veel ogen die er naar kijken, dus ook veel kans dat fouten door white hat gevonden worden en gepatched. Maar las laatst dat de linux kernel in de volgende kernel versie een hoop hardware support gaat droppen omdat er al jaren niemand naar gekeken heeft/geupdate heeft, alsook een verhaal van iemand die een library gemaakt heeft die nu (rechtstreeks of via andere libraries) in zowat alle programmas zit (ben kwijt welke), dat hij er eigenlijk vanaf wilt omdat het te veel tijd neemt, hij de enige dev is en niemand het wilt overnemen...

Als je die verhalen hoort, weet je gewoon dat er hopen fouten in het systeem zitten die niet opgelost gaan worden "omdat het opensource is. En omdat ai zo goed is met code, dus relatief makkelijk uit te buiten, laat het een populaire opensource app analyseren, alle dependencies in kaart brengen, en de slechts onderhouden ervan analyseren.

Bij closed source hoop ik (bij grote bedrijven dan) dat er altijd iemand code reviewed voor die opgenomen wordt, dat er regelmatig audit 9p gedaan wordt, en hebben we nu net het voordeel dat de code er niet is, waardoor ai het nog steeds moeilijk heeft (voor zolang dat nog duurt).

Dus ja, is opensource nog steeds veiliger (de fouten zijn nu wel gepatched, voor dit...), of is closed source (waar een bedrijf nu ook ai kan loslaten op zijn code, met wat we nu zien bij Microsoft als gevolg, maar publiekelijk nog steeds de "extra security through obfuscation ") nu veiliger?
Ik denk dat je audits en op code wat overschat. Draai al wat jaren mee en als er een kostenpost is die je snel wegsnijd is die het wel.
Ok, laat ons die dan nog schrappen, komen we nog steeds dat dit bij opensource blijkbaar ook vaak niet gedaan wordt. Dus de vraag blijft dan of, nu we ai hebben, closed source (opnieuw, die het bedrijf zelf wel door ai kan trekken) ondertussen niet veiliger is, net omdat het vinden van bugs door mensen met slechte intenties moeilijker is zonder source code.

Ik ga geen statements maken, ik ken er niet genoeg van, dus is een oprechte vraag, maar zie de laatste tijd toch veel posts (paar dagen geleden nog php issues, al heb ik totaal niet gelezen wat de oorzaak was, nu dit) over vrij grote bugs in opensource.
Ik heb niet de illusie dat closed source veiliger is dan open source of omgekeerd: in beide schiet je gaten als je hard genoeg zoekt (ook ervaring). Het is meer: wat valt het meeste op. Een hack via een netwerk is altijd zichtbaarder dan een local exploit en feit is dat de bulk van de websites gemaakt worden met opensource componenten (want lekker goedkoop) en bedrijven niet of nauwelijks tijd en geld geven om ze behoorlijk te onderhouden. Dus het is een logisch gevolg van penny wise pound foolish zoals de Engelsen zeggen.
Ok, laat ons die dan nog schrappen, komen we nog steeds dat dit bij opensource blijkbaar ook vaak niet gedaan wordt. Dus de vraag blijft dan of, nu we ai hebben, closed source (opnieuw, die het bedrijf zelf wel door ai kan trekken) ondertussen niet veiliger is, net omdat het vinden van bugs door mensen met slechte intenties moeilijker is zonder source code.
AI is tegenwoordig zelfs in staat om aan de slag te gaan met de machinetaal in binaries.
Gevonden door MS zelf, en MS heeft de code natuurlijk wel..
Hoe zit dat dan met de MS Edge webbrowser? Onder de motorkap is dat Chromium, dus opensource. Voor Chromium krijg ik zowat wekelijks beveiligingsupdates. Wat doet Microsoft daarmee? Opsparen voor de maandelijkse update van MS Edge op patch tuesday? Dat zou betekenen dat MS Edge een groot deel van de maand kwetsbaar is.
Edge doet niet mee met Patch Tuesday. Die volgt de cyclus van Chronium en ontvangt heel vaak patches.
Dankjewel voor de verheldering! Kom zelf uit de UNIX en Linux hoek, dus heb weinig parate kennis van MS Windows. De laatste keer dat ik beroepsmatig de degens heb gekruist met Redmond was in het Windows XP / Windows Server 2003 tijdperk. Een van de redenen dat ik op Tweakers kom is om te zien 'How the Other Half Lives'. :)
Los daarvan hebben ze al een tijd mot met een white/gray hat hacker die constant Windows lekken lekt. Dus ga er maar van uit dat het ook met closed-source software makkelijk kan.
Nou bijv. Fortinet heeft ook met enige regelmaat spoed-exploit-fixes terwijl dat zeker niet OpenSource is.

En ook Cisco en ongetwijfeld ook vele anderen die me niet zo snel te binnen schieten.

Ik weet zo even geen closed source internet-connected software te verzinnen. Vraag me ook af hoeveel daarvan meer 'in stilte' gepatcht wordt omdat dat niet zozeer draait in omgevingen waar de gemiddelde Tweakers bezoeker mee te maken heeft en/of dat dat via dealers gaat die dan ook dergelijke spoed updates doorvoeren.

Kortom, met de meer closed software waar een zeer uitgebreid service/licentie-model aan hangt krijg je daar minder van mee.

Maar wel interessante vraag of daar nu ook veel sneller veel ernstige bugs gevonden worden.
De vraag is niet of closed software meer of minder erngstige bugs bevatten.
Volgens mij zijn hier onderzoeken naar gedaan en verschilt het niveau niet veel van elkaar.

Het gaat erom of closed software veiliger is, m.a.w. meer of minder kans heeft dat bugs actief misbruikt worden.

Als Cisco zelf een bug ontdekt (zonder dat anderen het hebben gezien en misbruikt hebben) en een update vrijgeeft... dan is er geen probleem...

Ik denk dat voor nu het antwoord simpel is: Open source is tegenwoordig een stuk onveiliger dankzij ai.
[...]

Ik denk dat voor nu het antwoord simpel is: Open source is tegenwoordig een stuk onveiliger dankzij ai.
Nou ik vraag me dus af of dat zo is.

Je kunt AI prima een applicatie laten decompilen en bugs voelen.
Decompiled code is voor een mens alsnog lastig leesbaar, omdat je de originele namen van functies en variabelen er niet bij hebt. Maar AI heeft daar geen/minder last van.

Ik denk dat er voor OpenSource best wel veel aandacht is voor bugreports enz. dus vraag me af of OpenSource gevaarlijker is door AI.
Werkt het decompilen zo goed (geen idee hoor, nooit gedaan)?

Kun je win11.exe geven en die laten decompilen?

En veel closed sourse software moet je eerst nog zien te krijgen, toch?

Chipsoft.exe is niet even te downloaden. Toch? Als je genoeg tijd en energie erin steekt, kun je 'm vast wel ergens halen. Maar het niet even een github repro die je kloont...
Geen idee of je die software makkelijk kunt verkrijgen. Maar in principe als je de code kunt uitvoeren, kun je ook bij de executables komen.

En ja, je kunt met AI gecompileerde code laten analyseren op bugs.

Decompilen kan je met elke software doen (al decennia). De vraag is alleen of het heel erg zinvol is.
Wat je terugkrijgt is namelijk niet de exacte originele source code, maar iets wat je opnieuw zou kunnen compileren tot een werkende binary.

Bij het compileren zit er vaak nog een precompiler-stap tussen, daarnaast heb je een optimizer stap en uiteindelijk dus de compilatie en dan het linken. (althans zo gaat het met C++, sommige andere talen zal het hier en daar een fractie anders gaan)

Vooral de optimalisatie-stap kan heel goed code die geschreven is helemaal anders maken voordat het de compiler in gaat.

De linker zal voor een release-build waarschijnlijk alle functienamen en variabele namen compleet vernaggelen, zodat het voor een mens veel en veel lastiger is te lezen. Voor een AI hoeft dat helemaal geen probleem te zijn. Die kan prima programmeerpatronen herkennen ookal zijn de functienamen en variabelen compleet random.
Interessante vraag. Ik speelde ook met die gedachte. Maar als je vervolgens ziet dat close-source software zoals Photoshop ook puur op basis van extern-observeerbaar gedrag nagebouwd kan worden op het niveau van ArtCraft... dan vraag ik me af of dat voordeel lang blijft bestaan.

Waarschijnlijk zal AI vrij snel in staan zijn ook zonder de broncode, maar puur op basis van de gecompileerde binary, dit soort kwetsbaarheden te vinden.

Ja, dat zijn twee heel verschillende use-cases, maar ik bedoel te zeggen dat het begrip van hoe code/algoritmes werken dat AI's ten toon spreidden zo hard toeneemt dat ze waarschijnlijk de human-readable source niet persé nodig zullen hebben om een 'mentaal' model van wat de binary doet te vormen, en dus kwetsbaarheden te beredeneren.

[Reactie gewijzigd door multiplexer op 23 oktober 2026 21:55]

Er is inderdaad nu iets dat 'rea' heet, wat staat voor 'reverse engineer anything'. daarmee kan AI veel nabouwen op basis van alleen de binary...

...Wat overigens meestal wel illegaal is, want dit is dan geen clean room implementatie.
Er zijn al papers geschreven over ai nr. 1 laten reverse engineering en documentatie schrijven en dan ai 2 het laten bouwen. Zo is de pc ooit gecloned en zie waar we nu zijn.
Als de binaries beschikbaar zijn is closed source geen heel grote barriere want je kunt de binary decompileren (zie REA (reverse engineer anything) en ghidra) en door AI laten annoteren en zoeken naar kwetsbaarheden. Op die manier worden veel routers, TVs, telefoons etc de firmware reverse engineered om er eigen software op te laten draaien bijvoorbeeld. Of een virus/malware/backdoor/botnet/ransomware erin te installeren als je minder goede bedoelingen hebt.

De gedachte nu is dat bedrijven hun binaries in de cloud laten draaien zodat hackers niet over de optie beschikken deze in te zien, tenzij ze 't platform zelf kunnen hacken en de source/binaries kunnen downloaden natuurlijk.
"if you know assembly everything is opensource"
Precies maar dat snapt toch niet iedereen.
Een LLM wel.
En die leest/ "begrijpt" de code ook nog eens razendsnel. En als daarmee fouten worden ontdekt is de route naar exploit ook te vinden.
Alleen software die lokaal draait dan
Voer maar eens een closed-source gecompileerde executable aan AI en vraag het om die om te zetten naar source code.

Dat werkt dus prima. En die source code is voor ons mensen lastig leesbaar (want: obscure functienamen en variables), maar een AI kan die code prima ontcijferen en er lekken in vinden.
de originele functienamen en variables komen niet meer voor in de gecompileerde exe, maar dat wil niet zeggen dat ze niet meer te herleiden zijn en dan kan je AI of zelf de naam/functie aan geven dat je maar wil in theorie.
Heb je dat geprobeerd met exe bestanden >100mb?
Lees ook vooral review: Gaten in het hart van Linux: vijf vragen over snel opeenvolgende kernelbugs. Hier wordt daar verder op ingegaan.

Tl;dr dat is momenteel wel de hypothese. Al hangt dat ook af van de beschikbaarheid van de AI modellen voor bedrijven. Want, als andere mensen de source code kunnen doorlichten met AI, dan kunnen de ontwikkelaars dat ook.
"Want, als andere mensen de source code kunnen doorlichten met AI, dan kunnen de ontwikkelaars dat ook."

Er zit alleen wel een verschil tussen 'kunnen' en 'doen'.
Hier is een comment van een tijdje geleden waar ik daar antwoord op geef: Aftansert in 'Citrix waarschuwt: patch direct vanwege kritieke kwetsbaarheid in NetScaler ADC'

tl;dr: Open source is in de meeste gevallen veiliger omdat het het speelveld tussen verdediger en aanvaller gelijker maakt, in plaats van een groot voordeel voor de aanvaller.
Voor populaire packages wellicht, maar er zijn er ook genoeg met een enkele is handvol maintainers. Maar deze packages zijn wel onderdeel van een hele keten.
Met opensource kan je dat ook zien, hoeveel updates iets krijgt hoeveel ontwikkeling er is en met die data kan er ook makkelijk een target gevonden worden.
Terwijl bij closed source het gewoon een pakket is waarvan wellicht ook delen van de code nooit is gewijzigd maar dat zie je simpel gezegd niet.
En vergeet ook niet bij open source sociaal Engineering, dus iemand bied zich aan als maintainer, doet dit ook werkelijk een langzaam aan wordt er code toegevoegd die bewust fouten bevat
Voor ai is closed source net zo open als open source. Dat 'jij' decompiled code niet goed begrijpt wil niet zeggen dat AI dat ook niet begrijpt, die hebben gewoon geleerd hoe een compiler werkt en wat voor 'human unreadable' binaries de compiler maakt obv 'human readable' code.
Welke closed source software? Alles wat je kan downloaden is open source, als het niet vandaag is dan wel morgen.

[Reactie gewijzigd door BlaDeKke op 24 oktober 2026 03:05]

Met komst van REA en Ghidra MCP valt closed source ook niet buiten schot.
Het is een inhaalslag nu. Het wordt beter, niet slechter. Windows is inmiddels ook "open source" met die AI reverse engineering tooling.
Denk het niet meer. Decompilen en met de hand een binary doorspitten was vroeger heel erg veel werk. Nu kan een ai in een paar uren/dagen alles mooie namen geven, veel voorkomende code herkennen en vervangen met een standaard implementatie en logica blokken voor je toevoegen.

Dan heb je een bijna identieke broncode als het origineel die je op fouten kan doorspitten.
Gecompileerde code kan evengoed door een ai gelezen worden, instructiesets van CPU en GPU zijn gekend, alsook de structuur van executables.

Ik heb vroeger redelijk wat geprogrammeerd op de 6502 CPU, in assembly, na verloop van tijd kon ik gewoon de hex code lezen.

[Reactie gewijzigd door mbbs1024 op 24 oktober 2026 14:55]

Security through obscurity is géén betrouwbare beveiligingsstrategie, maar is wel degelijk een extra beschermingslaag!

Ik heir al veel "foute" vergelijkingen. Photoshop of Windows is misschien wel closed-source, maar je installeert het op je eigen devices. Cloudsoftware waarbij alle datahandling en security op afgeschermde servers plaatsvinden is niet te vergelijken.

Ik laat mijn eigen spul door security-AI pentesten met volledige toegang tot de codebase, databasestructuur en alles eromheen. Voor bewijslasten voer ik AI-gebaseerde black-box pentests uit. Het verschil is gigantisch. Die black-box tests vinden nog geen honderdste van wat een AI met toegang tot de codebase vindt.

Niet iedere kwetsbaarheid is ook daadwerkelijk exploitable. We werken als developers natuurlijk met redundant layered security zodat niet alles opeens instort als we ooit één dingetje per ongeluk verpesten. Vaak moeten er allerlei verschillende zaken samenkomen en er zit ook verschil tussen een slordige implementatie en bv een datalek.

Mijn software is volledig maatwerk, zonder frameworks als Laravel of React. Toch blijf je afhankelijk van onderliggende technologieën zoals PHP, Node.js of Rust en veel anderen van frameworks zoals b.v. Laravel. Kwetsbaarheden daarin verdwijnen niet magisch omdat je software closed-source is. Goede architectuur en aanvullende beveiligingslagen heb ik bijvoorbeeld behoorlijk goed opgezet, maar zoiets als PHP2Shell blijft gewoon een gevaar, punt.

Maar je raakt een punt dat ik zelf met regelmaat maak: het idee dat open-source automatisch veiliger is omdat iedereen de code kan controleren, is een illusie. In de praktijk gebeurt dat eigenlijk relatief weinig en bestaat het vooral uit requests of bijdragen in de vorm van nieuwe/toegevoegde functionaliteiten, terwijl kwaadwillenden óók volledige toegang hebben en er geen enkele garantie is dat zij gevonden kwetsbaarheden melden.

Met AI wordt het vinden van kwetsbaarheden in een beschikbare codebase ineens veel sneller en toegankelijker en is dat gevaar, zoals jij al benoemd, echt exponentieel veel groter nu. Closed-source is absoluut geen garantie voor veiligheid, maar het dwingt een aanvaller in ieder geval om zonder die interne kennis te werken.

Ik zou wat dat betreft dus wel zeggen: Ja, security through obscurity is een nuttig wapen tegen iets als AI.
Al is het maar omdat je niet flagged wordt als 'vulnerable' vanuit automatic bot-crawling.
volgens mij vergeten veel mensen een antwoord te geven op je vraag.

Dus bij deze: ja, closed source is (iig tegenwoordig) veiliger dan open source.
In theorie maakt het voor een AI niets uit of de "bron" die wordt uitgelezen source code tekst is die leesbaar is door een mens, of binaire machine code. Praktisch gezien is binaire code voor een AI zelfs makkelijker dan source tekst omdat de binaire code niet meer afhankelijk is van de gebruikte compiler en instellingen voor die compiler.

De vraag is alleen of de gebruikte AI is getraind op alleen source code tekst, of ook op binaire code.
Dat niet alleen, AI maakt ook wel degelijk gebruik van naamgeving en comments om de intentie van code te gebruiken, dus het heeft zeker ook een handicap als het alleen de binaries kan bekijken. Alleen niet zo’n grote handicap als wanneer een mens dat zou moeten doen.
Alleen bij source code moet je meestal maar raden wat de intentie is want de meeste source code komt zonder comments. Binaire code /is/ de intentie. Er hoeft niet meer te worden nagedacht over wat de binaire code gaat doen, want dat is 100% deterministisch vastgelegd in silicium. Comments daarintegen kunnen zelfs afleidend werken want die kunnen een heel ander verhaal vertellen dat wat de uiteindelijke code gaat doen. Bij binaire code heb je daar geen last van.
Dat comments en andere hints een ander verhaal vertellen is dan dus juist een voordeel voor een LLM die op zoek gaat naar bugs. Juist dan kan je makkelijk verschillen zien tussen intentie en wat het echt doet.
Dat is niet duidelijk. Wat ik wel frappant vond is dat het aantal aanvallen 10 tot 50 keer hoger ligt voor open source. Zeker als het ook iets met data opslag doet. Zo draait WordPress niet 100% de open source versie, zat ergens in deze podcast https://open.spotify.com/episode/3ZFhGnDnl5kTmpd1wKjuhU?si=4KEUZvwKQiKqy8BNdnzDOw&utm_source=copy-link.

Een programmeertaal is natuurlijk een beetje lastig closed source. Al zou je met genoeg tokens/geld een eind moeten kunnen komen. Maar dan moet je dus ook als zelf (automatisch) debuggen en fixen.
Nee. AI's kunnen net zo makkelijk machine-instructies lezen als enige andere programmeertaal. Het vermogen om dat te doen hangt helemaal af van de trainingsset, en die is in het geval van software echt enorm en ook heel goed synthetisch te voeden om AI te leren wat de bekendste compilers zoal doen met veelvoorkomende patronen in hun inputs. Voeg daaraan toe dat AI's vaak de binary zelf ook nog kunnen en mogen runnen, en ze kunnen er op basis van geobserveerd gedrag eindeloos mee gaat zitten prutsen om te achterhalen wat iets precies doet.
Wel gaaf, met AI wordt nu alle open source code dusdanig doorgespit door iedereen en nogwat, dat er straks gewoon uberhaupt geen bugs meer in zitten. Meer secure dan dat wordt het niet.

We moeten nu gewoon even door de zure appel heen bijten. Maar ik denk dat dit een tijdelijke fase is. Uiteindelijk zal het een zege zijn.
met AI wordt nu alle open source code dusdanig doorgespit door iedereen en nogwat, dat er straks gewoon uberhaupt geen bugs meer in zitten.
Is dat wel zo? Ik vraag het me af. Dat is ons de afgelopen 30-40 jaar nooit gelukt.

De volgende generatie LLM of een heel slim persoon of een autist, kan straks nog steeds fouten of kwetsbaarheden vinden. Ook grote kwetsbaarheden.

Niets is perfect. En er is (te)veel code in omloop, met allemaal afhankelijkheden van libraries en andere code-sets. Die ook allemaal om de haverklap vernieuwd worden.
Bor Coördinator Frontpage Admins / FP Powermod
@perry1 • 23 oktober 2026 23:35
Is dat wel zo? Ik vraag het me af.
Nee natuurlijk is dat niet zo. Onfeilbare software bestaat niet. Ook Ai maakt fouten en vind niet alle fouten. Laat bv vibecoding nu juist ook enorm in opkomst zijn waar meer dan eens onveilige code wordt opgeleverd.

Het idee dat " dat er straks gewoon überhaupt geen bugs meer in sofware zit" is op zijn positiefst wishful thinking maar ook wel een beetje naief.

[Reactie gewijzigd door Bor op 23 oktober 2026 23:36]

dat is niet waar. Er zullen altijd bugs in software blijven zitten. AI maakt ook fouten. Bij het PHP2Shell probleem van afgelopen week was het niet AI zelf die het probleem vond, er was iemand nodig met de juiste skills om het probleem te achterhalen, te testen en te classificeren. Zonder die persoon was het AI waarschijnlijk niet gelukt.

Dat het nu sneller gaat, en 'makkelijker' is ja daar is iets van te zeggen. Ook van obscure bugs die in een heel donker edge case hoekje zitten worden nu gevonden.
Als ik zo lees is dit veel breder dan alleen nodejs omdat het in de brotli library zit?
Volgens mij ook, ook. Net bijv. Zit in Google brotli niet perse nodejs.
Na PHP2Shell kon je er op wachten dat er meer incidenten zo'n label gingen krijgen. Ben benieuwd hoe de komende twee weken er uit komen te zien, na o.a. Heartbleed en Shellshock verbaast het mij niet dat er oude, niet-ontdekte bugs in veelgebruikte talen/bibliotheken zitten.

Hoe eerder we hier tegenaan lopen hoe beter 🤷
Klinkt een beetje als mee proberen te liften op de hype door het node2shell te noemen. Dus waarschijnlijk een nothing burger. Niet lang na log4shell was er ook een spring4shell wat een enorme nothing burger was.

Een ergerlijk probleem in de security wereld is toch wel de aandachtsgeilheid. Zo veel drama. Maar ook de "time to marketing" wens die voor serieuze problemen zorgt door coordinated disclosures te saboteren.
Helemaal eens. Node2Shell is wel erg overdreven. Er zijn wel grotere vulnerabilities geweest die ze dan node2shell hadden mogen noemen :+
Wij mochten nog even voor het weekend al onze images die gebruikt maakten van Node updaten en uitrollen. Misschien overdreven maar we hoeven iig voor deze CVE ons geen zorgen te maken dit weekend.
Thanks gelijk een update gedaan :D
synology pusht bij mij nu vrij hard: DSM 7.4.1-90080 Update 1
echter blijkt dat dit nog het patchen van de PHP kwetsbaarheid betreft en niet CVE-2026-111497
Dank je!

Ik meende afgelopen week nog een update gedaan te hebben. Dat hard pushen valt wel mee; ik moest het zelf gaan zoeken, dowloaden en installeren.
Ook wel belachelijk dat nodejs het merendeel van zijn dependencies bundelt. Nu ben je er niet gewoon van af met een brotli update, nu moeten daarenboven de nodejs devs die wijziging doorvoeren en de distros nieuwe packages uitbrengen. Op mijn Gentoo wordt nodejs gelukkig standaard gebouwd met --shared-brotli, dus als er een probleem zit in brotli is een update enkel daarvan genoeg. Geen fan van vendored en/of static libs om die reden. Heeft er iemand echt niet te versmaden voordelen in gedachten?
Ach. Hier is het erger. Ik gebruik Gulp en moet van v5.0.1 opeens downgraden naar v3.9 door een exploit in een andere core package.

Moest alles met de hand weer naar v5 brengen omdat ik alleen gulp gebruik om mijn eigen scripts te bundelen in es2020.

En v3.9 heeft natuurlijk ander bugs, exploits en geen es2020 ondersteuning

[Reactie gewijzigd door DJMaze op 24 oktober 2026 01:31]

Twee Python brotli implementies blijken ook vatbaar te zijn. https://opensourcemalware.com/blog/node2shell-affects-python

Om te kunnen reageren moet je ingelogd zijn