CVE-2026-92948: Kritisk sandkasseflugt i vm2 3.9.6–3.11.6
Kritisk fejl i vm2 3.9.6–3.11.6 tillader sandkasseflugt på Node.js 24+. Opdatér til 3.11.7 nu.
Hvad er det?
vm2 er et JavaScript-bibliotek, der bruges til at køre upålidelig kode i en isoleret sandkasse, så den ikke kan påvirke resten af systemet. CVE-2026-92948 er en fejl i vm2-versionerne 3.9.6 til og med 3.11.6, der gør det muligt at bryde ud af denne sandkasse. Fejlen opstår, fordi vm2 ikke håndterer Node.js 24’s nye måde at eksponere det indbyggede modul node:test på korrekt. En angriber kan udnytte dette til at køre vilkårlig kode direkte på værtssystemet uden for sandkassen. Fejlen er rettet i vm2 3.11.7.
Hvem rammer det?
Fejlen rammer virksomheder og udviklere, der bruger npm-pakken vm2 i version 3.9.6 til og med 3.11.6 på et system, der kører Node.js 24 eller nyere. Den er kun udnyttelig, hvis applikationen eksplicit tillader det indbyggede modul node:test i sin konfiguration, for eksempel via require: { builtin: ['node:test'] }. Typiske målgrupper er SaaS-platforme, udviklingsmiljøer og interne systemer, der kører bruger- eller kundeleveret JavaScript i en sandkasse.
Hvad kan ske?
En angriber med en brugerkonto i et system, der kører den sårbare vm2-konfiguration, kan bryde ud af sandkassen og køre vilkårlig kode direkte på den server, der hoster applikationen. Det kan i praksis betyde fuld adgang til serveren, herunder adgang til databaser, interne systemer og følsomme data. En angriber kan potentielt hente kundedata, slette filer eller bevæge sig videre ind i jeres netværk.
Hvor alvorligt er det?
CVSS-scoren er 9.9, hvilket er kritisk. Angrebet kræver kun et lavt rettighedsniveau, det vil sige at angriberen blot skal have en almindelig brugerkonto i applikationen. Der kræves ingen handling fra andre brugere. Angrebet kan udføres over netværket uden fysisk adgang. Konsekvenserne for fortrolighed, integritet og tilgængelighed er alle vurderet til høj. Fejlen er endnu ikke bekræftet aktivt udnyttet, men den tekniske beskrivelse er offentlig, og kompleksiteten er lav, hvilket gør den let at misbruge.
Hvad gør jeg nu?
Følg disse trin i prioriteret rækkefølge for at lukke hullet:
- Opdatér vm2 til version 3.11.7 ved at køre
npm install vm2@3.11.7i jeres projekt og geninstaller applikationen i produktion. - Tjek om jeres konfiguration eksplicit tillader
node:testsom tilladt modul. Er det tilfældet, er I direkte sårbare og skal opdatere med det samme. - Søg jeres kodebase og afhængigheder igennem for indirekte brug af vm2, da biblioteket også kan være trukket ind via andre pakker. Brug
npm ls vm2til at kortlægge dette. - Gennemgå logfiler for usædvanlige procesopkald eller mistænkelig aktivitet i perioden fra Node.js 24-opgraderingen og frem til i dag.
- Hvis I ikke kan opdatere med det samme, så deaktivér
node:testsom tilladt modul i vm2-konfigurationen som midlertidig afhjælpning. - Kontakt en ekstern sikkerhedskonsulent, hvis I har mistanke om, at fejlen allerede er udnyttet, eller hvis I ikke kan vurdere omfanget af eksponeringen selv.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer vm2 til version 3.11.7 hurtigst muligt, da den tekniske beskrivelse af angrebet er offentlig og kompleksiteten er lav. Er opdateringen ikke mulig inden for de næste 24 timer, bør I som minimum fjerne node:test fra listen over tilladte moduler som midlertidig løsning. Det er ikke forsvarligt at vente til weekenden, hvis jeres system kører Node.js 24 og har den sårbare konfiguration aktiv. Kontakt os, hvis I har brug for hjælp til at vurdere eksponeringen eller gennemføre opdateringen sikkert.
Tidslinje
Konkrete eksempler
SaaS-platform der kører kundeleveret kode
En dansk softwarevirksomhed tilbyder en platform, hvor kunder kan uploade og køre egne JavaScript-regler til datahåndtering. Platformen bruger vm2 til at isolere denne kode fra resten af systemet. En kunde med ondsindede hensigter udnytter fejlen til at bryde ud af sandkassen og få adgang til serverens filsystem, herunder miljøvariabler med adgangsnøgler til virksomhedens database. Resultatet kan være et databrud med eksponering af alle kunders data og en anmeldelsespligt over for Datatilsynet.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger vm2 i den sårbare version?
Kør
npm ls vm2i roden af jeres projekt. Kommandoen viser, hvilken version der er installeret, og om den er trukket ind direkte eller via en anden pakke. Er versionen mellem 3.9.6 og 3.11.6, er I potentielt sårbare.Vi bruger vm2, men har ikke aktiveret node:test. Er vi stadig i fare?
Nej, denne specifikke fejl kræver, at
node:testeksplicit er tilladt i vm2-konfigurationen. Har I ikke gjort det, er I ikke sårbare over for dette angreb. Vi anbefaler alligevel at opdatere til 3.11.7, da det er god praksis og lukker hullet permanent.Kan vi vente med opdateringen til næste planlagte vedligeholdelsesvindue?
Kun hvis I bekræfter, at
node:testikke er tilladt i jeres konfiguration, og at I ikke kører Node.js 24 eller nyere. Ellers er risikoen for høj til at vente, da den tekniske beskrivelse er offentlig og angrebet er let at udføre.Skal vi anmelde dette til Datatilsynet, hvis vi er blevet ramt?
Hvis angrebet har medført adgang til personoplysninger, er I som udgangspunkt forpligtet til at anmelde bruddet til Datatilsynet inden for 72 timer efter, at I blev opmærksomme på det. Kontakt jeres databeskyttelsesrådgiver for en konkret vurdering af situationen.
Hvad gør vi, hvis vi ikke selv vedligeholder den kode, der bruger vm2?
Kontakt den leverandør eller det bureau, der har bygget og vedligeholder jeres applikation, og anmod om en opdatering til vm2 3.11.7. Bed om skriftlig bekræftelse på, hvornår opdateringen er gennemført i produktionsmiljøet.
Er der andre versioner af vm2 end 3.11.7, der er sikre?
Ifølge NVD-data er versioner under 3.9.6 ikke nævnt som sårbare. Versioner fra 3.9.6 og op til og med 3.11.6 er sårbare. Den eneste bekræftede rettede version er 3.11.7. Bemærk, at vm2-projektet tidligere har haft andre alvorlige sikkerhedsfejl, og vi anbefaler, at I overvejer alternativer på længere sigt.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying –eval= therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.