Ist deine Node.js-Version anfällig für die Brotli-RCE? In 2 Minuten prüfen

Führen Sie diesen Befehl jetzt aus. Wenn Ihre Version unter dem Mindeststand in der Tabelle liegt, sind Sie von der Node.js-Brotli-RCE (CVE-2026-111497) betroffen – und Angreifer nutzen sie bereits aktiv aus.

Testen Sie Apidog noch heute

node -v 

Für eine zweite Bestätigung können Sie die Binärdatei direkt abfragen:

node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH" 

Mit dem Patch wurde diese Konstante hinzugefügt. Wir haben dies auf neun offiziellen macOS-Builds der drei unterstützten Versionsreihen getestet: Jeder behobene Build gab -17 aus, während ältere Builds undefined lieferten. Verlassen Sie sich jedoch vorrangig auf node -v, da Distributionen, die den Patch zurückportieren, diese Konstante möglicherweise nicht übernehmen.

Verlassen Sie sich nicht auf process.versions.brotli. Der Wert lautete sowohl unter 24.21.0 als auch 24.22.1 1.2.0 und sowohl unter 22.23.3 als auch 22.23.4 1.1.0. Node.js hat den Fix per Cherry-Pick übernommen, ohne die gemeldete Version zu ändern – daher lässt dieses Feld keinen Rückschluss darauf zu, ob Ihr System gepatcht ist.

TL;DR

ELLIO registrierte Exploit-Traffic in seinen Sensoren bereits am 26. Oktober – fünf Tage nach Bereitstellung des Fixes. Die abgefangene Payload zielte auf Node.js 24.22.0 unter x86-64 ab. Zwar schlug die letzte Stufe dieser Payload in den Tests von ELLIO fehl, ELLIO konnte jedoch auf Standard-Builds von 24.22.0 eine erfolgreiche Codeausführung eigenständig nachweisen. Die CISA hat US-Bundesbehörden eine Frist bis zum 10. November gesetzt und stuft die Nutzung durch Ransomware als „Unbekannt" ein. Telemetriedaten von Akamai zeigten, dass am 26. Oktober noch 61 % aller Netzwerke betroffene Versionen einsetzten.

Node2Shell erklärt: So funktioniert die Brotli-Schwachstelle

Node2Shell beruht auf einem Out-of-bounds Write im Brotli-Decoder, der fest in der Node.js-Runtime integriert ist. Ein manipulierter komprimierter Datenstrom veranlasst den Decoder dazu, über das Ende eines internen 8-Byte-Puffers hinaus zu schreiben, was den Arbeitsspeicher des Prozesses beschädigt. Die Folge können Programmabstürze, das Auslesen von Speicherinhalten oder die Ausführung von beliebigem Schadcode auf Ihrem Server sein.

Die eigentliche Ursache ist ein fehlerhaft eingestufter Fehlerzustand: Ein ungültiger Blockwechsel wurde fälschlicherweise als „weitere Eingabedaten erforderlich" statt als „Daten fehlerhaft" interpretiert, sodass der Streaming-Decoder fortlaufend weitere Bytes an diesen kleinen Puffer anfügte.

Der Fehler liegt in Googles Brotli-Bibliothek in den Versionen 1.0.3 bis 1.2.0 und ist somit kein reines Node.js-Problem. Das Node.js-Projekt hat seine integrierte Version behoben, indem der Upstream-Commit 0ed4268a per Cherry-Pick in das Release 24.22.1 sowie die parallelen Releases übernommen wurde. Entdeckt und gemeldet wurde die Lücke von den Sicherheitsforschern Khai Tran und Sylvie Mayer von OpenAI Codex Security.

Herkömmliche Dependency-Scanner schlagen hier nicht an, da der Decoder Teil der Runtime und kein separates Paket ist. npm install meldete für unser Express-5-Testprojekt 0 Schwachstellen, obwohl es auf einem ungepatchten Node.js 24.15.0 lief.

Wer ist verwundbar?

Eine verwundbare Runtime ist nur die halbe Voraussetzung. Hinzu kommen muss ein Codepfad, über den nicht vertrauenswürdige Brotli-Daten an den Decoder gelangen. Wir haben verschiedene Pfade unter Node.js 24.22.1 getestet, indem wir einen harmlosen ungültigen Request-Body (den Text not-valid-brotli) mit dem Header Content-Encoding: br gesendet sowie gültige Brotli-Daten an die jeweiligen Clients ausgeliefert haben.

Zwei Ergebnisse verdienen einen genaueren Blick: fetch() dekodierte Brotli selbst dann, wenn im Request explizit Accept-Encoding: identity gesetzt war – denn es orientiert sich am Header der Serverantwort, nicht an der Anfrage. Jeder Server, den Ihre Anwendung aufruft, kann somit den Decoder erreichen. Dienste wie Webhook-Tester, Link-Vorschauen oder URL-Importer sind dadurch direkt exponiert. Zudem beweist ein HTTP-Status 400 allein noch nichts: Sowohl Express 5 als auch Standard-Fastify liefern diesen Fehlercode, doch nur Express 5 hat dabei tatsächlich den Decoder ausgeführt. Achten Sie daher genau auf die Fehlermeldung.

Mit folgenden drei Befehlen ermitteln Sie betroffene Pfade:

# Direct decoder use grep -rnE "brotliDecompress|createBrotliDecompress" src/ # Parsers that decode request bodies npm ls express body-parser @koa/bodyparser @fastify/compress # Base images and pinned versions grep -rnE "^FROM .*node" --include='Dockerfile*' . 

Ein einziger neuer fetch()-Aufruf kann die Ausgangslage bereits verändern. „Nicht erreichbar" bedeutet daher trotzdem: unbedingt patchen.

So patchen Sie CVE-2026-111497

Aktualisieren Sie auf den neuesten Build Ihrer Release-Reihe – nicht nur auf die Mindestversion. Über die folgenden Quellen standen am 5. November bereits behobene Versionen bereit:

Schließen Sie anschließend die beiden häufigsten Fallstricke:

• Starten Sie alle Dienste neu. Laufende Prozesse behalten die alte Binärdatei im Arbeitsspeicher. Ein Update auf der Festplatte ändert nichts, solange pm2, systemd oder Ihr Orchestrator den Prozess nicht neu gestartet hat.
• Bauen Sie bereitgestellte Artefakte neu. Bestehende Images behalten die alte Runtime bei. Bei Images, die per Digest fixiert sind, ist ein Image-Scan erforderlich, da das Tag allein keinen Aufschluss gibt.

Führen Sie zum Abschluss die Prüfungen vom Anfang dieses Beitrags innerhalb des deployten Containers sowie auf CI-Runnern und Entwickler-Rechnern durch. Den jeweils neuesten Sicherheits-Build pro Release-Reihe ermitteln Sie mit folgendem Befehl:

curl -s https://nodejs.org/dist/index.json | jq -r '[.[] | select(.security == true and (.version | test("^v(22|24|26)\\.")))] | group_by(.version | split(".")[0]) | .[] | max_by(.date) | "\(.version) \(.date)"' 

Nutzen Sie noch Version 20 oder 25? Für diese existieren keine bereinigten Builds. Lesen Sie den Node.js 20 End-of-Life-Leitfaden und migrieren Sie umgehend.

Node.js-Brotli-Schutzmaßnahmen: Wenn Sie heute nicht patchen können

Diese Maßnahmen verschaffen Zeit, ersetzen das Upgrade jedoch keinesfalls.

1. br am Edge abweisen. Blockieren Sie Content-Encoding: br auf Proxys oder Load-Balancern – unter Berücksichtigung von Groß-/Kleinschreibung sowie Listen wie gzip, br.
2. In der Anwendung abweisen. Fügen Sie folgende Middleware vor Ihren Body-Parsern ein. In unserem Express-5-Test lieferte sie den Status 415 zurück:

app.use((req, res, next) => { const encoding = req.headers['content-encoding'] || ''; if (/\bbr\b/i.test(encoding)) return res.status(415).end(); next(); }); 

1. Dekomprimierung deaktivieren. express.json({ inflate: false }) gab bei derselben Anfrage ebenfalls 415 zurück. Dabei werden allerdings auch mit Gzip komprimierte Bodies abgewiesen – prüfen Sie daher vorab Ihre Clients.
2. Ausgehende Antworten kontrollieren. axios unterstützt decompress: false, wodurch die Daten in unserem Test unkomprimiert blieben. fetch() bietet keinen standardmäßigen Abschaltmechanismus; schränken Sie daher über Allowlisten und Egress-Regeln ein, welche Hosts erreicht werden dürfen.
3. Schadensradius begrenzen. Segmentieren Sie Node.js-Dienste und beschränken Sie den Zugriff auf Core-Dumps, da ELLIO darauf hinweist, dass Abstürze dort Daten aus dem Arbeitsspeicher offenlegen können.

Achten Sie auf verdächtige Muster, wie sie ELLIO zuerst registriert hat: Häufungen von Brotli-komprimierten Request-Bodies, mit denen Angreifer testen, welche Hosts diese dekodieren. Unerwarteter Datenverkehr mit Content-Encoding: br an einer JSON-API oder ein plötzlicher Anstieg von Worker-Abstürzen erfordern eine sofortige Überprüfung.

Sicherstellen, dass Ihre API das Upgrade überstanden hat: Tests per Agent automatisieren

Ein Versionssprung der Runtime kann das Verhalten von TLS, DNS und HTTP verändern – und das Oktober-Release hat alle drei Bereiche berührt. Vergleichen Sie solche Änderungen nicht manuell. Lassen Sie Ihren Coding-Agenten die Apidog CLI vor und nach dem Update ausführen, um Abweichungen automatisch zu erfassen.

npm install -g apidog-cli@latest apidog login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted 

Geben Sie Ihrem Agenten folgenden [REDACTED PROMPT]
Run Apidog test suite in project against staging and save the
results to reports/before. After I upgrade Node.js, add a test case for
POST /orders that sends the plain text "not-valid-brotli" with
Content-Encoding: br, asserts a 4xx status, then checks GET /health
returns 200. Rerun the suite to reports/after and list every request
whose result changed.

 Der Agent führt daraufhin diese Befehle aus: 

bash
apidog run --test-suite --project -e -r cli,junit --out-dir reports/before
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project --file case.json
apidog run --test-case --project -e -r cli,json
apidog run --test-suite --project -e -r cli,junit --out-dir reports/after

 Dieser zusätzliche Testfall ist ein reiner Integritätstest und kein Exploit: Der Body besteht aus reinem Text und schlug in unseren Tests sowohl auf verwundbaren als auch auf behobenen Builds mit demselben Padding-Fehler fehl. Dennoch deckt er ein reales Problem auf: Unser Koa-Test lieferte den Status 500, weil der Dekodierungsfehler nicht abgefangen wurde – eine öffentliche API sollte hier jedoch mit 4xx antworten. Führen Sie diesen Test ausschließlich gegen eine Staging-Umgebung aus. Die [Befehlsreferenz für den Run-Befehl](https://apidog.com/de/blog/apidog-run-command-reference?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) listet sämtliche Flags auf, und der [CI/CD-Leitfaden](https://apidog.com/de/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) zeigt, wie Sie den gleichen JUnit-Durchlauf in Ihre Pipeline einbinden. Der kostenlose Tarif von Apidog umfasst bis zu 4 Benutzer. ## Warum der 11. November als Nächstes wichtig wird Das Node.js-Projekt hat für den 11. November 2026 oder kurz danach bereits [weitere Sicherheits-Releases](https://nodejs.org/en/blog/vulnerability/november-2026-security-releases) für die Versionen 26.x, 24.x und 22.x vorangekündigt – erneut mit HOCH als höchstem Schweregrad. Bislang wurden noch keine CVEs veröffentlicht. In [unserem Leitfaden zum November-Release](https://apidog.com/de/blog/nodejs-november-2026-security-release?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) erfahren Sie, wie Sie sich darauf vorbereiten. Patchen Sie die Brotli-Schwachstelle jetzt, anstatt bis zu diesem Wartungsfenster zu warten. Details zur Lücke sind bereits öffentlich und es gibt aktiven Exploit-Traffic. Zudem dient das Upgrade in dieser Woche als Generalprobe für das nächste: gleiche Bestandsaufnahme, gleicher Rebuild von Images, gleiche Testsuite. Bei [PHP2Shell](https://apidog.com/de/blog/php2shell-php-vulnerability?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) und [React2Shell](https://apidog.com/de/blog/fix-react2shell-exploit?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) verlief die Entwicklung nach demselben Muster. ## FAQ **Wird CVE-2026-111497 bereits ausgenutzt?** Ja. Die CISA hat die Schwachstelle am 27. Oktober 2026 unter Google Brotli in den Katalog bekannter ausgenutzter Schwachstellen (KEV) aufgenommen, und ELLIO hat bereits am 26. Oktober Exploit-Traffic verzeichnet. **Ist die Lücke als „High" oder „Critical" eingestuft?** Beide Einstufungen treffen zu. Node.js stuft sie als HOCH (HIGH) ein. Die NVD bewertet sie im CVSS 3.1 mit 9.8 KRITISCH (CRITICAL), und der von Google vergebene CVSS-4.0-Score liegt bei 9.2. Richten Sie Ihre Maßnahmen danach aus, dass die Lücke aktiv ausgenutzt wird. **Ich verwende Express 4. Bin ich sicher?** Eingehende Request-Bodies erreichen den Decoder zwar nicht, Aufrufe über `fetch()`, axios sowie direkte `node:zlib`-Aufrufe hingegen schon. Zudem wurden mit demselben Release neun weitere CVEs behoben – führen Sie das Upgrade daher in jedem Fall durch. **Ist Node.js 20 betroffen?** Für End-of-Life-Zweige führt das Projekt keine Risikobewertung mehr durch und stellt keine Fixes bereit. Betrachten Sie 20.x und 25.x daher als ungepatcht und unbewertet – migrieren Sie so schnell wie möglich. **Sind neben Node.js noch weitere Systeme betroffen?** Ja. Das [GitHub-Advisory](https://github.com/advisories/GHSA-9v8h-qqgm-4m35) umfasst die PyPI-Pakete `brotli` und `brotlicffi`, und Hersteller melden Patches für Bun 1.4.4 sowie .NET. Aktualisieren Sie jeden Decoder separat, da ein Node.js-Upgrade ausschließlich die eigene integrierte Kopie abdeckt.