Node2Shell: Wie wir Node.js-Laufzeiten und Deployments abgesichert haben

Am 21. Oktober 2026 veröffentlichte das Node.js-Projekt Sicherheitsupdates für die unterstützten Versionslinien 22, 24 und 26. Im Mittelpunkt der öffentlichen Diskussion steht CVE-2026-111497, häufig „Node2Shell“ genannt: ein Speicherfehler im mit Node.js ausgelieferten Brotli-Decoder, der bei der Verarbeitung speziell präparierter komprimierter Daten zu einem Absturz, zur Offenlegung von Prozessspeicher oder zur Ausführung von Code führen kann.

Für den Betrieb reicht es deshalb nicht, lediglich eine Abhängigkeit in einer Anwendung zu aktualisieren. Der fehlerhafte Decoder ist Teil der Node.js-Laufzeit. Entscheidend ist, welche Node-Version ein Build verwendet, welche Version im Zielsystem installiert ist und welcher Binärstand im tatsächlich laufenden Prozess steckt.

Was hinter Node2Shell steckt

Brotli ist ein Kompressionsverfahren, das unter anderem für HTTP-Inhalte verwendet wird. Laut Node.js-Sicherheitsmeldung kann ungültige Brotli-Eingabe den Decoder dazu bringen, über das Ende eines internen Puffers hinauszuschreiben. Angreifbar ist nicht automatisch jede Node.js-Anwendung: Eine ausnutzbare Datenstrecke muss nicht vertrauenswürdige Brotli-Daten bis zu einer Dekompression mit node:zlib führen. Wo dieser Pfad besteht, liegt das Problem jedoch unterhalb der eigentlichen Anwendungslogik im Prozessspeicher.

Ein solcher Pfad kann beispielsweise entstehen, wenn konfigurierte Middleware einen komprimierten Request-Body entpackt oder eine Anwendung eine Brotli-komprimierte Antwort eines anderen Dienstes verarbeitet. Ein einfacher Node.js-HTTP-Server dekomprimiert eingehende Brotli-Daten nicht allein dadurch, dass er sie empfängt. Die konkrete Erreichbarkeit hängt von Framework, Middleware, Proxy-Konfiguration und Anwendungscode ab; eingehende und ausgehende Datenverarbeitung sind dabei getrennt zu betrachten. Diese Expositionsanalyse ersetzt das Runtime-Update nicht.

Welche Node.js-Versionen korrigiert sind

Das Node.js-Projekt nennt für die betroffenen unterstützten Release-Linien folgende Sicherheitsversionen:

• Node.js 22: mindestens 22.23.4

• Node.js 24: mindestens 24.22.1

• Node.js 26: mindestens 26.12.1

Die Veröffentlichung behebt neben CVE-2026-111497 weitere Schwachstellen in DNS-Auflösung, TLS-Hostname-Prüfung, HTTP-Verbindungswiederverwendung, Zufallswerten in Snapshots und dem Permission Model. Ein selektiver Workaround nur für Brotli wäre daher kein gleichwertiger Ersatz für das vollständige Security Release.

Was ForgeOne konkret getan hat

Wir haben die Reaktion in drei Ebenen getrennt: verwaltete Sollstände, neu erzeugte Artefakte und der tatsächlich aktive Laufzeitstand. Diese Trennung ist wichtig, weil eine geänderte Versionsdatei noch keinen laufenden Dienst absichert.

Die drei Ebenen eines Runtime-Patches

1. Sollzustand: Verwaltete Node.js-Versionen, Runtime-Baselines sowie Vorgaben für CI und Deployment.

2. Ausgelieferte Laufzeitumgebung: Build oder Release-Artefakt, Container-Image oder separat installierte Runtime und kontrollierter Rollout.

3. Tatsächlich laufender Prozess: Aktive Node.js-Runtime, Prüfung des Versionsstands sowie Healthchecks und Betriebsüberwachung.

Ein aktualisierter Sollzustand ist noch kein Nachweis für einen aktualisierten Produktionsprozess.

1. Node.js-24-Baselines auf 24.22.1 angehoben

Die zentral verwalteten Runtime-Vorgaben für ForgeOneCMS, Nuxt-basierte Shopware-Frontends, OpenSchedule und das von uns betriebene XWiki-Frontend wurden auf Node.js 24.22.1 festgelegt. Auch die Container-Basis des ForgeOneCMS verwendet den korrigierten Node-24-Stand. Damit beziehen Neuinstallationen und nachfolgende Deployments nicht versehentlich wieder eine ältere 24.x-Version.

2. Anwendungen neu gebaut und ausgerollt

Die erforderliche Maßnahme hängt vom Deploymentmodell ab. Enthält ein Container-Image die Node.js-Laufzeit, muss es mit einer korrigierten Basis neu gebaut und ausgerollt werden. Bei Standalone-Artefakten und Deployment-Paketen ist zu prüfen, ob sie die Runtime enthalten oder auf eine separat installierte Laufzeit zugreifen. Ist Node.js separat installiert, können das Runtime-Update und ein anschließender kontrollierter Dienstneustart genügen. Auch CI- und Build-Umgebungen brauchen einen eigenen geprüften Versionsstand, selbst wenn die produktive Runtime getrennt bereitgestellt wird.

Für die erfassten ForgeOne-Dienste haben wir die jeweils betroffenen Container- und Release-Artefakte mit der korrigierten Runtime erzeugt, kontrolliert ausgerollt und die Dienste neu gestartet. So erreichte die Änderung nicht nur die verwaltete Konfiguration, sondern auch die Prozesse, die Anfragen verarbeiten.

3. Laufende Prozesse direkt geprüft

Nach dem Rollout haben wir die Node-Version über die ausführbare Datei der aktiven Systemd-Prozesse kontrolliert. Die ermittelten produktiven ForgeOneCMS-Instanzen sowie die deutschen und internationalen Talheim-Records-Nuxt-Storefronts liefen zum Prüfzeitpunkt mit Node.js 24.22.1. Diese Aussage bezieht sich bewusst auf die von uns erfassten und geprüften Dienste.

4. Funktions- und Betriebsprüfungen angeschlossen

Ein Sicherheitsupdate ist erst abgeschlossen, wenn der Dienst wieder stabil arbeitet. Deshalb gehören Dienststatus, Healthchecks, zentrale Webpfade und Logs zur Nachkontrolle. Zusätzlich bleibt das reguläre Monitoring aktiv, damit Fehler nach einem Rollout nicht erst über Rückmeldungen von Nutzerinnen und Nutzern sichtbar werden.

Warum ein npm-Update allein nicht genügt

CVE-2026-111497 steckt im gebündelten Brotli-Code der Node.js-Laufzeit. npm update oder ein neu erzeugtes Lockfile kann Anwendungsabhängigkeiten aktualisieren, ersetzt aber nicht automatisch das Node-Binary. Ebenso reicht eine neue Container-Basis in einer Datei nicht aus, wenn das Image nicht neu gebaut und der laufende Container nicht ersetzt wird.

Für eine belastbare Prüfung müssen folgende Fragen beantwortet werden:

• Welche Node.js-Version ist für Entwicklung, CI und Produktion vorgesehen?

• Enthält das Release-Artefakt die Runtime oder wird Node.js separat bereitgestellt?

• Wurde ein Artefakt mit gebündelter Runtime nach der Änderung tatsächlich neu gebaut?

• Wurde der Dienst oder Container mit dem neuen Artefakt neu gestartet?

• Welche Version verwendet der aktive Prozess jetzt wirklich?

Monitoring und weitere Einordnung

Die Bezeichnung „Node2Shell“ macht die Schwachstelle eingängig, ersetzt aber keine Expositionsanalyse. Logdaten können Abstürze, ungewöhnliche Request-Muster oder unerwartete Prozessstarts sichtbar machen. Sie können allein jedoch nicht beweisen, dass ein Speicherfehler nie ausgelöst wurde. Deshalb basiert unsere Maßnahme auf dem Herstellerupdate und der Verifikation des laufenden Stands, nicht auf der Annahme, dass fehlende Alarme fehlendes Risiko bedeuten.

Für wiederholbare Änderungen nutzen wir automatisierte Deployment-Vorgaben und kontrollierte Rollouts. Mehr dazu zeigen unsere Seiten zu Ansible, Wazuh und Tests im Lab.

Was Betreiber jetzt prüfen sollten

• Alle produktiven, internen und CI-seitigen Node.js-Laufzeiten inventarisieren.

• Unterstützte Release-Linien auf 22.23.4, 24.22.1 beziehungsweise 26.12.1 oder neuer aktualisieren.

• Container und Standalone-Artefakte neu bauen, wenn sie die Node.js-Runtime enthalten.

• Nach einer Runtime-Aktualisierung oder einem Deployment die betroffenen Dienste kontrolliert neu starten beziehungsweise Container mit der korrigierten Runtime ersetzen und anschließend die Node.js-Version des aktiven Prozesses prüfen.

• Eingehende und ausgehende Brotli-Datenpfade in Frameworks, Middleware und Proxys nachvollziehen.

• Healthchecks, zentrale Benutzerpfade und Logs nach dem Rollout prüfen.

• Nicht mehr unterstützte Node.js-Versionen ablösen; für sie gibt es keine regulären Sicherheitsupdates.

Aktive Node.js-Runtime unter Systemd prüfen

Die Ausgabe von node --version in einer interaktiven Shell muss nicht mit der Runtime des aktiven Dienstes übereinstimmen. Bei einem direkten Systemd-Prozess lässt sich zunächst ermitteln, welche ausführbare Datei dessen Hauptprozess verwendet:

PID=$(systemctl show -p MainPID --value mein-dienst.service)
readlink -f "/proc/$PID/exe"

Die gefundene Datei muss dem richtigen Prozess zugeordnet und ihre reale Version geprüft werden. Startet Systemd nur einen Wrapper, ein Shell-Skript oder einen Prozessmanager, ist gegebenenfalls der tatsächliche Node.js-Kindprozess zu untersuchen. Bei Containern erfolgt die Versionsprüfung innerhalb der laufenden Instanz. Der Dateipfad allein ist deshalb ebenso wenig ein universeller Nachweis wie die Ausgabe einer beliebigen interaktiven Shell.

Fazit

Node2Shell zeigt, warum Runtime-Patchmanagement mehr als Paketpflege ist. Inventar, eindeutige Sollversionen, reproduzierbare Builds, kontrollierte Rollouts und eine Prüfung am laufenden Prozess müssen zusammenpassen. Genau diese Kette haben wir für die erfassten ForgeOneCMS- und Nuxt-Dienste auf Node.js 24.22.1 geschlossen.