2026/10/28

Node2Shell (CVE-2026-111497): Welche Systeme gefährdet sind und was jetzt zu tun ist

Welche Systeme CVE-2026-111497 in Brotli wirklich gefährdet, wie dringend jeder Fall ist und wie Sie jetzt patchen, neu bauen, neu starten und absichern.

Aktualisiert am 27. Oktober 2026

CVE-2026-111497, auch „Node2Shell“ oder „HTTP2Shell“ genannt, ist ein Speicherfehler (Memory Corruption) im Brotli-Dekompressor. Brotli ist das im gesamten Web verwendete br-Kompressionsverfahren. Der Fehler steckt in Googles Brotli-Bibliothek in den Versionen 1.0.3 bis 1.2.0 [1]. Node.js bündelt diese Bibliothek, und das Node.js-Projekt hat das Problem für die Release-Linien 22.x, 24.x und 26.x als High eingestuft [2]. Derselbe Decoder steckt auch in Python-Paketen, Linux-Systembibliotheken, Desktop-Anwendungen und Entwicklerwerkzeugen. Die tatsächliche Angriffsfläche ist daher weit größer als nur „Node.js-Server“.

Dieser Artikel richtet sich an Teams, die schnell entscheiden müssen, ob sie betroffen sind und was sie zuerst tun sollten.

Fazit: Wenn eines Ihrer Systeme Brotli-Daten dekomprimiert, die von einer Stelle stammen, die Sie nicht kontrollieren (ein Client im Internet, eine externe Website, ein Webhook-Absender, eine hochgeladene Datei), behandeln Sie dies als dringend. Patchen, neu bauen, neu starten und br bis dahin blockieren.

Was die Schwachstelle bewirkt

Der Decoder verarbeitet einen fehlerhaften „Block Switch“ im komprimierten Datenstrom falsch. Er wertet den Fehler als „Ich brauche mehr Eingabedaten“ statt als „Diese Daten sind ungültig“ und hängt so lange Bytes an einen kleinen internen Puffer fester Größe an, bis er über dessen Ende hinausschreibt [2]. Ein Angreifer, der Ihre Anwendung dazu bringen kann, einen präparierten Brotli-Datenstrom zu dekomprimieren, kann den Prozessspeicher beschädigen. Das kann zu Folgendem führen:

Ein Absturz (Denial of Service). Das ist die zuverlässigste Folge.
Abfluss von Prozessspeicher. Antworten oder Logs könnten Fragmente von Secrets, Tokens oder Daten anderer Benutzer preisgeben.
Mögliche Remote Code Execution. Node.js führt RCE als mögliche Auswirkung auf [2]. Der erste öffentliche Proof of Concept erreichte Codeausführung nur gegen einen absichtlich geschwächten Build. Inzwischen haben Forscher jedoch eine nicht zuverlässige Codeausführung gegen einen offiziellen, unveränderten Build von Node.js 24.22.0 gemeldet [3].

Eine Authentifizierung ist nicht erforderlich: Der Angreifer muss lediglich Bytes einschleusen, die den Decoder erreichen. Deshalb liegt der CVSS-4.0-Score bei 9.2 (Critical) [1]. Die entscheidende Frage für jedes System lautet daher nicht „Nutzen wir Brotli?“, sondern „Kann eine nicht vertrauenswürdige Partei uns dazu bringen, Brotli zu dekomprimieren?“

Typische Einsatzszenarien und ihr Risiko

Fall 1: Aus dem Internet erreichbare APIs, die komprimierte Request-Bodies akzeptieren (höchste Priorität)

Manche Node.js-API-Server, BFFs, API-Gateways und Upload-Endpunkte dekomprimieren Request-Bodies, die mit Content-Encoding: br gesendet werden. Andere tun dasselbe über Middleware. Risiko: Jeder anonyme Client im Internet kann einen präparierten Body senden. Die Folgen reichen von wiederholten Abstürzen des Dienstes, also einem billigen DoS, bis zum Abfluss von Speicher aus einem Prozess, der Sitzungsdaten und API-Schlüssel hält. Dringlichkeit: Notfall. Patchen Sie noch heute und blockieren Sie br-Request-Bodies bis dahin am Netzwerkrand.

Fall 2: Dienste, die Inhalte von außen abrufen (hohe Priorität)

Webhook-Consumer, Crawler und Scraper, Linkvorschau- und RSS-Dienste, Zahlungs- oder SaaS-Integrationen sowie KI-Agenten, die im Web surfen, stellen alle ausgehende HTTP-Anfragen. Viele HTTP-Clients senden Accept-Encoding: br und dekomprimieren die Antwort automatisch. In Python tun urllib3 und requests dies immer dann, wenn das Paket Brotli oder brotlicffi installiert ist, selbst wenn Ihr Code es nie importiert. aiohttp verhält sich genauso, und httpx ebenfalls, wenn es mit seinem Brotli-Extra installiert wurde [4]. Risiko: Ein bösartiger, kompromittierter oder gefälschter entfernter Server kann Ihr Backend über seine Antwort angreifen. Der Angreifer muss Ihr Netzwerk dafür gar nicht erreichen: Sie rufen ihn auf. Dringlichkeit: hoch. Patchen Sie zuerst überall dort, wo die Ziele nicht vollständig vertrauenswürdig sind.

Fall 3: Desktop-Anwendungen, KI-Coding-Agenten und CLIs mit eingebetteter Runtime

Electron-Anwendungen, auf Bun oder Node basierende CLIs und KI-Entwicklerwerkzeuge bringen ihre eigene Kopie der Runtime mit. Ein Update des System-Pakets node behebt das Problem bei ihnen nicht. Auch ein Update der Anwendung auf der Festplatte behebt bereits laufende Instanzen nicht: Langlebige Prozesse behalten die alte Runtime im Speicher, bis sie neu gestartet werden. Risiko: Diese Werkzeuge verfügen oft über Zugangsdaten und rufen externe Inhalte ab, was Fall 2 mit einem privilegierten Prozess kombiniert. Dringlichkeit: hoch bei Werkzeugen, die nicht vertrauenswürdige Inhalte abrufen. Aktualisieren Sie sie und starten Sie sie anschließend tatsächlich neu. Die Falle „aktualisiert, aber es läuft noch der alte Code“ haben wir ausführlich behandelt in HTTP2Shell: Warum das Aktualisieren einer Binärdatei laufende Prozesse nicht absichert.

Fall 4: Container-Images und CI/CD-Artefakte

Images, die vor dem Fix mit FROM node:22, node:24 oder node:26 gebaut wurden, enthalten weiterhin die verwundbare Runtime, auch wenn der Host gepatcht ist. Dasselbe gilt für gebündelte Python-Wheels und vendorte Abhängigkeiten. Risiko: Der verwundbare Code kehrt bei jedem Deployment und jedem Autoscaling-Ereignis zurück, bis das Image neu gebaut wird. Dringlichkeit: hoch bei Images hinter Fall 1 und 2. Bauen Sie neu, statt nur neu zu starten.

Fall 5: Linux-Systembibliotheken, Schriftarten und Bildverarbeitung

Distributionen liefern den Decoder als Shared Library aus, zum Beispiel libbrotli1 unter Ubuntu/Debian. Er wird von curl und libcurl verwendet, wenn Kompression aktiviert ist, von FreeType für WOFF2-Webfonts und indirekt von Bild- und Dokumentwerkzeugen wie Pillow. Risiko: Systeme, die von Benutzern hochgeladene Schriftarten oder Dokumente rendern oder externe Inhalte mit curl --compressed abrufen, können von nicht vertrauenswürdigen Brotli-Daten erreicht werden. Ein Server, der diesen Bibliotheken nie externe Daten zuführt, ist praktisch nur gering exponiert. Dringlichkeit: in den meisten Fällen mittel, aber hoch bei Diensten für Dokument-Rendering oder Upload-Verarbeitung. Ubuntu hat korrigierte brotli-Pakete für 22.04, 24.04, 26.04 und 26.10 veröffentlicht [1]. Prüfen Sie für RHEL, Oracle Linux und andere Distributionen das Advisory Ihres Anbieters zum Paket brotli, statt einen Status anzunehmen.

Fall 6: Rein interne Systeme mit vertrauenswürdigen Eingaben (geringere Priorität)

Manche Dienste dekomprimieren Brotli nur aus Daten, die Sie selbst erzeugen, etwa interne Caches oder Ihre eigenen Build-Artefakte. Diese bergen ein geringeres Risiko, aber kein Nullrisiko: Ein Angreifer, der bereits Fuß gefasst hat, kann den Fehler nutzen, um weiter vorzudringen. Dringlichkeit: im nächsten regulären Zyklus patchen.

Was zu tun ist: Schritte zur Reaktion

Schritt 1: Ermitteln, wo Brotli dekodiert wird (heute)

Node.js: Prüfen Sie node -v auf jedem Host sowie in jedem Container-Image und CI-Runner. Durchsuchen Sie Code und Konfigurationen nach brotliDecompress, createBrotliDecompress und Body-Parsing-Middleware, die br entpackt.
Eingebettete Runtimes: Erfassen Sie die verwendeten Electron-Anwendungen, Bun/Node-CLIs und KI-Agenten und notieren Sie jeweils die eingebettete Runtime-Version, nicht nur die Anwendungsversion.
Python: pip show Brotli brotlicffi in jeder Umgebung und jedem Image. Suchen Sie in Lockfiles und SBOMs nach httpx[brotli] und transitiv eingebundenen Abhängigkeiten.
OS-Pakete: dpkg -l | grep brotli oder rpm -qa | grep brotli, und prüfen Sie dann, welche Prozesse die Bibliothek tatsächlich laden.
Priorisieren Sie anhand der obigen Fälle: Alles, was von nicht vertrauenswürdigen Eingaben erreicht werden kann (Fall 1, 2, 3 und 5 mit Uploads), kommt zuerst.

Schritt 2: Betroffene Komponenten patchen

Node.js: Aktualisieren Sie auf 22.23.4, 24.22.1 oder 26.12.1 oder neuer [2].
Python: Brotli>=1.2.1 oder brotlicffi>=1.2.1.0. Generieren Sie die Lockfiles neu [4].
Upstream-Brotli / vendorter C-Code: 1.0.10, 1.1.1 oder 1.2.1, je nach Branch [1].
OS-Pakete: Spielen Sie das Sicherheitsupdate Ihrer Distribution für brotli / libbrotli ein.
Desktop-Anwendungen und Agenten: Aktualisieren Sie auf Hersteller-Releases, die ausdrücklich die korrigierte Runtime enthalten. Hat ein Hersteller nichts veröffentlicht, betrachten Sie die Anwendung als nicht verifiziert statt als sicher.

Schritt 3: Neu bauen, neu deployen und neu starten

Bauen Sie Container-Images aus gepatchten Basis-Images neu und deployen Sie sie erneut. Ein Neustart eines alten Images hilft nicht.
Starten Sie jeden langlebigen Prozess neu, der die verwundbare Bibliothek geladen hatte: Node-Dienste, Worker, Agenten-Sitzungen und alles, was gegen die Systembibliothek gelinkt ist. Bei zustandsbehafteten Jobs und KI-Agenten sollten Sie die Arbeit zuerst abschließen lassen oder übergeben, damit keine eingereihten Ereignisse oder Freigaben verloren gehen.

Schritt 4: Risiken während des Patchens eindämmen

Eingehend: Weisen Sie Request-Bodies, deren Content-Encoding br enthält, am Reverse Proxy, Load Balancer oder an der WAF ab, bevor ein Decoder sie zu sehen bekommt.
Ausgehend: br aus Accept-Encoding zu entfernen, reicht allein nicht aus, da ein bösartiger Server trotzdem br senden kann. Weisen Sie zusätzlich Antworten mit Content-Encoding: br ab oder verweigern Sie deren Dekodierung [4].
Python-Notlösung: Wo ein Upgrade warten muss, deinstallieren Sie Brotli und brotlicffi, damit Clients br nicht mehr dekodieren. Testen Sie vorher, denn manche Server senden trotzdem br.

Schritt 5: Überprüfen und auf Anzeichen einer Ausnutzung achten

Bestätigen Sie die Runtime-Version aus dem laufenden Prozess oder Container heraus, nicht nur über den Paketmanager.
Scannen Sie Images und SBOMs erneut, um sicherzustellen, dass keine ältere Kopie mehr transitiv eingebunden wird.
Prüfen Sie aktuelle Logs auf unerklärliche Abstürze, Segmentation Faults oder Neustartschleifen in Diensten, die br verarbeiten. Eine Häufung von Abstürzen aus einer einzigen Quelle sollte als möglicher Angriffsversuch untersucht werden.
Ist ein stark exponierter Dienst vor dem Patchen unerwartet abgestürzt, sollten Sie die Secrets rotieren, die dieser Prozess hielt, da eine Offenlegung von Speicherinhalten nicht ausgeschlossen werden kann.

Zusammenfassung

Situation	Risiko	Maßnahme
Öffentliche API dekodiert `br`-Request-Bodies	Kritisch	Sofort patchen; `br` am Netzwerkrand blockieren
Backend ruft externe URLs, Webhooks oder Webseiten ab	Hoch	Sofort patchen; `br`-Antworten ablehnen
Electron-Anwendungen, KI-Agenten oder CLIs mit eingebetteter Runtime	Hoch	Aktualisieren und jede laufende Instanz neu starten
Alte Container-Images und CI-Artefakte	Hoch	Aus gepatchten Basis-Images neu bauen und erneut deployen
Systembibliothek für Uploads, Schriftarten oder `curl --compressed`	Mittel–Hoch	OS-Update einspielen; Dienste, die sie laden, neu starten
Nur interne, vertrauenswürdige Daten	Niedrig–Mittel	Im nächsten Zyklus patchen

Das Paket zu patchen ist nur die halbe Arbeit. Die Gefährdung ist erst beseitigt, wenn kein laufender Prozess, kein Image und keine eingebettete Runtime nicht vertrauenswürdige Brotli-Daten noch mit dem alten Code dekodieren kann.