CVE-2026-100721: Kritisk sandkasseflugt i vm2

vm2 er et javascript-bibliotek, som udviklere bruger til at køre upålidelig kode i en isoleret sandkasse, altså et afgrænset miljø adskilt fra resten af applikationen. CVE-2026-100721 er en fejl i den del af vm2, der kaldes NodeVM, og som styrer hvilke moduler kode i sandkassen må hente ind udefra. Fejlen ligger i, hvordan vm2 tjekker stien til tilladte moduler: den bruger et regulært udtryk uden krav om en fuld sti-afgrænsning, så et modul med et navn, der blot starter med samme tegn som et godkendt modul, kan glide igennem. Kode i sandkassen kan derfor kræve et modul, der aldrig var godkendt, og det kører med fulde rettigheder i værtsprogrammet, før vm2 når at lægge begrænsninger på det. Resultatet er en sandkasseflugt: kode, der skulle være isoleret, får i stedet fuld adgang til værtsmiljøet.

Det rammer virksomheder, der har udviklet eller driver Node.js-applikationer, som bruger vm2 til version før 3.12.2, og som konkret har konfigureret `require.external` med en tilpasset resolver og `context: ‘host’`. Det gælder typisk platforme, hvor brugere eller tredjeparter kan uploade og køre kode, eksempelvis plugin-systemer, online kodeeditorer, CI/CD-værktøjer eller SaaS-løsninger med scriptbare udvidelser. Almindelige webshops eller interne administrationssystemer uden brugerstyret kodekørsel er ikke berørt, medmindre de bygger på vm2 til dette formål.

En angriber, der kan få sin kode kørt inde i sandkassen, kan bryde ud og opnå kodekørsel med samme rettigheder som selve serverprocessen. I praksis betyder det adgang til filsystem, miljøvariabler, database-forbindelser og andre systemer, serveren kan tilgå. For en dansk virksomhed, der driver en platform med brugerindsendt kode, kan det føre til datatyveri, installation af skadelig software eller at angriberen bruger serveren som springbræt videre ind i det interne netværk.

CVSS-score er 9,0 ud af 10, kritisk. Sårbarheden kræver ikke login eller nogen handling fra en bruger uden for sandkassen, men den forudsætter, at angriberen allerede kan få kode udført inde i sandkassen, og at driften har konfigureret den specifikke resolver-funktion. Angrebskompleksiteten er sat til høj, fordi det kræver kendskab til modulstier og sandkassens opsætning. Der er ikke belæg for, at sårbarheden bliver udnyttet i praksis på offentliggørelsestidspunktet, men den tekniske beskrivelse er detaljeret nok til, at et angreb kan udvikles relativt hurtigt.

Følgende trin lukker hullet og begrænser skaden, hvis I bruger vm2 i jeres applikationer:

1. Opdatér vm2 til version 3.12.2 eller nyere i alle projekter og afhængigheder, hvor biblioteket indgår.
2. Gennemgå jeres kodebase for brug af vm2 og NodeVM, herunder indirekte via tredjepartsbiblioteker, så I kender det fulde omfang.
3. Tjek om I bruger `require.external` med en tilpasset resolver og `context: ‘host’`, og stram i så fald listen over tilladte moduler, indtil opdateringen er på plads.
4. Gennemgå logs for uventet modulindlæsning eller uforklarlig kodekørsel i den periode, sårbarheden har eksisteret.
5. Overvej på sigt at erstatte vm2 med en aktivt vedligeholdt isolationsløsning, da vm2-projektet historisk har haft flere lignende sandkasseflugter.
6. Hent hjælp udefra, hvis I ikke selv kan verificere, om jeres platform bruger den sårbare konfiguration, eller hvis I finder tegn på misbrug.