Sandboxing is bedoeld om onbetrouwbare code veilig in te sluiten. Toch melden onderzoekers nu een Isolated-vm kwetsbaarheid die de grens tussen sandbox en host-app kan ondermijnen. Daarmee bestaat het risico op een sandbox-escape en mogelijk zelfs vergaande aanvallen, afhankelijk van hoe de library in jouw omgeving wordt gebruikt.
De issue is gerapporteerd onder GHSA-864f-rcv7-6rh4 en (nog) zonder toegewezen CVE. Alle versies tot en met 7.0.0 vallen eronder. De fix is beschikbaar in 6.2.0 en 7.0.1, die eerder in dezelfde maand zijn uitgebracht.
Wat is Isolated-vm en waarom wordt het gebruikt?
Isolated-vm is een open-source Node.js-bibliotheek waarmee je untrusted JavaScript kunt uitvoeren binnen een V8 Isolate. Een Isolate is een onafhankelijke instantie van de V8 JavaScript-engine. Het doel is dat meerdere sandboxed omgevingen tegelijk kunnen draaien zonder data te delen of elkaar te verstoren.
In de praktijk betekent dit dat je doorgaans waarden niet zomaar kunt doorgeven tussen de “normale” Node.js-thread en de geïsoleerde worker. Isolated-vm pakt dat op met een mechanisme dat werkt met een klasse genaamd ExternalCopy: daarmee kun je objecten serialiseren uit de host-context en deserialiseren in de guest (sandbox).
Waar zit de Isolated-vm kwetsbaarheid precies?
De onderzoekers plaatsen de oorzaak bij ExternalCopy. Volgens de technische beschrijving kan code binnen de sandbox via een fout in de afhandeling van de transferList-optie leiden tot memory corruption in het hostproces.
Het gaat daarbij niet om een falende Isolate-grens op zichzelf. De kern is de “lijm” (C++ koppellaag) die waarden en controle-informatie over de boundary moet overzetten. Als die lijm verkeerd omgaat met een optie, kan een geslaagde aanval de stabiliteit en integriteit van de host raken.
Van crash naar (mogelijk) sandbox-escape
Bij succesvolle exploitatie kan de host-app meerdere gedragingen vertonen. Het minimum dat is aangetoond is een betrouwbare, beheerste crash: een denial-of-service triggerbaar door elke guest die een ivm.Reference krijgt. Zo’n reference is een gangbare manier om een sandbox enige vorm van capability te geven.
Het maximum dat in de demonstratie is onderzocht, gaat verder: onderzoekers rapporteerden een vorm van control-flow hijack van het hostproces. Dat opent in theorie de deur naar remote code execution in de host, als de omstandigheden precies genoeg zijn en de omgeving daar kwetsbaar voor is.
Waarom dit type aanval zo lastig te verdedigen is
Wat extra zorgelijk maakt, is dat de isolatiebouwsteen (de V8 Isolate boundary) volgens de toelichting zelf niet kapot was. De veiligheid ging mis in de laag die overschrijdt: het proces van marshalling, het overzetten van waarden en de verwerking van transfer-gerelateerde metadata.
Daarmee is het type risico herkenbaar voor organisaties die sandboxen inzetten voor bijvoorbeeld scriptuitvoering, plugin-ecosystemen of code die van gebruikers of externe systemen komt. Als jouw systeem sandboxed JavaScript draait, is de kans reëel dat je juist in de waardekoppeling een zwakke schakel hebt.
Welke impact kun je in jouw omgeving verwachten?
De projecthouder benadrukt dat de afgebakende impact in twee smaken komt: betrouwbaar crashen (SIGSEGV) en, onder bepaalde omstandigheden, verdergaande aantasting van de hostflow. Ook wordt gewezen op een bredere erosie van de trust boundary: de “veronderstelling” dat de sandbox geïsoleerd blijft, komt onder druk te staan.
Concreet betekent dit niet automatisch dat elke gebruiker direct remote code execution zal ervaren. De exploitdemonstratie is echter wel zó opgezet dat ze de grenswerking aantoont, waardoor je in elk geval moet uitgaan van een verhoogd risico.
Hoe los je de Isolated-vm kwetsbaarheid op?
De aanbeveling is helder: update naar de nieuwste versie van Isolated-vm voor optimale bescherming. In dit geval zijn dat minimaal de patched releases 6.2.0 of 7.0.1, afhankelijk van je versiepad.
Check daarnaast hoe je Isolated-vm gebruikt:
- Geef je de sandbox ivm.Reference of vergelijkbare capabilities?
- Werk je met de ExternalCopy-functionaliteit en specifiek de transferList-optie?
- Worden onbetrouwbare scripts direct of via extensies door jouw systeem uitgevoerd?
Door dit te beoordelen, bepaal je sneller welke componenten het hardst geraakt worden en hoe urgent je de update doorvoert.
Praktische richtlijnen voor veilige sandboxing
Los van deze specifieke issue kun je je sandboxstrategie aanscherpen. Niet omdat Isolate zelf “slecht” is, maar omdat je wilt voorkomen dat de koppellaag of integratie de zwakte wordt.
- Werk afhankelijkheden bij en houd je Node.js-supply chain actueel.
- Beperk capabilities die je aan de sandbox geeft; elke ivm.Reference vergroot je aanvalsvlak.
- Minimiseer de data-overdracht tussen host en guest waar mogelijk.
- Monitor crashes en onverklaarbaar gedrag in processen die sandboxed code draaien.
Als je dit combineert met een releaseproces waarin patches snel landen, verklein je de kans dat een kwetsbaarheid zoals deze lang in je omgeving blijft hangen.
Vergelijkbare risico’s: beveiliging stopt niet bij de sandbox
Deze gebeurtenis past in een breder patroon: veel aanvallen misbruiken niet per se de “grote” isolatiebarrière, maar de periferie eromheen — vertalingen, bindings, serialisatie of integratielogica.
Heb je interesse in hoe sandbox- of isolatiekeuzes in de praktijk mis kunnen gaan, dan kan dit artikel aanvullend inzicht geven in beveiliging rond ingesloten modeluitvoering: AI modelbeveiliging met sandboxing: leer van CameraSwarm.
Ook voor organisaties die veel met web- of edge-componenten werken, zijn er signalen over hoe vertaallagen en verwerkingsroutes DoS of andere vormen van impact kunnen veroorzaken. Zie bijvoorbeeld: CDN tsunami: HTTP/3 vertaalslag voor DoS.
Conclusie
De Isolated-vm kwetsbaarheid laat zien dat sandboxing meer is dan alleen “een Isolate draaien”. In dit geval kwam het probleem voort uit de ExternalCopy-afhandeling, waardoor code in de sandbox memory in de host kan beschadigen. Daarmee ontstaan risico’s variërend van een betrouwbare crash tot mogelijk verdergaande hostcompromittering.
De oplossing is praktisch: update naar 6.2.0 of 7.0.1 en herzie waar en hoe je sandboxed JavaScript capabilities krijgt en gegevens overdraagt. Door die stappen nu te zetten, herstel je de veronderstelde veiligheid van je isolatiepraktijk.
Bron: https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
