#Netzwerk & Sicherheit · 3 Min. Lesezeit · Tim Rinkel

NODE-SCHOCK! vm2-Sandbox EXPLODIERT — Code in JEDER Node-App wird zur GAU-Falle, CVSS perfekte 10

NODE-SCHOCK! vm2-Sandbox EXPLODIERT — Code in JEDER Node-App wird zur GAU-Falle, CVSS perfekte 10

NODE.JS-KATASTROPHE quer durch jede CI-Pipeline! Sicherheitsforscher haben am Mittwoch CVE-2026-43997 veröffentlicht — eine kritische Sandbox-Escape-Lücke in der vm2-Bibliothek. Score: perfekte 10.0 auf CVSS. Damit kannst du im Lehrbuch nachschlagen, was schlimmstmöglich aussieht — und vm2 ist es.

HAMMER: Was vm2 macht — und warum’s gefährlich ist

vm2 wurde gebaut, um untrustworthy JavaScript in einer eigenen Umgebung laufen zu lassen — als Plugin-Engine, als Eval-Replacement, als Skript-Engine in CMS-Backends. Dachte man. Tatsächlich ist die Bibliothek schon mehrfach mit Escapes aufgefallen, der ursprüngliche Maintainer hat sie 2023 für tot erklärt. CVE-2026-43997 ist der vorerst letzte Akt: Code in der „Sandbox” kann auf Host-Objekte zugreifen — Filesystem, Netzwerk, alles.

UNGLAUBLICH: Wo vm2 noch sitzt

Trotz Maintainer-Stopp läuft vm2 weiter in tausenden NPM-Paketen. Tools wie Bildungsplattformen, Code-Playgrounds, Workflow-Engines, einige Tikz-Renderer und Marketing-Automation-Suites haben es als Dependency eingezogen. Wer Node-Apps betreibt, sollte JETZT einen npm ls vm2 in seinem Projekt-Tree absetzen — die Antwort wird unbequem.

GEFAHR: Vertrauliche Daten weg

Was kann ein erfolgreicher Exploit anrichten? Der Angreifer schickt ein präpariertes Skript in die Sandbox — ein User-Template, ein Plugin, eine Workflow-Definition — und holt sich von dort Filesystem-Zugriff. Heißt: .env-Dateien, Datenbank-Credentials, S3-Keys. In Cloud-Apps: Direkt zum nächsten Service-Account. Klassischer Lieferketten-Angriff, der ganze SaaS-Bestände in den Schmutz reißen kann.

EXTRA: Migration in 5 Schritten

So tauschst du vm2 raus:

  1. Inventur: npm ls vm2 in allen Repos.
  2. Bewertung: Direkte Nutzung vs. transitive Dependency identifizieren.
  3. Alternativen wählen: isolated-vm für echten Isolations-Bedarf, node:vm + Worker-Threads für einfache Eval-Szenarien.
  4. API-Anpassung: isolated-vm ist strenger, Context-Bridging muss explizit gemacht werden.
  5. Logs & Monitoring: Eingehende Skripte protokollieren, Anomalien per ML auf Anomalie prüfen.

FAZIT: Schluss mit vm2

vm2 ist tot — offiziell, mehrfach. CVE-2026-43997 ist die Beerdigung mit Donnerwetter. Wer noch produktiv darauf setzt, hat keine Sandbox, sondern einen Eintrag in den nächsten Pentest-Bericht. Migration ist Wochen-Arbeit, aber sie ist Pflicht. Cloud-Anbieter, die User-Code akzeptieren, dürfen vm2 ab heute nicht mehr nutzen — sonst geht das Haftungsbudget hoch.

Häufige Fragen

Was bedeutet CVE-2026-43997?
Es ist eine kritische Sandbox-Escape-Lücke in der Node.js-Bibliothek vm2. Code, der eigentlich isoliert laufen soll, kann auf Host-Objekte zugreifen und damit das Host-System kompromittieren. CVSS-Score 10.0 ist der höchstmögliche Wert.
Welche Versionen sind betroffen?
Alle vm2-Versionen, da das Projekt seit 2023 nicht mehr gepflegt wird und keine Fixes mehr veröffentlicht werden. Es gibt keinen sicheren Stand — Migration ist die einzige Abhilfe.
Wie behebe ich das Problem konkret?
Auf isolated-vm wechseln, wenn du echte Isolation brauchst, oder auf node:vm mit Worker-Threads, wenn nur basic Sandboxing reicht. Manche Use-Cases lassen sich auch durch Eval in Subprocess oder WASM lösen.
Gab es schon aktive Angriffe?
Der Public Disclosure war am 13. Mai 2026, PoC-Code zirkuliert in einschlägigen Security-Foren. Konkrete Massen-Exploits sind noch nicht dokumentiert, aber die Lücke ist trivial auszunutzen.

Quellen:

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert