CVE-2026-92953: Kritisk sårbarhed i vm2 3.11.0–3.11.7
Kritisk fejl i vm2 3.11.0–3.11.7 giver angribere mulighed for at manipulere værtens hukommelse. Opdatér til 3.11.8 nu.
Hvad er det?
CVE-2026-92953 er en kritisk sårbarhed i JavaScript-sandkassebiblioteket vm2, som bruges til at køre upålidelig kode isoleret fra resten af serveren. I versionerne 3.11.0 til og med 3.11.7 er det muligt at gå uden om denne isolation ved at manipulere såkaldte prototyper, det vil sige de grundlæggende skabeloner som JavaScript-arrays og buffere er bygget på. Når en angriber ændrer disse skabeloner inde i sandkassen, smitter ændringerne tilbage til selve værtssystemet, efter at koden er kørt færdig. Fejlklassen hedder CWE-913 og handler om ukontrolleret styring af dynamisk kode.
Hvem rammer det?
Sårbarheden rammer alle systemer og tjenester, der bruger npm-pakken vm2 i versioner fra 3.11.0 til og med 3.11.7. Det er typisk Node.js-baserede applikationer, der tillader brugere eller tredjepartskode at køre JavaScript i en isoleret kontekst, for eksempel SaaS-platforme, CI/CD-pipelines, scripting-funktioner i forretningssystemer og cloudbaserede udviklermiljøer. Virksomheder, der bruger vm2 indirekte via et tredjeparts npm-modul, er lige så sårbare.
Hvad kan ske?
En angriber, der kan sende kode til jeres vm2-sandkasse, kan manipulere de datastrukturer som hele Node.js-processen bagefter bruger. Det betyder, at data der behandles efter angrebet, kan læse eller skrive forkerte værdier, uden at applikationen opdager det. I praksis kan det føre til fejlagtige beregninger, korrupte dataposter i databasen eller mulighed for at eskalere angrebet videre i systemet. Tilgængelighed og dataintegritet er begge i fare, og konsekvenserne rækker potentielt ud over den enkelt vm2-kørsel.
Hvor alvorligt er det?
CVSS-scoren er 10,0, det højeste mulige. Angrebet kræver ingen forudgående login, ingen særlige rettigheder og ingen handling fra en bruger. Det udføres over netværket med lav kompleksitet. Omfanget er vurderet til at ramme ud over sandkassen selv, hvilket afspejler, at effekten spreder sig til værtsmiljøet. Der er endnu ikke bekræftet aktiv udnyttelse i naturen, men den netværksbaserede angrebsflade og fraværet af alle adgangsbarrierer gør sårbarheden ekstremt attraktiv for angribere.
Hvad gør jeg nu?
Gennemfør følgende trin i prioriteret rækkefølge:
- Opdatér vm2 til version 3.11.8 ved at køre
npm install vm2@3.11.8i jeres projekter og geninstallér afhængigheder i produktionsmiljøet. - Søg i jeres kodebase og package-lock.json eller yarn.lock efter direkte og indirekte afhængigheder af vm2, så ingen instanser overses.
- Genstart alle Node.js-processer, der bruger vm2, så den opdaterede kode træder i kraft.
- Begræns midlertidigt adgangen til de endepunkter, der modtager brugerstyret kode til vm2-kørsel, hvis I ikke kan opdatere med det samme.
- Gennemgå logfiler fra de seneste 30 dage for usædvanlig adfærd i sandkassekørsler, særligt kode der forsøger at manipulere prototyper.
- Kontakt os eller en anden ekstern rådgiver, hvis I er usikre på, om I er ramt, eller hvis jeres applikation ikke kan opdateres uden større ændringer.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer vm2 til 3.11.8 som den første handling i dag, inden I gør andet. Sårbarheden har ingen adgangsbarrierer, og konsekvenserne rækker ud over selve sandkassen, så tidsvinduet for at handle, før nogen udnytter den, er kort. Har I ikke ressourcerne til at gennemgå alle afhængigheder selv, hjælper vi med en hurtig scanning af jeres Node.js-projekter. Det er acceptabelt at vente til næste arbejdsdag kun, hvis I allerede har isoleret de berørte endepunkter fra offentlig adgang.
Tidslinje
Konkrete eksempler
Scripting-funktion i forretningssystem
En dansk softwarevirksomhed tilbyder sine kunder mulighed for at skrive egne JavaScript-regler, der kører i en vm2-sandkasse på serveren. En angriber med adgang til denne funktion sender kode, der ændrer prototype-skabelonerne for arrays. Efterfølgende beregninger i systemet, herunder fakturabeløb og lageroptælling, returnerer forkerte værdier, og fejlen opdages først efter flere timers drift og dataskade.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger vm2?
Kør kommandoen
npm list vm2i roden af hvert Node.js-projekt. Den viser, om vm2 er installeret direkte eller som en afhængighed af et andet modul. I kan også søge i jeres package-lock.json eller yarn.lock-filer efter strengen “vm2”.Kan vi nøjes med at blokere for adgang udefra som en midlertidig løsning?
Ja, det reducerer risikoen midlertidigt. Hvis I afskærer de endepunkter, der modtager ekstern kode til vm2-kørsel, fra internettet, fjerner I angrebsfladen for ukendte angribere. Det er dog ikke en permanent løsning, da interne brugere eller kompromitterede konti stadig kan udgøre en risiko. Opdateringen skal følge hurtigst muligt.
Vi bruger ikke vm2 direkte. Kan vi alligevel være ramt?
Ja. Mange npm-pakker bruger vm2 som en intern afhængighed. Tjek jeres package-lock.json for alle forekomster af vm2, uanset om I har installeret den direkte. Har et tredjeparts modul hentet vm2 3.11.0–3.11.7, er I sårbare på samme måde.
Skal vi anmelde dette til Datatilsynet?
En anmeldelse til Datatilsynet kræver, at der er sket et brud på persondatasikkerheden. Selve sårbarheden udløser ikke en pligt til anmeldelse, men hvis I konstaterer, at en angriber faktisk har udnyttet hullet og dermed kan have tilgået eller manipuleret personoplysninger, skal I vurdere anmeldelse inden for 72 timer. Dokumentér jeres undersøgelse uanset udfald.
Kan vi vente til weekendens vedligeholdelsesvindue?
Det fraråder vi i dette tilfælde. CVSS-scoren er 10,0, og angrebet kræver ingen forudsætninger. Venter I til weekenden uden at lukke adgangen til de berørte endepunkter, er risikoen reel. Foretag enten opdateringen nu eller isolér endepunkterne, indtil opdateringen kan gennemføres.
Hvad sker der konkret i vores applikation, hvis nogen udnytter sårbarheden?
Angriberen ændrer de grundlæggende skabeloner for arrays og buffere i Node.js-processen. Det betyder, at al efterfølgende behandling af disse datatyper i jeres applikation kan opføre sig uforudsigeligt. Det kan resultere i forkerte beregninger, korrupte data gemt i databasen eller i visse tilfælde mulighed for yderligere angreb mod jeres system.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
vm2 versions from 3.11.0 before 3.11.8 fail to protect host TypedArray and ArrayBuffer prototypes from sandbox mutation. Attackers can use prototype-walking primitives to reach and modify host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, causing host-created typed arrays to observe attacker-controlled properties after VM.run() returns.
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.