CVE-2026-93603: Kritisk sandkasse-flugt i vm2
Kritisk fejl i vm2 (CVE-2026-93603) gør det muligt at bryde ud af sandkassen og køre kode på serveren. Opdatér til 3.12.1.
Hvad er det?
vm2 er et udbredt JavaScript-bibliotek til Node.js, som udviklere bruger til at køre upålidelig kode i en sandkasse, altså et lukket miljø, der skal forhindre koden i at røre resten af serveren. CVE-2026-93603 er en fejl i vm2’s bro-funktion (bridge.js), som håndterer kald mellem sandkassen og værtsprogrammet. Når kode i sandkassen kalder en værtsfunktion uden at angive en modtager for ‘this’, indsætter JavaScript-motoren V8 automatisk hele det globale objekt fra værten som ‘this’. vm2 videregiver ved en fejl dette objekt til sandkassen, som dermed får levende adgang til hele værtens miljø, herunder ‘process’-objektet, som kan bruges til at afvikle systemkommandoer. Det svarer til, at en gæst i et aflåst lokale pludselig får nøglen til hele bygningen.
Hvem rammer det?
Sårbarheden rammer virksomheder, der har udviklet eller driver applikationer i Node.js, som bruger vm2 til at afvikle brugerindsendt eller på anden måde upålidelig kode. Det gælder for eksempel online kodeeditorer, plugin- og udvidelsessystemer, low-code platforme, CI/CD-værktøjer og chatbots eller automatiseringstjenester, der lader brugere indtaste formler eller scripts. Alle versioner af vm2 til og med 3.12.0 er berørte. Fejlen kræver, at den omkringliggende applikation stiller mindst én værtsfunktion til rådighed for sandkassen, som ikke er skrevet i strict mode. Da strict mode ikke er standard i almindelig JavaScript, gælder det de fleste typiske installationer.
Hvad kan ske?
En angriber, der kan få sin kode afviklet i sandkassen, for eksempel via et plugin, en formel eller et script, kan bryde helt ud og køre vilkårlige kommandoer direkte på serveren. I praksis betyder det, at angriberen kan læse databaseoplysninger og adgangskoder fra miljøvariabler, installere skadelig software, slette eller kryptere data og bruge serveren som springbræt videre ind i jeres netværk. Da sandkassen normalt bruges til at isolere upålidelig kode, kan konsekvensen være langt større, end hvis den samme fejl fandtes i en almindelig funktion, fordi hele sikkerhedsformålet med vm2 forsvinder.
Hvor alvorligt er det?
CVSS-scoren er 10,0 ud af 10, den højeste mulige. Angrebet kræver ingen adgangskoder, ingen brugerinteraktion og kan udføres over netværket med lav kompleksitet. Fortrolighed, integritet og tilgængelighed rammes alle fuldt ud, og angrebet kan påvirke systemer ud over selve vm2-komponenten, fordi hele værtsmiljøet bliver blotlagt. Der er offentliggjort en detaljeret teknisk beskrivelse af, hvordan fejlen udnyttes, hvilket gør det forholdsvis let for en angriber at bygge et fungerende angreb. Der er ikke oplysninger om, at fejlen er udnyttet i angreb, men den tekniske beskrivelse fungerer i praksis som en køreklar opskrift.
Hvad gør jeg nu?
Følg disse trin, i denne rækkefølge:
- Opdatér vm2 til version 3.12.1 i alle applikationer og tjenester, hvor biblioteket indgår, enten direkte eller som en afhængighed.
- Kortlæg hvor vm2 bruges. Kør en søgning i jeres package.json- og package-lock.json-filer eller brug ‘npm ls vm2’ på tværs af jeres Node.js-projekter.
- Kan I ikke opdatere med det samme, så begræns hvilke værtsfunktioner sandkassen har adgang til, og isolér tjenesten yderligere med containerisering eller netværkssegmentering.
- Gennemgå logs for usædvanlig aktivitet fra tjenester, der kører vm2, hvis opdateringen har ventet.
- Overvej på sigt at migrere væk fra vm2, da projektet ikke længere vedligeholdes aktivt, og skift til et alternativ som isolated-vm.
- Få hjælp udefra, hvis I ikke selv har overblik over, hvilke systemer der bruger vm2, eller om jeres applikation er sårbar.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer vm2 til 3.12.1 med det samme, uanset om biblioteket bruges direkte eller ligger skjult i en anden komponent. Det er kun i orden at vente, hvis I kan dokumentere, at ingen af jeres systemer bruger vm2, eller at sandkassen aldrig eksponerer værtsfunktioner uden strict mode. Da CVSS-scoren er den højeste mulige og teknikken er offentliggjort i detaljer, bør opdateringen prioriteres over andre driftsopgaver.
Tidslinje
Konkrete eksempler
Formel-felt i en dansk webshop-platform
En dansk e-handelsvirksomhed driver en tilpasset webshop-platform, hvor kunder kan indtaste egne prisformler i et administrationsmodul, der afvikles i en vm2-sandkasse på serveren. En angriber opretter en formel, der udnytter CVE-2026-93603 til at bryde ud af sandkassen og får derved adgang til at læse databasens loginoplysninger fra en miljøvariabel på serveren. Herfra tilgår angriberen kundedata og betalingsoplysninger, som opbevares i samme system.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis jeres virksomhed driver eller har fået udviklet en Node.js-applikation, der bruger vm2 til at afvikle brugerindsendt eller upålidelig kode, for eksempel plugins, formler eller scripts. Brug I ikke Node.js eller vm2 slet ikke, er I ikke berørte.
Hvordan tjekker vi, om vi bruger vm2?
Søg efter ‘vm2’ i jeres projekters package.json og package-lock.json, eller kør kommandoen ‘npm ls vm2’ i hvert Node.js-projekt. Har I fået udviklet en løsning af en ekstern leverandør, bør I spørge leverandøren direkte.
Kan vi vente med at opdatere til efter weekenden?
Det frarådes. Fejlen har den højeste CVSS-score og kan udnyttes uden login eller brugerinteraktion. Opdateringen tager typisk kort tid at gennemføre og bør prioriteres samme dag, den opdages.
Skal vi anmelde hændelsen, hvis vi finder tegn på misbrug?
Finder I tegn på, at nogen har udnyttet sårbarheden til at bryde ud af sandkassen, bør I vurdere, om det udløser pligt til anmeldelse efter reglerne om databeskyttelse eller NIS2, afhængigt af hvilke data der er blevet tilgået, og kontakte Datatilsynet eller relevante myndigheder hurtigst muligt.
Er alle brugere af vm2 sårbare, eller kun nogle konfigurationer?
Sårbarheden kræver, at applikationen stiller mindst én værtsfunktion til rådighed for sandkassen, som ikke er skrevet i strict mode. Da de fleste JavaScript-funktioner ikke bruger strict mode som standard, er langt de fleste typiske vm2-installationer sårbare, men det bør bekræftes for jeres konkrete løsning.
Hvad gør vi, hvis vm2 indgår i en tredjepartsløsning, vi ikke selv har udviklet?
Kontakt leverandøren og spørg, om de har opdateret til vm2 3.12.1 eller senere. Har leverandøren ikke svaret eller opdateret, bør I overveje midlertidigt at begrænse eller lukke den funktion, der bruger sandkassen, indtil der foreligger en rettelse.
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 through 3.12.0 (fixed in 3.12.1) does not correctly handle a nullish `this` receiver in the apply trap of its bridge (lib/bridge.js): when sandboxed code calls a host-provided non-strict (sloppy-mode) function without a receiver — e.g. `fn()`, a detached method, `fn.call()`, `fn.apply(undefined)`, `Reflect.apply(fn, undefined, [])`, or `fn.bind()()` — the undefined receiver is passed straight through to the host call, and V8 substitutes the host realm’s global object for `this`. vm2 then wraps and returns that object to the sandbox, giving sandboxed script a live proxy of the host global. This allows a complete sandbox escape: untrusted script can reach `process` and execute arbitrary code/commands on the host (for example via `process.getBuiltinModule(‘child_process’).execSync`). Exploitation requires that the embedding application expose at least one non-strict host function to the sandbox; strict-mode and ES module host functions are not affected.
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.