Kritische Sicherheitslücken in vm2-Bibliothek gefährden Node.js-Anwendungen

Kritische Sicherheitslücken in der JavaScript-Sandbox vm2 ermöglichen Systemkompromittierung

Die Sicherheit von Software-Anwendungen, insbesondere jener, die Code von Drittanbietern oder unsichere Skripte ausführen, ist von zentraler Bedeutung. Im Kontext von Node.js-Anwendungen kommt hierbei häufig die JavaScript-Sandbox-Bibliothek vm2 zum Einsatz, um eine isolierte Ausführungsumgebung zu gewährleisten. Aktuelle Berichte und Sicherheitswarnungen enthüllen jedoch kritische Schwachstellen in dieser Bibliothek, die unter bestimmten Voraussetzungen einen Ausbruch aus der Sandbox und die Ausführung von Schadcode auf dem Hostsystem ermöglichen.

Details zu den Schwachstellen

Zwei spezifische Schwachstellen stehen im Fokus der aktuellen Diskussionen: CVE-2026-22709 und CVE-2026-26956. Beide werden mit einem hohen bis kritischen Bedrohungsgrad eingestuft und verdeutlichen die potenziellen Risiken für Systeme, die vm2 einsetzen.

CVE-2026-22709: Die „Async Proxy Trap“-Technik

Diese Schwachstelle betrifft vm2-Versionen bis einschließlich 3.10.1 und ermöglicht Remote Code Execution (RCE) durch eine sogenannte „Async Proxy Trap“-Technik. Die Hauptursache liegt in der Art und Weise, wie vm2 die Callback-Funktionen von `Promise.prototype.then` und `Promise.prototype.catch` handhabt. Es wurde festgestellt, dass die Filterung der Eingaben für diese Funktionen umgangen werden kann. Insbesondere die `globalPromise.prototype.then`-Methode in `lib/setup-sandbox.js` führte nicht die notwendige Bereinigung durch, im Gegensatz zu `localPromise.prototype.then`.

Die Kernproblematik von CVE-2026-22709 liegt in der Manipulation von `Function.prototype.call`. Angreifer können innerhalb der Sandbox `Function.prototype.call` überschreiben. Wenn der Host versucht, eine Promise zu bereinigen, wird versehentlich der bösartige Code des Angreifers mit Host-Privilegien ausgeführt, was zu einem vollständigen Sandbox-Ausbruch führt. Dies wird durch aggressive asynchrone Stack-Trace-Optimierungen in den V8-Engines von Node.js 24 und 25 begünstigt, die interne Objektzustände während der Ausnahmebehandlung exponieren, welche vm2 nicht korrekt bereinigen kann.

Die Behebung dieser Lücke erfolgte mit Version 3.10.2 von vm2. Der Patch ersetzt die dynamische Methodensuche durch `Reflect.apply`, welches die Objekteigenschaften und Prototypketten ignoriert und somit die Ausführung der eigentlichen Funktion erzwingt, ohne die Manipulationen des Angreifers zu berücksichtigen.

CVE-2026-26956: WebAssembly Sandbox Escape

Eine weitere kritische Schwachstelle, CVE-2026-26956, wurde spezifisch für Node.js 25 identifiziert. Diese Lücke ist in vm2 Version 3.10.4 vorhanden und wurde in Version 3.10.5 geschlossen. Sie wird als kritisch eingestuft und ermöglicht ebenfalls einen vollständigen Sandbox-Ausbruch mit beliebiger Codeausführung. Die Bedrohung besteht ausschließlich, wenn WebAssembly Exception Handling und JSTag Support in Node.js 25 aktiv sind (getestet auf v25.6.1).

Die vm2-Sicherheit basiert auf zwei JavaScript-basierten Mechanismen: einem Code-Transformer, der `handleException()` in JS-`catch`-Klauseln injiziert, und Bridge-Proxies, die Cross-Context-Objekte umschließen. Beide operieren vollständig innerhalb von JavaScript. WebAssemblys `try_table`-Anweisung mit einem `JSTag`-Catch-Handler fängt JavaScript-Exceptions auf V8s C++-Ebene ab – also unterhalb der JavaScript-Ebene. Wenn eine importierte JS-Funktion einen `TypeError` auslöst, der durch eine Symbol-zu-String-Koersion während der Stack-Formatierung entsteht (z.B. `e.name = Symbol(); e.stack`), fängt die WASM-`try_table` dies als ein undurchsichtiges `externref` ab und gibt es als normalen Funktionsrückgabewert zurück. Dieser Pfad der WASM-Exception-Behandlung zum Rückgabewert wird von vm2 nicht bereinigt. Der `TypeError` des Host-Bereichs erreicht den Angreifer-Code unbereinigt. Seine Konstruktorkette (`hostError.constructor.constructor`) löst sich zu einer Funktion auf, die das Host-Prozessobjekt zurückgibt, was eine Reflexion außerhalb des vm2-Kontextes und somit die Codeausführung ermöglicht.

Ein Proof-of-Concept-Exploit für diese Schwachstelle ist öffentlich verfügbar, was das Risiko einer Ausnutzung erhöht.

Betroffene Systeme und erforderliche Maßnahmen

Die Schwachstellen betreffen Node.js-Anwendungen, die vm2 zur Ausführung von als unsicher eingestuftem Code verwenden. Dies umfasst beispielsweise Plattformen für "Functions as a Service", Discord-Bots oder Regelwerke, die benutzerdefinierte JavaScript-Skripte ausführen.

Kurzfristige Maßnahmen: Updates

Für Anwender, die vm2 weiterhin nutzen, ist ein dringendes Update auf die neuesten Versionen der Bibliothek erforderlich:

• Für CVE-2026-22709: Update auf vm2 Version 3.10.2 oder neuer (empfohlen 3.10.3).
• Für CVE-2026-26956: Update auf vm2 Version 3.10.5.

Diese Updates schließen die identifizierten Lücken und verhindern die Ausnutzung durch bekannte Exploits.

Langfristige Empfehlungen: Migration zu robusteren Lösungen

Experten weisen darauf hin, dass die Architektur von vm2, die auf JavaScript-Proxies zur Isolation basiert, prinzipiell anfällig für Sandbox-Escapes ist. Das Projekt vm2 wurde ursprünglich Mitte 2023 eingestellt, bevor es Ende 2025 unter dem Titel "Resurrection" wiederbelebt wurde. Die wiederholten kritischen Sicherheitslücken unterstreichen die inhärenten Herausforderungen, JavaScript-Code innerhalb der V8-Engine zuverlässig zu isolieren.

Für eine robustere und langfristig sicherere Lösung wird die Migration zu alternativen Technologien empfohlen:

• `isolated-vm`: Diese Bibliothek nutzt V8 Isolates, eine niedrigere Primitive auf C++-Ebene, die eine wesentlich stärkere Speichersicherheit bietet als die kontextbasierte Isolation von vm2.
• Deno: Deno verfügt über ein integriertes Sicherheitsmodell auf Laufzeitebene. Die Ausführung von unvertrautem Code in einem Deno-Subprozess mit eingeschränkten Berechtigungen (`--allow-none`) gilt als Goldstandard.
• Containerisierung: Die Ausführung von unvertrautem Code in ephemeren Docker-Containern oder Firecracker MicroVMs bietet eine physische Trennung, die über die logische Sandbox-Isolation hinausgeht.

Fazit und Ausblick

Die jüngsten Entdeckungen von kritischen Schwachstellen in der vm2-Bibliothek sind eine deutliche Erinnerung an die Komplexität und die fortwährenden Herausforderungen im Bereich der Softwaresicherheit. Insbesondere in der schnelllebigen Welt der JavaScript-Entwicklung kann die Abhängigkeit von nicht gewarteten oder architektonisch anfälligen Bibliotheken erhebliche Risiken bergen. Unternehmen und Entwickler sind angehalten, ihre Systeme regelmäßig auf Schwachstellen zu überprüfen und proaktiv in sicherere Architekturen und Technologien zu investieren, um potenzielle Angriffsvektoren zu minimieren und die Integrität ihrer Anwendungen zu gewährleisten.

Bibliographie

• Schirrmacher, D. (2026, 7. Mai). Node.js 25: Ausbrüche aus JavaScript-Sandbox vm2 vorstellbar. heise online.
• patriksimek. (2026, 1. Mai). WASM Sandbox Escape (Node 25 only) · Advisory · patriksimek/vm2. GitHub.
• patriksimek. (2026, 25. Januar). Sandbox Escape · Advisory · patriksimek/vm2. GitHub.
• Cybersicherheitsportal BW. (2026, 28. Januar). Kritische Schwachstelle in der Sandbox-Bibliothek vm2 für Node.js.
• Penligent.ai. (2026, 28. Januar). The Zombie Exploit: Deconstructing CVE-2026-22709 in Node.js vm2.
• Endor Labs. (n.d.). CVE-2026-26956, VM2 Has a WASM Sandbox Escape (Node 25 only).
• Knop, D. (2026, 29. Januar). JavaScript-Sandbox vm2: kritische Lücke erlaubt Ausbruch. heise online.
• CVEReports. (2026, 26. Januar). CVE-2026-22709: The Call Is Coming From Inside The House: Breaking vm2 with Method Hijacking.
• IT-Boltwise. (2026, 28. Januar). Kritische Sicherheitslücke in vm2: Sandbox-Ausbruch und Code-Ausführung.