Kritische vm2-Sandbox-Schwachstelle lässt nicht vertrauenswürdigen Code auf den Host ausbrechen

Die Maintainer von vm2, einer weit verbreiteten Sandbox-Bibliothek für Node.js, haben eine kritische Schwachstelle offengelegt, durch die nicht vertrauenswürdiges JavaScript aus seiner sandbox ausbrechen und Code auf dem Host-System ausführen kann. Die Lücke wird unter CVE-2026-26956 geführt, betrifft vm2 Version 3.10.4 und wurde veröffentlicht, obwohl bereits öffentlicher Proof-of-Concept-Exploit-Code verfügbar ist.

Das ist wichtig, weil vm2 zu den Standardwerkzeugen gehört, auf die Entwickler zurückgreifen, wenn sie von Nutzern geliefertes JavaScript in einer angeblich eingeschränkten Umgebung ausführen müssen. Die Bibliothek steckt in Online-Coding-Plattformen, Automatisierungsprodukten, AI-Tools und SaaS-Anwendungen, die Kunden das Ausführen von Scripts erlauben. Wenn in solcher Software ein Sandbox-Escape auftaucht, handelt es sich nicht um einen sauberen theoretischen Bug. Es ist eine direkte Frage, ob nicht vertrauenswürdiger Mandanten-Code zu einer Kompromittierung auf Host-Ebene führen kann.

Laut dem Advisory der Maintainer und der Berichterstattung von BleepingComputer hängt der Bug mit der Art zusammen, wie vm2 Ausnahmen behandelt, die zwischen der sandbox und dem Host wechseln. In der betroffenen Konfiguration kann WebAssembly exception handling die JavaScript-Schutzmechanismen von vm2 innerhalb der V8-Engine umgehen. Dadurch kann ein hostseitiges Fehlerobjekt zurück in die sandbox gelangen, wo Angreifer die constructor chain missbrauchen können, um wieder Zugriff auf Node.js-Interna wie das process object zu erhalten und letztlich beliebige Befehle auf dem Host auszuführen.

Die Gefährdung betrifft nicht pauschal jede Node.js-Bereitstellung. Dem Advisory zufolge wurde das Problem unter Node.js 25.6.1 in Umgebungen bestätigt, in denen WebAssembly exception handling und JSTag-Unterstützung aktiviert sind. Dieser technische Rahmen ist wichtig, sollte aber keine falsche Sicherheit erzeugen. vm2 wird über npm mehr als eine Million Mal pro Woche heruntergeladen, und solche Bibliotheken sind oft tief in größeren Produkten, internen Tools oder Erweiterungsfunktionen für Kunden verborgen, die Teams nicht sorgfältig genug inventarisieren.

Die dringendere Einzelheit ist, dass Exploit-Code bereits öffentlich ist. Sobald ein Sandbox-Escape sowohl eine CVE als auch einen öffentlichen Proof of Concept hat, schrumpft der Abstand zwischen Offenlegung und opportunistischer Ausnutzung meist schnell, besonders bei internetseitig erreichbaren Diensten, die Nutzer-Workflows, Code-Snippets oder Automatisierungsschritte ausführen. Wenn ein Unternehmen vm2 verwendet, um nicht vertrauenswürdige Logik zu isolieren, sollte es davon ausgehen, dass Angreifer diese Grenze jetzt testen, nicht später.

Der Patch-Pfad ist unkompliziert. Nutzer sollten vm2 3.10.4 sofort verlassen und auf Version 3.10.5 oder höher aktualisieren, wobei 3.11.2 derzeit verfügbar ist. Aber Patchen allein ist nicht die ganze Antwort. Teams sollten außerdem feststellen, wo vm2 eingebettet ist, bestätigen, ob betroffene Node.js-25-Konfigurationen im Einsatz sind, und alle Produktflächen überprüfen, auf denen externe Nutzer Code einreichen können, der am Ende eine vm2-Sandbox erreicht.

Diese Offenlegung passt zudem in ein breiteres Muster. vm2 war in den vergangenen Jahren von mehreren schweren Sandbox-Escape-Bugs betroffen, was eine schwierige, aber immer wichtigere Engineering-Frage aufwirft: Wie viel echte Isolation bietet eine JavaScript-Sandbox noch, wenn Angreifer Wege finden, die Schutzmechanismen auf Sprachebene zu umgehen? Für Teams, die Plattformen rund um von Nutzern ausgeführten Code bauen, wird diese Frage zunehmend architektonisch statt nebensächlich. Wie zuerst von BleepingComputer berichtet, besteht die sicherste Reaktion hier nicht nur darin, schnell zu patchen, sondern auch erneut zu prüfen, wie viel Vertrauen vm2 überhaupt eingeräumt wird.