Das Wichtigste in Kürze 

• STARFACE, unsere STARFACE-Module und der StarfleetController sind nicht betroffen. Sie basieren auf Java und enthalten weder Node.js noch vm2.
  EasySetup – ein Werkzeug zur Vorbereitung von Kundeninstallationen ist betroffen – wir haben es vorläufig vom Netz genommen.
• In der Sandbox-Bibliothek vm2 stecken sechs Lücken, die schwerste mit CVSS 10.0. Abhilfe schafft Version 3.11.8.
• Node.js schließt zehn eigene Lücken und aktualisiert mitgelieferte Bibliotheken wie OpenSSL, c-ares und undici. Abhilfe schaffen die Versionen 26.12.1, 24.22.1 und 22.23.4.
• Unser Webhosting und unsere internen Systeme haben wir bereits aktualisiert. Kunden mit Node.js-Anwendungen sollten ihre Anwendung neu starten und prüfen, ob sie vm2 verwenden.

Vorwort

Zeitgleich mit PHP2Shell gibt es auch neue Sicherheitsmeldungen aus der JavaScript-Welt. Zwei Themen treffen dabei zusammen: kritische Lücken in der Sandbox-Bibliothek vm2 und ein umfangreiches Sicherheitsupdate für die Laufzeitumgebung Node.js selbst.

Node.js ist heute eine der wichtigsten Grundlagen für Webanwendungen, Automatisierungs-Tools und Entwicklungsumgebungen. Auch bei uns spielt JavaScript eine große Rolle – wie wir schon im Artikel zum npm-Wurm Shai-Hulud beschrieben haben. In diesem Artikel ordnen wir die neuen Lücken ein und beantworten die Frage, die uns Kunden zuerst stellen: Bin ich betroffen?

vm2: Sechs Lücken in der Sandbox

Die Node.js-Bibliothek vm2 soll fremden JavaScript-Code isoliert ausführen, in einer sogenannten Sandbox. Sechs Schwachstellen erlauben es Angreifern, aus dieser Sandbox auszubrechen. Behoben sind sie in vm2 3.11.8. Das BSI fasst die Lücken im Sicherheitshinweis WID-SEC-2026-3071 zusammen.

Die schwerste Lücke hat die Höchstwertung CVSS 10.0: Angriff über das Netz, ohne Anmeldung und ohne Mitwirkung eines Nutzers. Wer Code in die Sandbox einschleusen kann, führt ihn danach mit den Rechten des Node.js-Prozesses aus. Betroffen sind alle Versionen vor 3.11.8.

Node.js: 10+ Lücken

Am 21. Oktober 2026 hat das Node.js-Projekt Sicherheitsupdates für alle unterstützten Versionslinien veröffentlicht. Sie schließen zehn Lücken in Node.js selbst, davon vier mit hohem Schweregrad.

Die vier Lücken mit hohem Schweregrad:

• CVE-2026-111497: Fehlerhafter Schreibzugriff im Brotli-Decoder, also beim Entpacken komprimierter Daten. Laut Node.js ist damit möglicherweise das Ausführen von Schadcode möglich.
• CVE-2026-105483 und CVE-2026-106069: Die Prüfung, ob ein TLS-Zertifikat zum Hostnamen passt, lässt sich mit ungewöhnlich geschriebenen IP-Adressen umgehen. Das erleichtert Man-in-the-Middle-Angriffe auf verschlüsselte Verbindungen.
• CVE-2026-105482: dns.resolve schneidet Namen mit NUL-Zeichen ab. Eine Anwendung fragt dann unter Umständen einen anderen Namen ab als den, den sie geprüft hat.

Dazu kommen drei Lücken mittleren Schweregrads, unter anderem bei der Zertifikatsprüfung und bei Zufallswerten von crypto.randomUUID(), sowie drei Lücken mit niedrigem Schweregrad im experimentellen Permission Model.

Geerbte Lücken: Node.js bringt viele fremde Bibliotheken direkt mit. Deren Sicherheitsupdates erreichen Anwender erst mit einer neuen Node.js-Version. Das Oktober-Release aktualisiert deshalb auch c-ares (DNS), undici (HTTP-Client), OpenSSL (in den Linien 22 und 24) und SQLite (Linie 22). Außerdem entfernt es ein Zwischenzertifikat der Zertifizierungsstelle eMudhra aus der Liste vertrauenswürdiger Zertifikate, weil es kompromittiert wurde. Über Lücken in OpenSSL haben wir bereits im Januar berichtet haben.

Hintergrund: Warum JavaScript-Sandboxes so schwer abzusichern sind

Viele Anwendungen erlauben es Nutzern, eigene Skripte zu hinterlegen – etwa Automatisierungs-Tools, Low-Code-Plattformen oder Chatbots. Damit diese Skripte keinen Schaden anrichten, laufen sie in einer Sandbox. vm2 baut diese Sandbox innerhalb desselben Node.js-Prozesses auf, in dem auch die Anwendung läuft.

Das Problem: Sandbox und Anwendung teilen sich die JavaScript-Laufzeitumgebung. JavaScript ist eine sehr dynamische Sprache. Objekte erben Eigenschaften über Prototypen, Fehlerobjekte tragen Verweise mit sich, asynchrone Aufgaben laufen später weiter. Jede dieser Eigenschaften kann zu einem Durchgang nach draußen werden. vm2 muss jeden dieser Wege einzeln abdichten. Die aktuellen Lücken zeigen, dass das nie vollständig gelingt.

vm2 hatte bereits in der Vergangenheit mehrere kritische Ausbruchslücken. Wer fremden Code sicher ausführen muss, sollte deshalb auf eine stärkere Trennung setzen: einen eigenen Prozess, eine eigene V8-Instanz (zum Beispiel mit isolated-vm) oder einen Container. Node.js weist selbst darauf hin, dass sein eingebautes Modul node:vm kein Sicherheitsmechanismus ist.

Bei Node.js selbst zeigt sich ein anderes Muster: Eine Laufzeitumgebung ist nur so sicher wie die Bibliotheken, die sie mitbringt. Ein Update von OpenSSL oder c-ares auf dem Betriebssystem allein reicht nicht, weil Node.js eigene Kopien davon enthält.

Sind unsere Produkte betroffen?

Unsere Kundenprodukte sind – mit einer Ausnahme – nicht betroffen. Unser Webhosting und unsere internen Systeme haben wir bereits aktualisiert.

STARFACE, der StarfleetController und unsere Module laufen auf Java. Ihre Weboberflächen entwickeln wir zwar mit JavaScript und TypeScript. Auf der Anlage läuft aber keine Node.js-Laufzeit und kein vm2. An Ihrer STARFACE müssen Sie nichts unternehmen.

EasySetup ist ein Werkzeug zur Vorbereitung einer STARFACE-Installation. Wir haben es vorläufig vom Netz genommen und überarbeiten es in diesem Zuge auch vollständig.

Hinweis für Kunden mit Node.js-Anwendungen in unserem Webhosting

Die Node.js-Versionen in Plesk haben wir auf den gepatchten Stand aktualisiert. Zwei Dinge können wir Ihnen aber nicht abnehmen:

1. Anwendung neu starten. Ein laufender Node.js-Prozess nutzt die neue Version erst nach einem Neustart. Starten Sie Ihre Anwendung in Plesk neu.
2. Abhängigkeiten aktualisieren. vm2 ist kein Bestandteil von Node.js, sondern eine Bibliothek in Ihrer Anwendung. Prüfen Sie mit npm ls vm2, ob Ihre Anwendung vm2 direkt oder über ein anderes Paket nutzt. Falls ja, aktualisieren Sie auf 3.11.8 oder neuer und starten Sie die Anwendung neu.

Bei Fragen hilft Ihnen unser Support.

Empfehlungen für eigene Node.js-Systeme

Betreiben Sie selbst Anwendungen auf Basis von Node.js, empfehlen wir:

1. Node.js aktualisieren auf 26.12.1, 24.22.1 oder 22.23.4. Ältere Linien wie Node.js 20 und 18 erhalten keine Sicherheitsupdates mehr und sollten abgelöst werden.
2. vm2 suchen und aktualisieren. vm2 steckt oft indirekt in Anwendungen, über ein anderes Paket. npm ls vm2 zeigt, ob und über welchen Weg es eingebunden ist. Mindestversion ist 3.11.8.
3. Lockfiles und Container prüfen. Feste Paketversionen in package-lock.json verhindern, dass ein Update automatisch ankommt. Docker-Images müssen mit einem aktuellen Node.js-Basis-Image neu gebaut werden.
4. Fremden Code stärker trennen. Führt Ihre Anwendung Code von Nutzern aus, verlassen Sie sich nicht allein auf eine Sandbox im selben Prozess. Ein eigener Prozess mit wenigen Rechten oder ein Container bietet deutlich mehr Schutz.
5. Hersteller fragen. Viele Produkte bringen Node.js oder vm2 mit, ohne dass es auf den ersten Blick sichtbar ist. Prüfen Sie die Sicherheitshinweise Ihrer Softwarelieferanten.

Quellen

• Node.js: October 2026 Security Releases
• heise online: Node.js fixt eigene und geerbte Sicherheitslücken
• Security-Insider: Kritische Sandbox-Lücken in vm2, Fix in 3.11.8
• GitHub Advisory GHSA-88hf-g992-jg85 (vm2, CVE-2026-92955)
• BSI-Sicherheitshinweis WID-SEC-2026-3071 (vm2)