vm2 wieder geöffnet: Zwölf Sandbox-Escapes auf einen Schlag — was das für Ihre KI-Agent-Stacks bedeutet

Am 7. Mai 2026 sind in einer einzigen Sammelmeldung rund ein Dutzend neue, kritische Sandbox-Escapes in der Node-Bibliothek vm2 veröffentlicht worden. Mehrere Einträge tragen einen CVSS-Score von 9.8 oder 10.0 — also „kritisch ohne wenn und aber“. Die Bibliothek galt schon im Sommer 2023 einmal als tot, wurde im Oktober 2025 von ihrem ursprünglichen Entwickler reanimiert und in TypeScript neu aufgesetzt. Der Befund von dieser Woche zeigt: Die strukturellen Probleme sind nicht weg. Sie sind anders verpackt.

Kurzfassung für Entscheider

vm2 ist eine JavaScript-Sandbox, die fremden Code in einem isolierten Kontext mit Whitelisting der Node-Built-ins ausführen soll. Genau diese Aufgabe ist im KI-Agent-Zeitalter plötzlich extrem populär: Wer einen Agenten Code generieren und sofort ausführen lässt — etwa im Flowise-Workflow, in LangChain.js-Tools oder in selbstgebauten MCP-Servern — braucht eine Schutzhülle zwischen Modell und Host. vm2 war über Jahre die einfache Antwort: ein npm-Paket, einen Wrapper drum, fertig. Die Schicht hat aber eine Eigenschaft, die in keinem Marketing-Diagramm vorkommt: Sie liegt im selben V8-Prozess wie die aufrufende Anwendung. Bricht ein Stück präparierter Code aus dem Sandkasten aus, läuft es im Kontext der Host-Anwendung — mit deren Tokens, deren Filesystem-Rechten, deren Netzwerk-Zugängen.

Die aktuelle Lage

Der Block dieser Woche ist breit. Ein Auszug der schwerwiegendsten Einträge: CVE-2026-43997 — Code Injection mit Zugriff auf das Host-Object, CVSS 10.0, vollständiger Sandbox-Escape, beliebige Code-Ausführung auf dem Host. CVE-2026-44009 — Sandbox-Escape via Null-Proto-Exception, CVSS 9.8. CVE-2026-24118 — Escape via __lookupGetter__, CVSS 9.8. CVE-2026-24781 — Escape via inspect-Funktion, CVSS 9.8. CVE-2026-26332 — Escape via SuppressedError, CVSS 9.8. CVE-2026-26956 — Symbol-zu-String-Coercion mit TypeError-Bypass, CVSS 9.8.

Die offizielle Empfehlung: Update auf vm2 ≥ 3.11.0. Wer das nicht zeitnah einspielen kann, sollte sich überlegen, ob vm2 für seinen Anwendungsfall überhaupt das richtige Werkzeug ist.

Warum die übliche Annahme hier nicht trägt

vm2 befindet sich in einem unauflösbaren Dilemma: Die V8-Engine selbst ist nicht für mehrmandantenfähige Code-Ausführung im selben Prozess gebaut. Jede neue ECMAScript-Funktion, jede neue Spezial-Methode, jede neue Coercion-Pfad-Variante kann zum Bypass werden. Das Spiel ist endlos. Der Maintainer selbst hat das öffentlich eingeräumt.

Erstens — Wer vm2 als Schutzschicht zwischen LLM-Output und Host-System betreibt, hat keine Sandbox, sondern eine Verzögerungsstrategie. Die nächste Lücke kommt; die einzige Frage ist, ob der Patch-Pfad in der eigenen Pipeline schneller ist als der Exploit.

Zweitens — In Agent-Frameworks ist vm2 oft als „silent fallback“ konfiguriert. Genau das, was im normalen Betrieb unauffällig ist, wird im Sicherheitsfall zum Einfallstor. Wer Flowise oder vergleichbare Stacks einsetzt, sollte heute genau prüfen, an welcher Stelle vm2 im Codepfad sitzt — und ob das überhaupt bekannt war.

Drittens — In Build-Pipelines, in denen vm2 transitive Abhängigkeit ist (über Drittpakete für Template-Engines, Plugin-Systeme, dynamische Konfigurationen), genügt die offene CVE-Liste, um von Audit-Werkzeugen jeder Couleur Alarm zu bekommen. Auch wenn der eigene Code nichts mit vm2 zu tun hat, blockiert es den nächsten Compliance-Bericht.

Was wir konkret empfehlen

Die ehrliche Antwort lautet: weg von In-Process-Sandboxes für Agent-Code. Drei strukturelle Wege, geordnet nach Aufwand und Schutzwirkung.

Option A — Containerisierung mit hartem Capability-Drop. Agent-Code läuft in einem Docker- oder Podman-Container mit --cap-drop=ALL, ohne Netz, ohne Bind-Mounts auf produktive Pfade. Das ist gegen V8-Bypasses immun, weil es V8 nicht mehr als Trust-Boundary nutzt. Mehrkosten: ein paar hundert Millisekunden pro Aufruf, die in den meisten Agent-Szenarien irrelevant sind.

Option B — Firecracker- oder Kata-Microvms. Für Stacks, in denen mehrere Mandanten dasselbe Frontend teilen, lohnt sich der Schritt in Richtung Hardware-Virtualisierung. Die Produkt-Linie Wolfi-OS-Container plus Firecracker hat sich in unseren eigenen Setups bewährt — minimaler Angriffspfad, klares Lifecycle-Management.

Option C — isolated-vm als Brücke. Wer kurzfristig nicht aus dem Node-Prozess heraus kann, sollte zumindest auf isolated-vm migrieren. Die Bibliothek nutzt V8s native Isolate-API direkt und reduziert die Angriffsfläche erheblich — vollständig sicher ist auch sie nicht, aber sie schließt die Klasse der Coercion-Angriffe weitgehend aus.

Option D — Socket.dev's kostenlose Certified Patches als zeitlich begrenzte Brücke. Wer aus Kompatibilitätsgründen mit transitiven Abhängigkeiten gerade nicht auf vm2 ≥ 3.11.0 upgraden kann, findet bei Socket.dev kostenlose, kuratierte Patches für die aktuellen vm2-Sandbox-Escapes. Das ist explizit als Übergang gedacht, nicht als Ersatz für die strukturelle Migration. Praktisch interessant für Stacks, in denen vm2 als transitive Abhängigkeit von Drittpaketen mitläuft und ein Direkt-Upgrade nicht ohne Breaking-Change möglich ist. Als dauerhafte Lösung bleibt der Pfad zu Option A oder B — die Socket-Patches sind eine kontrollierte Notbremse, kein Ersatz für die Architektur-Frage.

In keinem Fall ist „weiter vm2 nutzen, schneller patchen“ eine seriöse Antwort. Wir sind dieser Logik in mehreren Audits begegnet und haben sie in keinem Fall gehalten gesehen.

Was wir bewusst nicht empfehlen

Wir empfehlen keine pauschale Pflicht, jede Agent-Funktion in eine eigene VM zu sperren. Es gibt produktive Anwendungsfälle — Daten-Klassifikation, Embedding-Generierung, simple JSON-Transformationen — bei denen nie fremder Code zur Ausführung kommt. Dort ist die Sandbox-Frage gegenstandslos. Es lohnt nicht, Komplexität dort einzuziehen, wo das Bedrohungsmodell sie nicht trägt.

Was wir aber konsequent durchziehen: An jeder Stelle, an der ein LLM-Output zu generiertem, ausgeführtem Code wird — sei es Python, JavaScript, Shell, SQL — gehört eine Prozess-Grenze dazwischen. Eine, die nicht vom selben Engine-Hersteller kommt wie der Sandbox-Versuch. Konzeptionell ist das vergleichbar mit dem Punkt, den wir zur Container-Ebene bei CVE-2026-31431 „Copy Fail“ gemacht haben: Verantwortung an der richtigen Schicht verorten.

Wer am stärksten betroffen ist

Drei Profile aus unserer Beratungspraxis sind heute akut. Mittelständische Betriebe, die in den letzten zwölf Monaten einen Flowise-Stack für interne Automatisierung aufgesetzt haben — oft als „kleines KI-Pilotprojekt“ gestartet, inzwischen mit Zugriff auf interne Dokumente, Mailpostfächer, ERP-Daten. Die Lückenkette zwischen Modell und Host ist hier oft genau eine vm2-Schicht.

SaaS-Anbieter, die ihren Kunden „Custom-Logic“-Felder anbieten, in die Endkunden JavaScript-Snippets eintragen — Beispielfeld: Berechnung von Provisions-Regeln, dynamische Auswertungen. vm2 ist hier ein klassischer Default. Hier sitzt die Sandbox direkt zwischen Mandant und Host-Datenbank.

Entwickler-Teams, die in eigenen MCP-Servern Tools schreiben, in denen Modell-Output ausgeführt wird, ohne dass das im Architektur-Diagramm explizit auftaucht. Wir haben in den letzten Wochen mehrere Reviews gesehen, in denen vm2 als reiner Implementierungs-Detail-Eintrag im package.json versteckt war. Dasselbe Strukturthema, das wir bei den Bitwarden-CLI-Lieferkettenrisiken beschrieben haben — nur eine Ebene tiefer im Stack.

Fazit

vm2 ist keine Sandbox. Es ist eine wiederholt geflickte Behauptung, eine zu sein. Die heutige CVE-Sammelmeldung ist nicht die letzte ihrer Art und nicht der schwerste Treffer. Die Frage lautet nicht, wann der nächste Bypass kommt. Sie lautet, ob Sie die nächste Bypass-Welle auf einer Architektur erleben, die ohne vm2 auskommt — oder auf einer, die wieder einen Patch-Sprint einplant. Persönlicher Hintergrund und technische Details zur In-Process-Sandbox-Diskussion: ole-hartwig.eu.