CVE-2026-92937: Kritisk sandkasseflugt i vm2 3.11.6
Kritisk fejl i vm2 3.11.6 tillader angribere at bryde ud af sandkassen og køre kode på serveren. Opdatér til 3.11.7.
Hvad er det?
vm2 er et udbredt Node.js-bibliotek, der bruges til at køre upålidelig JavaScript-kode i en isoleret sandkasse, altså et afskærmet miljø adskilt fra resten af serveren. CVE-2026-92937 viser, at sandkassens beskyttelsesmekanisme kan omgås via en indirekte kaldsteknik med Function.prototype.call eller .apply. Når en asynkron hostfunktion afviser med en fejl, der indeholder et ikke-primitivt objekt som egenskab, når det rå hostobjekt frem til sandkassekoden. En angriber med adgang til at køre kode i sandkassen kan dermed tilgå Node.js-processen på serveren og udføre vilkårlige kommandoer. Fejlen er en ufuldstændig rettelse af en tidligere kendt sårbarhed.
Hvem rammer det?
Sårbarheden rammer applikationer og tjenester, der anvender vm2 version 3.11.6 til at afvikle upålidelig kode. Det gælder typisk SaaS-platforme, kodeeditorer, testmiljøer, pluginsystemer og andre løsninger bygget i Node.js, hvor brugere eller tredjeparter kan indsende kode til afvikling. Anvender I et internt eller eksternt system bygget på Node.js, bør I undersøge, om vm2 indgår som afhængighed, herunder indirekte via andre pakker.
Hvad kan ske?
En angriber, der kan få sandkassemiljøet til at afvise en asynkron hostfunktion med en bestemt fejlstruktur, opnår fuld adgang til Node.js-processen på serveren. Det betyder, at angriberen kan læse og ændre filer, hente fortrolige data som API-nøgler og adgangskoder, installere bagdøre eller afbryde tjenesten helt. Angrebet kræver ikke administratorrettigheder og efterlader sig ikke nødvendigvis synlige spor i standardlogfiler.
Hvor alvorligt er det?
CVSS-scoren er 10 ud af 10, hvilket er den højest mulige. Angrebet kan udføres over netværket uden forudgående login og uden nogen handling fra en bruger. Omfanget er kritisk, da det kompromitterede system kan bruges som afsæt til angreb på andre systemer i samme netværk. Der er endnu ikke bekræftet aktiv udnyttelse, men teknikken er præcist beskrevet i offentliggjorte detaljer, og et fungerende angreb er realistisk at konstruere for en erfaren angriber.
Hvad gør jeg nu?
Gennemfør disse handlinger i prioriteret rækkefølge for at lukke sårbarheden:
- Opdatér vm2 til version 3.11.7 i alle projekter og miljøer, herunder produktions-, test- og udviklingsmiljøer. Kør
npm install vm2@3.11.7og geninstallér afhængigheder. - Søg efter indirekte afhængigheder: kør
npm ls vm2i jeres projekter for at afdække, om andre pakker trækker vm2 3.11.6 ind. - Genstart de berørte Node.js-processer efter opdateringen, så den nye version er aktiv i hukommelsen.
- Gennemgå logfiler for usædvanlige procesopkald eller filsystemadgange fra Node.js-processen de seneste dage.
- Hvis I ikke kan opdatere med det samme, bør I afskære ekstern adgang til de tjenester, der anvender vm2, indtil opdateringen er gennemført.
- Kontakt en ekstern sikkerhedskonsulent, hvis I finder tegn på kompromittering, eller hvis opdateringen ikke kan gennemføres inden for 24 timer.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer vm2 til 3.11.7 hurtigst muligt, da sårbarheden giver fuldstændig kontrol over serveren uden krav om login. Det er acceptabelt at vente til næste planlagte vedligeholdelsesvindue kun, hvis de berørte tjenester ikke er tilgængelige fra internet eller fra upålidelige brugere. I alle andre tilfælde bør opdateringen gennemføres i dag. Vi hjælper gerne med at kortlægge, om vm2 indgår i jeres systemer, og med at verificere, at opdateringen er korrekt gennemført.
Tidslinje
Konkrete eksempler
Softwarevirksomhed med brugerindsendt kode
En dansk softwarevirksomhed tilbyder en platform, hvor kunder kan indsende JavaScript-kode til afvikling i et sandkassemiljø baseret på vm2. En ondsindet kunde udnytter CVE-2026-92937 ved at konstruere en asynkron funktion, der afviser med en fejl indeholdende en reference til et hostobjekt. Sandkassen leverer fejlobjektet urensket tilbage til brugerens kode, og angriberen udfører systemkommandoer med serverprocessens rettigheder. Angriberen kan herefter læse databaseadgangskoder fra miljøvariable og skaffe sig adgang til virksomhedens interne systemer.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger vm2?
Kør kommandoen
npm ls vm2i roden af hvert Node.js-projekt. Er vm2 ikke direkte installeret, kan den stadig være en indirekte afhængighed. Tjek også jerespackage-lock.jsonelleryarn.lockfor forekomster af vm2.Kan vi vente til weekenden med at opdatere?
Det fraråder vi, hvis jeres tjenester er tilgængelige fra internet eller fra brugere, der kan indsende kode. Angrebet kræver ingen forudgående adgang, og de tekniske detaljer er offentliggjort. Jo længere I venter, jo større er risikoen for udnyttelse.
Er vi ramt, selvom vi ikke selv har skrevet kode med vm2?
Ja, det er muligt. Mange Node.js-pakker anvender vm2 som en intern afhængighed. Et CMS, en testramme eller et automatiseringsværktøj kan trække vm2 ind uden at I er klar over det. Brug
npm ls vm2til at afdække dette.Skal vi anmelde dette til Datatilsynet?
En anmeldelse til Datatilsynet er påkrævet, hvis I har konstateret et brud på persondatasikkerheden, og bruddet sandsynligvis medfører risiko for de registrerede. Har I kun opdateret som forebyggelse og ikke fundet tegn på kompromittering, er der ikke pligt til anmeldelse. Er I i tvivl, bør I konsultere jeres databeskyttelsesrådgiver.
Løser en firewall problemet, hvis vi ikke kan opdatere med det samme?
En firewall kan begrænse angrebsfladen, men løser ikke den grundlæggende fejl. Angrebet udføres af kode, der allerede kører i sandkassen, og ikke direkte fra netværket. Den bedste midlertidige afhjælpning er at afskære ekstern adgang til den berørte tjeneste, indtil opdateringen er på plads.
Er det nok at opdatere i produktionsmiljøet?
Nej. Opdatér i alle miljøer, herunder test og udvikling, da angribere kan udnytte upatchede udviklingsmiljøer som indgangspunkt til jeres netværk. Sørg desuden for, at jeres CI/CD-pipeline og containerimages også anvender den opdaterede version.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
vm2 3.11.6 is vulnerable to a sandbox escape leading to remote code execution in the host Node.js process. The fix for GHSA-m283-3h24-438v is incomplete: the bridge gate at lib/bridge.js:1624 identity-checks only the direct call target when deciding whether to rebuild/sanitise a rejected host Promise value. Registering the rejection handler through Function.prototype.call or .apply indirection (e.g., p.then.call(p, undefined, cb)) makes the intercepted target host Function.prototype.call, so the sanitiser never runs and the raw host error reaches sandbox code with its own properties intact. If an embedder exposes a host-realm Promise to the sandbox (an async host function bridged via the sandbox option, or a NodeVM external module’s async method) and that Promise rejects with an Error carrying a non-primitive own property referencing a host object (for example err.detail = process), untrusted code in the sandbox obtains a fully functional proxy to that host object and can execute arbitrary commands with the privileges of the host process (e.g., e.detail.mainModule.require(‘child_process’).execSync(…)). The direct p.then(undefined, cb), bind, and Reflect.apply forms are correctly sanitised. 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.