Kurzfassung

Für die Node.js-Sandbox-Bibliothek vm2 sind inzwischen neunzehn zusammenhängende kritische Schwachstellen öffentlich dokumentiert worden. Mehrere davon erreichen CVSS 10.0, kritisch, und ermöglichen aus einer eigentlich isolierten VM oder NodeVM heraus die Ausführung beliebiger Befehle im Host-Prozess, den Zugriff auf Speicherinhalte, das Mitlesen sensibler Verbindungen, globale Manipulationen an DNS- oder Vertrauenseinstellungen sowie Denial-of-Service bis hin zum Prozessabbruch. Für Unternehmen ist das vor allem dort akut, wo vm2 fremden oder nur teilweise vertrauenswürdigen JavaScript-Code ausführt, etwa in Plug-in-Systemen, Automatisierungsplattformen, Low-Code-Backends oder Multi-Tenant-Diensten.

Was ist passiert?

vm2 wird in Node.js-Umgebungen eingesetzt, um nicht vertrauenswürdigen JavaScript-Code in einer Sandbox laufen zu lassen. Genau dieses Schutzversprechen wird durch eine ganze Serie neuer Schwachstellen unterlaufen. Betroffen sind unterschiedliche Fehlerklassen: unvollständige Schutzmechanismen, unsichere Weitergabe von Host-Objekten, Umgehungen von Modulbeschränkungen und problematische Interaktionen mit eingebauten Node.js-Modulen.

Im Kern geht es fast immer um denselben Effekt: Code innerhalb der VM oder NodeVM kann aus der Sandbox ausbrechen oder auf Ressourcen des Host-Prozesses zugreifen, die eigentlich abgeschirmt sein sollten. Dazu gehören Betriebssystembefehle, Prozessobjekte, TLS-Vertrauensstellungen, HTTP(S)-Verbindungen, DNS-Auflösung, native Bibliotheken, Speicherbereiche und globale Prototypen. Hinzu kommen Fehler, die keine direkte Codeausführung liefern, aber die Verfügbarkeit des Host-Prozesses beeinträchtigen oder Sicherheitsgrenzen bei Paket- und Builtin-Freigaben aushebeln.

Die betroffenen Kennungen sind CVE-2026-92934, CVE-2026-92935, CVE-2026-92937, CVE-2026-92938, CVE-2026-92939, CVE-2026-92940, CVE-2026-92941, CVE-2026-92944, CVE-2026-92946, CVE-2026-92947, CVE-2026-92948, CVE-2026-92950, CVE-2026-92951, CVE-2026-92953, CVE-2026-92954, CVE-2026-92955, CVE-2026-92956, CVE-2026-92957 und CVE-2026-92960. Ein Teil der Fehler wurde laut NVD in vm2 3.11.7 behoben, weitere aber ausdrücklich erst in 3.11.8.

Technische Details

Die technische Schwere der Serie ist außergewöhnlich hoch. Der zusammengefasste Referenzwert liegt bei CVSS 10.0, kritisch. Der Vektor CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/… bedeutet hier: Angriffe sind über das Netzwerk möglich, die Komplexität ist gering, es sind keine Berechtigungen und keine Nutzerinteraktion nötig. Dieser Wert beschreibt die technische Schwere, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn. Einzelne neu hinzugekommene Einträge weichen im Angriffsmodell davon ab, etwa mit lokalem Zugriff, Nutzerinteraktion oder bereits vorhandenen Rechten, bleiben wegen der möglichen Auswirkungen aber ebenfalls kritisch.

CVE-2026-92934 betrifft vm2 vor 3.11.8. Hier war eine frühere Absicherung von Error.cause unvollständig. Unter bestimmten Bedingungen lassen sich unsanitierte Host-Proxys aus AggregateError-Strukturen in die Sandbox zurücktragen. Das kann zu Sandbox-Escape, Informationsabfluss und letztlich Codeausführung im Host-Prozess führen.

CVE-2026-92935 betrifft die Versionen 3.11.4 bis 3.11.6. Ein Fehler in der Behandlung der require-Konfiguration erlaubt es, bei aktivierter Verschachtelung eine innere NodeVM mit eigener Builtin-Freigabe zu erzeugen. So kann fremder Code etwa child_process freischalten und Befehle auf dem Host ausführen. Als behoben wird vm2 3.11.7 genannt.

CVE-2026-92937 betrifft vm2 3.11.6. Eine unvollständige Korrektur in der Behandlung abgelehnter Promises lässt sich über Umwege mit call oder apply umgehen. Dadurch gelangen Host-Fehlerobjekte mit sensiblen Eigenschaften in die Sandbox. Wenn diese auf Host-Objekte verweisen, ist erneut ein Ausbruch mit Remote Code Execution möglich. Laut NVD wurde auch dieser Fehler in 3.11.7 behoben.

Eng verwandt ist CVE-2026-92954. Betroffen sind vm2-Versionen ab 3.10.0 bis einschließlich 3.11.7. Hier werden aus dem Host-Kontext in die Sandbox zurückgereichte Promises an der Bridge-Grenze nicht grundsätzlich als behandelt markiert. Wenn Sandbox-Code etwa eine Host-Funktion aufruft, die ein abgelehntes Promise zurückliefert, und den Rückgabewert einfach ignoriert, kann das Standardverhalten von Node.js zu einer unbehandelten Rejection und damit zum Abbruch des Host-Prozesses führen. Das ist kein klassischer Escape, aber ein kritischer Verfügbarkeitsfehler und laut Beschreibung ebenfalls eine unvollständige Behebung eines früheren Promise-bezogenen Problems. Als Fix wird 3.11.8 genannt.

CVE-2026-92938 betrifft vm2 3.11.3 bis 3.11.6 in Konfigurationen, die das Builtin node:sqlite erlauben. Durch eine Umgehung beim Modulnamen und die Weitergabe aufrufbarer Host-Funktionen kann Sandbox-Code native Erweiterungen laden. Das hebelt die Isolation vollständig aus und führt zu nativer Codeausführung im Host-Prozess.

CVE-2026-92939 betrifft vm2 3.11.3 bis 3.11.6, wenn das Builtin crypto erlaubt ist. Der Aufruf von crypto.setEngine() kann eine vom Angreifer bereitgestellte native Bibliothek laden. Schon dadurch wird Code im Kontext des Host-Prozesses ausgeführt, auch ohne Zugriff auf klassische gefährliche Module wie child_process oder fs.

CVE-2026-92940 betrifft vm2 3.11.3 bis 3.11.6, wenn require(‚https‘) erlaubt ist. Sandboxed Code kann sich an Ereignisse des echten https.globalAgent hängen. Damit lassen sich unter anderem Autorisierungsheader, Zielsysteme und Antwortdaten fremder Host-Anfragen mitlesen oder für eigene authentisierte Requests missbrauchen.

CVE-2026-92941 betrifft vm2 ab 3.11.3 vor 3.11.7 bei freigegebenen tls- und url-Builtins. Angreifer können prozessweit die Standard-Zertifizierungsstellen austauschen. Praktisch bedeutet das: Nachfolgende HTTPS-Verbindungen des Hosts könnten manipulierten Zertifikaten vertrauen, was Man-in-the-Middle-Angriffe auf nachgelagerte Kommunikation erleichtert.

CVE-2026-92944 betrifft vm2 3.10.2 bis 3.11.6 auf Node.js 26. Ein Problem rund um Promise.prototype.finally() und Schutzmechanismen in V8 erlaubt es, zum Host-Function-Konstruktor und zum process-Objekt vorzudringen. Auch hier ist das Ergebnis letztlich beliebige Codeausführung.

CVE-2026-92946 betrifft vm2 vor 3.11.7, wenn require.external aktiviert ist und keine restriktive require.root-Konfiguration node_modules wirksam ausschließt. Dann kann Sandbox-Code das eigene vm2-Paket nachladen, eine unbeschränkte NodeVM erzeugen und Host-Kommandos über child_process starten.

In denselben Themenblock fällt CVE-2026-92951. Ebenfalls vor 3.11.7 prüft vm2 die Allowlist externer Pakete an einer Stelle nicht anhand vollständiger Paketnamensgrenzen, sondern über nicht-exakte Teilstring-Treffer. Dadurch kann ein Angreifer ein Paket mit kollidierendem Namen laden, das den Namen eines erlaubten Pakets nur als Teilzeichenfolge enthält. Im Ergebnis werden nicht autorisierte Host-Pakete im Host-Kontext geladen und ausgeführt, obwohl die Freigabeliste das eigentlich verhindern sollte.

CVE-2026-92947 betrifft vm2 vor 3.11.7. Hier wird der gemeinsam genutzte Buffer-Pool von Node.js für die Sandbox sichtbar. Das ermöglicht das Lesen und Schreiben von Daten in Host-Buffer-Bereichen. Neben Informationsabfluss kann das auch zu Instabilitäten oder Denial-of-Service führen.

Ergänzend dazu beschreibt CVE-2026-92953 einen weiteren Integritätsfehler an gemeinsam genutzten Grundlagen zwischen Host und Sandbox. Betroffen sind Versionen 3.11.0 bis vor 3.11.8. Host-Prototypen von Uint8Array, %TypedArray% und ArrayBuffer werden nicht ausreichend gegen Manipulationen aus der Sandbox geschützt. Angreifer können diese Prototypen über entsprechende Primitive erreichen und verändern, sodass vom Host erzeugte Typed Arrays nach Rückkehr aus VM.run() angreiferkontrollierte Eigenschaften beobachten. Das ist nicht in jedem Fall sofort ein Escape, unterläuft aber die Trennung zwischen Sandbox- und Host-Zustand und kann nachgelagerte Sicherheitsannahmen brechen.

CVE-2026-92948 betrifft vm2 3.9.6 bis 3.11.6 auf Node.js 24 und neuer, wenn explizit node:test freigegeben ist. Über eine Allowlist-Umgehung kann die Sandbox das Host-Modul node:test nutzen, einen separaten Node-Prozess starten und über manipulierte Startparameter beliebigen JavaScript-Code außerhalb der Sandbox ausführen.

Eine weitere Builtin-bezogene Umgehung ist CVE-2026-92957. Betroffen ist vm2 bis einschließlich 3.11.6. Bei einer NodeVM-Policy mit Wildcard-Freigaben und negativen Deny-Einträgen werden node:-Präfixe nicht konsistent normalisiert. Eine Konfiguration wie builtin: [‚*‘, ‚-node:child_process‘] verhindert daher nicht zuverlässig den Zugriff auf das kanonische Builtin child_process. Sandbox-Code kann child_process trotzdem laden und damit Prozessstart-APIs wie execSync oder spawn erhalten. Behoben wurde der Fehler in 3.11.7.

CVE-2026-92950 betrifft vm2 vor 3.11.7 und nicht die eigentliche Einbettung per API, sondern das mitgelieferte CLI-Werkzeug. Wird dem vm2-CLI eine bösartige Skriptdatei übergeben, kann diese sich über require(__filename) im Host-Kontext erneut ausführen, die Sandbox-Isolation umgehen und anschließend auf Host-Module wie fs oder child_process zugreifen. Das erweitert die Angriffsfläche für Umgebungen, die vm2 nicht nur als Bibliothek, sondern auch als Kommandozeilenwerkzeug zum Testen oder Ausführen fremder Skripte einsetzen.

CVE-2026-92955 betrifft vm2 vor 3.11.8 und beschreibt einen weiteren NodeVM-Escape mit maximaler technischer Schwere. Über console._stdout und console._stderr lässt sich auf Host-seitige __proto__-Getter und -Setter zugreifen. Angreifer können dadurch EventEmitter.prototype.emit überschreiben und beim Auslösen von Prozessereignissen Code mit Prozesskontext ausführen. Die in vm2 vorgesehenen Einschränkungen der Codegenerierung werden so umgangen.

CVE-2026-92956 erweitert die Serie um einen Escape, der schon aus einer Standardkonfiguration new VM() heraus erreichbar ist. Betroffen sind vm2 3.10.1 bis 3.11.6 auf Node.js 26. Über WebAssembly.compileStreaming beziehungsweise WebAssembly.instantiateStreaming kann ein rohes Host-Promise entstehen, das mit einem Host-Fehlerobjekt fehlschlägt. In Verbindung mit einer Steuerung von Symbol.species via Promise.prototype.finally erhält Sandbox-Code dieses Host-Fehlerobjekt, leitet daraus den Host-Function-Konstruktor ab und gewinnt Zugriff auf das echte Host-process-Objekt. Bemerkenswert ist hier, dass laut Beschreibung weder NodeVM noch require-Rechte oder eine anderweitig riskante Konfiguration vorausgesetzt werden. Als behoben wird 3.11.7 genannt.

CVE-2026-92960 betrifft vm2 vor 3.11.6 unter der Konfiguration builtin: [‚*‘]. In diesem Fall werden die Builtins os und dns nicht wirksam eingeschränkt. Sandbox-Code kann dadurch Informationen über Prozessidentität und Netzwerktopologie auslesen. Schwerer wiegt, dass über dns.setServers() der DNS-Resolver des Host-Prozesses global auf einen angreiferkontrollierten Server umgebogen werden kann, sodass nachfolgende DNS-Anfragen des Hosts fehlgeleitet oder überwacht werden.

Wer ist betroffen?

Unmittelbar betroffen sind Betreiber und Entwickler, die vm2 in eigenen Node.js-Anwendungen einsetzen. Besonders relevant ist das für Plattformen, die JavaScript von Kunden, Partnern, internen Fachbereichen oder Community-Plug-ins ausführen. Typische Beispiele sind Workflow-Engines, Skriptfunktionen in SaaS-Produkten, Build- oder Automatisierungsdienste, Chatbot-Backends, regelbasierte Integrationsplattformen und Plug-in-Ökosysteme.

Nicht jede Installation ist für jede CVE gleichermaßen anfällig. Einige Schwachstellen setzen bestimmte Konfigurationen voraus, etwa freigegebene Builtins wie https, tls, crypto, node:sqlite, node:test, os oder dns, aktiviertes require.external, Wildcard-Builtin-Policies mit Negativregeln oder verschachtelte NodeVMs. Andere Fehler sind deutlich allgemeiner und betreffen VM- oder NodeVM-Setups ohne zusätzliche Voraussetzungen, teils sogar die Standardkonfiguration unter bestimmten Node.js-Versionen.

Neu hinzu kommt, dass nicht nur API-Nutzer betroffen sein können. Wer das vm2-CLI verwendet, um fremde oder halbvertrauenswürdige Skripte lokal auszuführen, muss auch dieses Werkzeug in die Risikoanalyse einbeziehen. Ebenso relevant sind Produkte mit engen Allowlists für externe Pakete oder mit breit gefassten Builtin-Freigaben, weil gerade diese Schutzmechanismen durch mehrere der neu dokumentierten Lücken gezielt unterlaufen werden.

Für klassische Unternehmensanwendungen ohne Ausführung fremden JavaScript-Codes ist die praktische Relevanz meist gering. Wer vm2 jedoch genau zu diesem Zweck einsetzt, muss von hohem Risiko ausgehen. Dann ist die Annahme einer wirksamen Isolation nicht mehr haltbar.

Empfohlene Maßnahmen

Erstens: Prüfen Sie sofort, ob vm2 in Ihrer Umgebung überhaupt verwendet wird. Suchen Sie in package-lock.json, pnpm-lock.yaml, yarn.lock, im Container-Image und in SBOMs nach vm2. Berücksichtigen Sie dabei auch indirekte Abhängigkeiten über Drittprodukte oder interne Frameworks.

Zweitens: Aktualisieren Sie vm2 umgehend mindestens auf 3.11.8, sofern Ihre Anwendung darauf lauffähig ist. Das ist wichtig, weil CVE-2026-92934 ausdrücklich erst ab 3.11.8 als behoben gilt, während mehrere andere Lücken bereits in 3.11.7 adressiert wurden. Mit den neu hinzugekommenen Meldungen gilt das noch stärker, weil auch CVE-2026-92953, CVE-2026-92954 und CVE-2026-92955 erst in 3.11.8 als behoben beschrieben werden.

Drittens: Wenn ein sofortiges Update nicht möglich ist, reduzieren Sie die Angriffsfläche konsequent. Deaktivieren Sie die Ausführung nicht vertrauenswürdiger Skripte vorübergehend. Entfernen Sie, wo technisch machbar, freigegebene Builtins wie https, tls, crypto, node:sqlite, node:test sowie breit gefasste Freigaben für os und dns. Schalten Sie require.external und nesting ab, sofern diese Funktionen nicht zwingend gebraucht werden. Vermeiden Sie außerdem Wildcard-Builtin-Policies mit Negativlisten, wenn deren korrekte Wirkung nicht verifiziert ist.

Viertens: Begrenzen Sie die Folgen eines erfolgreichen Ausbruchs. Lassen Sie betroffene Dienste mit minimalen Rechten laufen, isolieren Sie sie zusätzlich per Container, seccomp, AppArmor oder vergleichbaren Mechanismen und unterbinden Sie unnötige Netzwerkverbindungen des Prozesses. Eine Sandbox innerhalb einer stark privilegierten Anwendung ist in dieser Lage besonders riskant.

Fünftens: Kontrollieren Sie auf Missbrauchsspuren. Achten Sie auf unerwartete Kindprozesse, verdächtige exec-Aufrufe, das Laden nativer Bibliotheken, ungewöhnliche HTTPS-Verbindungen, Änderungen an Zertifikatsvertrauen, auffällige DNS-Resolver-Einstellungen sowie nicht erklärbare Speicher-, Promise- oder Prozessanomalien. Wer Plug-ins oder Kundenskripte ausführt, sollte Logs und Telemetrie der betroffenen Laufzeit gesondert prüfen.

Sechstens: Falls Sie vm2-CLI intern nutzen, behandeln Sie auch lokale Skriptquellen als potenziell gefährlich und stellen Sie sicher, dass dieses Werkzeug nicht mit höher privilegierten Rechten oder in sensiblen Build- und Administrationskontexten eingesetzt wird. Für Allowlists externer Pakete sollten Sie überprüfen, ob nur exakt gewünschte Paketnamen erreichbar sind und ob keine kollidierenden Namensvarianten geladen werden können.

Einschätzung von CyberSecurity-News.de

Die Serie ist für den DACH-Markt klar relevant, aber nicht für jeden gleichermaßen. Für die meisten Unternehmen ohne vm2-Einsatz ist sie operativ kaum bedeutend. Für Anbieter, die VM oder NodeVM zur Isolation fremden Codes verwenden, ist die Lage dagegen kritisch, weil hier nicht ein einzelner Randfehler vorliegt, sondern eine ganze Kette unterschiedlicher Escape-Wege.

Auffällig ist, dass mehrere Schwachstellen auf unvollständige Schutzannahmen rund um Proxys, Host-Objekte, Modulfreigaben, Promise-Bridges, Prototypen und Node.js-Builtins hinauslaufen. Das spricht weniger für einen einmaligen Ausrutscher als für grundsätzliche Risiken des Modells, untrusted Code im selben Prozess sicher kapseln zu wollen. Wer vm2 als harte Sicherheitsgrenze behandelt hat, sollte diese Annahme neu bewerten.

Die neuen Einträge verschärfen dieses Bild noch einmal. Sie zeigen, dass nicht nur offensichtliche Hochrisiko-Funktionen wie child_process oder externe Module problematisch sein können, sondern auch Randbereiche wie CLI-Verhalten, Deny-Listen, Promise-Fehlerbehandlung, globale Prototypen oder DNS- und TLS-Nebeneffekte. Gerade diese Breite macht die operative Verteidigung schwierig: Selbst sorgfältig konfigurierte Freigaben können an einzelnen Details scheitern, die im Alltag leicht übersehen werden.

Die Informationslage ist in einem Punkt unbefriedigend: Die NVD-Einträge nennen technische Details und betroffene Versionen, aber ohne zusätzlich übergebene Herstellerinformationen bleibt offen, wie der Maintainer die Gesamtlage priorisiert, welche Migrationshinweise es gibt und ob weitere Härtungsmaßnahmen empfohlen werden. Für Verteidiger zählt deshalb vor allem die praktische Konsequenz: Update einspielen, Konfiguration entschärfen und die Ausführung fremden Codes notfalls vorübergehend stoppen.

Fazit

Wenn Sie vm2 einsetzen, sollten Sie das Thema nicht aufschieben. Aktualisieren Sie auf mindestens 3.11.8 und schränken Sie bis dahin alle riskanten VM- und NodeVM-Funktionen ein, insbesondere externe Module, Verschachtelung, breite Builtin-Freigaben und problematische Deny- oder Allowlist-Konfigurationen.

Wer mit vm2 fremden Code im selben Host-Prozess ausführt, muss die Umgebung zusätzlich absichern. Die Schwachstellenserie zeigt deutlich, dass die Sandbox allein keine belastbare Sicherheitsgrenze darstellt.

Quellenangabe