CVE-2026-92944: kritischer Sandbox-Escape in vm2 für Node.js 26

CVE-2026-92944: kritischer Sandbox-Escape in vm2 für Node.js 26

Kurz gefasst

Es wurde eine kritische Schwachstelle (CVE-2026-92944, CVSS 9.3) in der Bibliothek vm2 veröffentlicht, die zur Ausführung von Code in isolierten Umgebungen ("Sandbox") innerhalb von Node.js-Anwendungen verwendet wird [1]. Der Fehler ermöglicht es nicht vertrauenswürdigem Code, aus der Sandbox zu entkommen und die Kontrolle über den Host-Prozess zu übernehmen, wenn dieser unter Node.js 26 ausgeführt wird [1][2]. Wenn Ihr Unternehmen Anwendungen entwickelt oder einsetzt, die Code von Drittanbietern oder Nutzern mittels vm2 ausführen, ist der erste Schritt noch heute, zu identifizieren, wo diese Bibliothek verwendet wird, und die installierte Version zu überprüfen.

Was es ist und warum es wichtig ist

vm2 ist ein von Entwicklern häufig genutztes Tool, um JavaScript-Code aus nicht vertrauenswürdigen Quellen innerhalb einer vermeintlich vom Rest der Anwendung isolierten Umgebung auszuführen: Nutzer-Plugins, individuelle Skripte, Korrektoren für Programmierübungen, Regelmaschinen usw. Die Idee dahinter ist, dass, egal was innerhalb dieses Codes passiert, er nicht "entkommen" oder das reale System berühren kann.

Laut der offiziellen Beschreibung des Fehlers wird in den vm2-Versionen zwischen 3.10.2 und 3.11.6 ein interner Mechanismus der V8-Engine (der Protector namens PromiseThenLookupChain) unter Node.js 26 nicht aktualisiert, wodurch eine von einem Angreifer geschickt konstruierte asynchrone Funktion die Schutzmechanismen der Sandbox über die Methode Promise.prototype.finally() umgehen kann [1]. Das Ergebnis ist, dass der "isolierte" Code interne Systemfunktionen erreichen und beliebigen Code mit den Berechtigungen des Hauptprozesses ausführen kann [1][2].

Das eigene Intel des OCIRIA-Radars, der relevante Schwachstellen für Entwicklungs- und Produktionsinfrastrukturen überwacht, ordnet diesen Fall in die Kategorie Remote-Code-Ausführung ein und weist darauf hin, dass seine Bedeutung gerade darin liegt, dass er die Grundprämisse der Isolation bricht: Wenn die Sandbox versagt, ist die gesamte Anwendung – und potenziell weitere Daten und Dienste im selben Prozess – gefährdet [2].

Was die Frage betrifft, ob es Hinweise auf eine aktive Ausnutzung in der realen Welt gibt: Zum Zeitpunkt dieser Veröffentlichung ist die CVE nicht im Katalog bekannter ausgenutzter Schwachstellen (KEV) aufgeführt, den die US-Behörde CISA führt [3]. Das bedeutet nicht, dass sie harmlos ist – ihre Bewertung von 9.3 stuft sie unter die schwerwiegendsten ein [1] –, sondern lediglich, dass derzeit keine dokumentierten Belege für aktive Angriffskampagnen vorliegen.

Wen betrifft es

Diese Schwachstelle betrifft Organisationen, die:

• Node.js-Anwendungen entwickeln oder pflegen, die die Bibliothek vm2 verwenden, um die Ausführung von Code Dritter oder von Nutzern zu isolieren.
• ihre Umgebungen auf Node.js 26 aktualisiert haben oder dabei sind, dies zu tun, da sich der Fehler aufgrund einer Änderung in der V8-Engine speziell in dieser Runtime-Version zeigt [1].
• Plattformen des Typs "Code als Dienstleistung" betreiben: Online-Editoren, Test-Sandboxes, Automatisierungs-Engines, serverseitig ausgeführte Plugins oder Erweiterungen, automatische Korrektoren usw.

Die von OCIRIA verwaltete strukturierte Wahrheit identifiziert keine konkreten betroffenen Anbieter über das Paket vm2 selbst hinaus. Wir empfehlen daher, nicht anzunehmen, dass ein bestimmter Anbieter betroffen ist oder nicht, ohne dies direkt zu überprüfen.

Wie Sie herausfinden, ob Sie betroffen sind

Es gibt keine allgemeine Möglichkeit, dies "auf den ersten Blick zu erkennen": Es hängt davon ab, welche Abhängigkeiten Ihr Code verwendet und in welcher Umgebung er ausgeführt wird. Wir empfehlen:

1. Das Abhängigkeitsinventar Ihrer Node.js-Anwendungen (package.json / package-lock.json) auf vm2 zu überprüfen und die genaue installierte Version zu kontrollieren.

2. Zu bestätigen, welche Node.js-Version jeder Dienst in der Produktion ausführt, mit besonderem Augenmerk auf diejenigen, die bereits unter Node.js 26 laufen.

3. Die exponierte Oberfläche Ihrer Dienste und Entwicklungsumgebungen zu überprüfen, insbesondere jener, die externen Code akzeptieren oder ausführen, um unkontrollierte oder nicht inventarisierte Expositionspunkte zu identifizieren.

Wie Sie sich schützen können

• Aktualisieren Sie vm2 auf eine gepatchte Version, sobald der Projektbetreuer diese veröffentlicht; erwägen Sie in der Zwischenzeit, Funktionen, die nicht vertrauenswürdigen Code ausführen, einzuschränken oder vorübergehend zu deaktivieren, wenn das Risiko hoch ist [2].
• Überprüfen Sie die Verwendung von Sandboxes generell: Da sich diese Fehlerfamilie (Sandbox-Escape) häufig wiederholt, bewerten Sie, ob Ihre Architektur zu stark von einem einzigen Isolationsmechanismus auf Prozessebene abhängt oder ob es sich lohnt, diesen durch zusätzliche Isolation zu verstärken (Container, leichtgewichtige virtuelle Maschinen, eingeschränkte Betriebssystemberechtigungen).
• Überprüfen Sie den in der Sandbox ausgeführten Code aus nicht vertrauenswürdigen Quellen: externe Nutzer, Plugins Dritter oder wenig kontrollierte Integrationen.
• Überwachen Sie Sicherheitswarnungen der kritischen Bibliotheken, die Teil Ihrer Software-Lieferkette sind, nicht nur der wichtigsten Frameworks.
• Priorisieren Sie nach tatsächlicher Exposition: Wenn Ihre Dienste keinen Drittanbieter-Code in einer Sandbox ausführen oder Sie kein Node.js 26 verwenden, ist das unmittelbare Risiko geringer, es sollte aber für zukünftige Überprüfungen dokumentiert werden.

Häufig gestellte Fragen

Wie schwerwiegend ist diese Schwachstelle?

Laut NVD hat sie eine CVSS-Bewertung von 9.3 und wird als kritisch eingestuft [1].

Wird diese Schwachstelle derzeit aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung ist sie nicht im Katalog bekannter ausgenutzter Schwachstellen (KEV) der CISA verzeichnet, daher liegen keine dokumentierten Belege für eine aktive Ausnutzung vor [3].

Betrifft es jede Node.js-Anwendung?

Nein. Es betrifft speziell Anwendungen, die die Bibliothek vm2 (Versionen 3.10.2 bis 3.11.6) zur Ausführung von Code in einer Sandbox verwenden, und der beschriebene Escape tritt im Kontext von Node.js 26 auf [1].

Was soll ich tun, wenn ich nicht weiß, ob ich vm2 verwende?

Überprüfen Sie das Abhängigkeitsinventar Ihrer Node.js-Projekte, und falls Sie Zweifel an der tatsächlichen Exposition Ihrer Systeme haben, empfiehlt sich eine umfassendere Überprüfung Ihrer exponierten Oberfläche.

Quellen

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-92944
• [2] https://github.com/advisories/GHSA-27g9-p43v-cw3v
• [3] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json