Node2Shell und Python2Shell: eine Brotli-Lücke in zwei Ökosystemen

Am 21. Oktober 2026 hat Node.js ein Sicherheitsrelease mit zehn Fixes veröffentlicht. Eines davon, CVE-2026-111497, ist ein Out-of-Bounds-Write im Brotli-Decoder von Google, den Node in die eigene Binary einbindet. Nach Angaben von Node.js erlaubt die Lücke Remote Code Execution.

Die zwei Brotli-Pakete auf PyPI haben am 22. Oktober gepatchte Builds veröffentlicht; einen Tag später hatte die Python-Seite ihren eigenen Namen. Node2Shell, Python2Shell und das später aufgetauchte HTTP2Shell verweisen alle auf dieselbe CVE.

Zwei Angriffsflächen

Was im Decoder passiert

Ein Brotli-Stream besteht aus Blöcken und wechselt im Verlauf zwischen Blocktypen. Der Decoder in älteren Versionen hat einen ungültigen Blockwechsel als “die Eingabe endet zu früh, es fehlen noch Bytes” behandelt statt als Formatfehler. Er ließ den Stream offen und hängte neue Daten an einen internen Puffer an, der acht Bytes fasst.

Genug fehlerhafte Eingabe läuft über diesen Puffer hinaus und beschädigt benachbarten Speicher. Was daraus wird, hängt vom Heap-Layout ab: ein Absturz, ein Leck von Prozessspeicher oder Kontrolle über den Instruction Pointer, die in Codeausführung mündet. Der CVE-Record nennt zwei Schwächen, einen ungeprüften Rückgabewert (CWE-252) und einen Out-of-Bounds-Write (CWE-787). Node.js nennt OpenAI Codex Security, Khai Tran und Sylvie Mayer als Melder.

Google hat den Fix am 27. Februar 2026 im Brotli-Repository committet. Die Commit-Nachricht nannte ihn eine frühere Erkennung ungültiger Streams und erwähnte Sicherheit mit keinem Wort. Die gepatchten Releases 1.0.10, 1.1.1 und 1.2.1 erschienen am 21. Oktober, fast acht Monate später. Googles CVE-Record bewertet die Lücke mit 9,2 nach CVSS v4.0; Node.js stuft das eigene Advisory als High ein. Der betroffene Bereich beginnt bei 1.0.3 aus dem Frühjahr 2018; der Fehler war also über acht Jahre in ausgelieferten Versionen enthalten.

Node2Shell: drei Wege hinein

Brotli-Daten erreichen einen Node-Prozess über Request-Bodies, über Responses, die er abruft, und über direkte Aufrufe der Bibliothek.

Request-Bodies sind der naheliegende Weg. Express 5 bringt body-parser 2 mit, und dessen Parser (express.json(), express.raw() und die übrigen) entpacken standardmäßig Bodies mit Content-Encoding: br. Jeder Client kann dem Decoder beliebige Bytes übergeben, ohne ein Konto zu haben. Express 4 nutzt body-parser 1.x, der Brotli-Bodies mit einem 415-Fehler ablehnt, und ein reiner node:http-Server dekodiert Request-Bodies nicht von sich aus.

Responses bekommen weniger Aufmerksamkeit. fetch() entpackt Brotli automatisch und wählt den Decoder anhand des Response-Headers, unabhängig davon, was Ihr Request angekündigt hat. Eine Antwort von einem Server, den der Angreifer kontrolliert, erreicht den Decoder, bevor irgendein Parsing-Code von Ihnen läuft. Webhook-Zustellungen, URL-Vorschauen, Bild-Proxies und jedes “Holen Sie mir diesen Link”-Feature sind mitbetroffen.

Der dritte Weg ist ein direkter Aufruf von node:zlib, im eigenen Code oder in einer Abhängigkeit. Ein grep findet solche Aufrufe in einer Minute.

Impervas Red Team hat Codeausführung in frischen Containern mit dem offiziellen Node.js-Image 24.22.0 auf Linux arm64 reproduziert, über eine Response, die fetch() verarbeitet, und über Request-Bodies, die Express 5 mit body-parser 2 parst. Der Exploit brauchte mehrere Versuche, 24.22.1 wies dieselbe Eingabe ab, und Imperva hat den Code nicht veröffentlicht.

Öffentliche Repositories erschienen innerhalb von Stunden nach dem Release. Die veröffentlichten Proofs of Concept bringen ungepatchtes Node.js zum Absturz; Remote Code Execution hat bislang kein öffentlicher Code erreicht. CISAs Einschätzung im CVE-Record nannte am 23. Oktober keine Ausnutzung, und die CVE steht nicht in CISAs Known Exploited Vulnerabilities Catalog.

Die gefixten Versionen sind 22.23.4, 24.22.1 und 26.12.1. Bun bindet denselben Decoder ein und hat den Fix in 1.4.4 ausgeliefert. Node.js 25.x, 23.x, 20.x und älter sind End of Life und bekommen keinen.

Ein Image, das auf node:24.22.0 gepinnt ist, bleibt verwundbar, egal wie oft Sie neu bauen. Ziehen Sie zuerst den Pin nach.

Python2Shell: derselbe Fehler, einen Tag später

Kein CPython-Interpreter ist hier verwundbar. Googles Brotli-Binding und die CFFI-Alternative brotlicffi kompilieren denselben C-Decoder in ein Extension-Modul. Beide Projekte haben am 22. Oktober gepatchte Builds auf PyPI hochgeladen: Brotli 1.2.1 und brotlicffi 1.2.1.0. Das Changelog von brotlicffi nennt die CVE, ebenso Googles Release Notes zu 1.2.1. Die Projektseite von Brotli auf PyPI nennt sie nicht; ein Blick auf PyPI verrät Ihnen also nichts über den Fix.

Die Betroffenheit wandert mit den HTTP-Clients. Ist Brotli oder brotlicffi installiert, kündigt urllib3 Brotli-Unterstützung an und entpackt, was zurückkommt; requests erbt das über urllib3. httpx mit dem brotli-Extra, aiohttp und Scrapy verhalten sich genauso. Ihr Code muss das Paket nie importieren. urllib3 entpackt eine Brotli-Response auch dann, wenn der Request Accept-Encoding: identity gesendet hat, weil es den Response-Header liest. Ein Python-Dienst, der Seiten, Bilder oder Webhooks von Servern abruft, die Sie nicht kontrollieren, reicht Angreiferdaten an den Decoder weiter.

Etwa einen Tag lang stand keines der beiden Pakete in den Advisory-Datenbanken, die Scanner auslesen; ein sauberer Report bewies also nichts. Am 23. Oktober hat GitHub beide Pakete zu GHSA-9v8h-qqgm-4m35 hinzugefügt, PYSEC-2026-4322 (Brotli) und PYSEC-2026-4323 (brotlicffi) folgten. pip-audit markiert verwundbare Versionen jetzt.

Das Update ist pip install -U "Brotli>=1.2.1" "brotlicffi>=1.2.1.0", danach ein Rebuild jedes Images oder Wheels, das die Pakete enthält. Bei Poetry, uv oder pip-tools heben Sie die Versionsgrenze an und erzeugen das Lockfile neu.

Wo ein Deploy heute nicht möglich ist, entfernt das Deinstallieren beider Pakete den verwundbaren Decoder. Die HTTP-Clients behalten gzip und deflate, aber ein Server, der nur in Brotli antwortet, liefert einen Body, den Ihr Code nicht lesen kann. Achten Sie auf Extras wie httpx[brotli], die das Paket beim nächsten Build wieder installieren.

Python aus einem Distributionspaket bekommt den Fix unter Umständen als Systemupdate von libbrotli statt als pip-Release. Prüfen Sie, wogegen der Interpreter linkt, bevor Sie die Sache für erledigt halten.

Derselbe Decoder anderswo

Jedes Produkt, das eine eigene Kopie von Brotli mitbringt, muss einen eigenen Fix ausliefern. Bun hat das in 1.4.4 getan. Envoy hat den Fehler in 1.40.0, 1.39.3, 1.38.6 und 1.37.8 behoben, Istio in 1.29.9, 1.30.6 und 1.31.2. curl-Builds, die gegen Brotli gelinkt sind, entpacken es mit --compressed, und Git-Builds, deren libcurl Brotli unterstützt, fordern es bei HTTPS-Fetches an. Git for Windows 2.56.0.windows.3 brachte am 24. Oktober noch Brotli 1.2.0 mit.

Unter Debian linken Node.js- und Python-Pakete aus der Distribution gegen die System-Brotli-Bibliothek; der Fix kommt dort über das Paket brotli: 1.0.9-2+deb12u1 für Bookworm und 1.1.0-2+deb13u1 für Trixie.

Warum die Scanner still blieben

Der Fehler sitzt in einer nativen Bibliothek unterhalb Ihrer Anwendung. Statische Analyse liest Ihren Quellcode, Dependency-Scanner lesen Manifeste und Lockfiles. Keiner von beiden sieht einen Decoder, der in eine Node-Binary oder ein Python-Wheel kompiliert ist.

Ein gewöhnlicher Request erreicht den Decoder. Wenn der Body-Parser global eingehängt ist, wie meistens, läuft der verwundbare Code vor Ihrem Route-Handler und Ihrer Authentifizierungs-Middleware.

Die Behebung ist ein Versionssprung plus Neustart oder Rebuild. Anwendungscode ändert sich nicht, was den Fix einfach aussehen lässt, bis Sie belegen müssen, dass der Prozess, der den Traffic beantwortet, die neue Version fährt.

Google hat die Änderung im Februar committet und die Releases im Oktober veröffentlicht. Ein Commit im Repository ändert nichts an bereits ausgerollten Binaries, und acht Monate lang hat kein Advisory darauf gezeigt.

Die Prüfung in zehn Minuten

Lesen Sie die Version aus der Binary, die in der Produktion läuft. Ein Manifest sagt Ihnen nur, was jemand ausrollen wollte.

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

Vergleichen Sie die erste Zeile mit 22.23.4, 24.22.1 und 26.12.1. Die zweite Zeile liefert auf einem gepatchten Build -17 und auf einem verwundbaren undefined, weil der Fix diesen Fehlercode ergänzt hat.

Lassen Sie process.versions.brotli dafür weg. Node.js hat den Upstream-Commit übernommen, ohne die eingebundene Version zu erhöhen; ein gepatchtes Node 22.23.4 meldet weiterhin 1.1.0, ein gepatchtes Node 24.22.1 weiterhin 1.2.0. Die Zeichenkette sieht vorher und nachher gleich aus.

In Containern führen Sie dieselben Befehle gegen das Image aus, das Sie ausrollen:

docker run --rm --entrypoint node <image> --version
docker run --rm --entrypoint node <image> -p "require('zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH"

Node.js aus der Distribution linkt unter Umständen gegen die System-Brotli-Bibliothek. Dann kommt der Decoder-Fix mit dem brotli-Paket der Distribution, und die Node-Versionsnummer sagt Ihnen nichts darüber:

ldd "$(command -v node)" | grep -i brotli

Für den Request-Body-Pfad:

npm ls express body-parser
grep -rnE "express\.json|express\.raw|bodyParser|brotliDecompress|createBrotliDecompress" --include=*.js --include=*.mjs --include=*.ts .

Für Python fragen Sie den Interpreter, der den Produktions-Traffic bedient:

python -c "import brotli; print(brotli.__version__)"
python -c "import brotlicffi; print(brotlicffi.__version__)"
pip show Brotli brotlicffi
pipdeptree -r -p Brotli
pip-audit

Ein ImportError bei einem der Importe bedeutet, dass das Paket in dieser Umgebung nicht installiert ist. pipdeptree zeigt, welche Abhängigkeit Brotli hereingezogen hat.

Wenn die Prüfung einen Host findet, den Sie diese Woche nicht patchen können, oder Sie nicht sagen können, welche Laufzeit ein Dienst fährt, vereinbaren Sie ein kostenloses 30-Minuten-Gespräch. Wir gehen die Ergebnisse mit Ihnen durch und sortieren die Hosts danach, wie stark sie ausgesetzt sind.

Was DevOps diese Woche tun sollten

Patchen Sie in der Reihenfolge der Betroffenheit. Internetzugewandte Dienste, die Brotli aus nicht vertrauenswürdigen Quellen dekodieren, kommen zuerst, dann API-Gateways und Reverse Proxies, die Kompression terminieren, dann alles, was im Namen von Nutzern URLs abruft. Interne Batch-Jobs kommen zuletzt.

Ziehen Sie Image-Tags nach und bauen Sie neu. Ein Rebuild, der einen gecachten Layer mit der alten Laufzeit wiederverwendet, ändert nichts; prüfen Sie die Version im neuen Image, bevor es in eine Registry geht.

Starten Sie den Prozess neu. Ein gepatchtes Paket auf dem Host aktualisiert keinen Container, der letzte Woche gestartet ist, und Node behält den verwundbaren Decoder im Speicher, bis der Prozess endet.

Bestätigen Sie die laufende Version auf der ausgerollten Instanz statt auf Ihrem Laptop, mit demselben Einzeiler.

Wenn das Upgrade heute nicht landet, senken Sie das Risiko, während Sie es planen. Weisen Sie Content-Encoding: br am Edge ab, ohne Rücksicht auf Groß- und Kleinschreibung, und auch dann, wenn br in einer Liste wie gzip, br steht. In Express verweigert express.json({ inflate: false }) komprimierte Bodies bis zum Upgrade; die Option weist auch gzip-Bodies ab, also testen Sie zuerst Ihre Clients. Mehrere WAF- und Hosting-Anbieter haben Regeln für diese CVE ausgeliefert, und die decken nur eingehenden Traffic ab.

Ausgehende Aufrufe brauchen einen anderen Fix. br aus Accept-Encoding zu entfernen hilft nicht, weil fetch(), urllib3 und curl dekodieren, was der Response-Header ankündigt. Leiten Sie ausgehenden Traffic über einen Egress-Proxy, der Responses mit Content-Encoding: br ablehnt, oder schalten Sie das Dekodieren ab, wo der Client es erlaubt, wie urllib3 mit decode_content=False. Für Python ist das Deinstallieren der beiden Pakete schneller als eine Proxy-Änderung und kostet etwas Bandbreite. Jede dieser Maßnahmen kauft ein paar Tage; das Upgrade muss trotzdem folgen.

Was SecOps diese Woche tun sollten

Kontrollieren Sie zuerst den Edge. Eine Regel auf Content-Encoding: br kostet eine Konfigurationszeile und hält, bis das Laufzeit-Upgrade landet. Testen Sie sie gegen legitime Clients, bevor Sie die Regel auf Blockieren stellen, weil manche SDKs und Mobile-Apps Brotli-Bodies senden.

Beschränken Sie den Egress von Anwendungsservern. Ein kompromittierter Prozess, der keine zweite Stufe nachladen und keinen Tunnel öffnen kann, ist für einen Angreifer deutlich weniger wert. Eine Allowlist bricht Hobbyprojekte; zu den meisten Produktionsdiensten passt sie.

Härten Sie den Prozess, denn die Ausnutzung landet in einem Web-Worker oder einem Python-Interpreter. Container laufen als Non-Root mit read-only Root-Dateisystem, ohne Linux-Capabilities, mit Seccomp-Profil und ohne Shell im Image. Nichts davon verhindert die Speicherbeschädigung, aber alle zusammen verteuern jeden Schritt danach.

Achten Sie dann auf Verhalten, das einem erfolgreichen Treffer folgt:

Kein einzelnes Signal beweist eine Ausnutzung. Korrelieren Sie sie mit der ausgerollten Laufzeitversion und mit der Quelle des komprimierten Traffics.

Setzen Sie Fristen nach Betroffenheit, nicht nach Score:

Eine weitere Regel für diese Woche: Führen Sie keine Binaries aus, die unter dem Namen einer Sicherheitslücke ankommen. Gefälschte Scanner und Proof-of-Concept-Archive verbreiten sich mit jeder prominenten Lücke. Holen Sie Werkzeuge von der Node.js-Release-Seite, von PyPI oder aus dem Repository des Projekts.

Was die DSGVO ergänzt

Läuft Angreifercode in einem Prozess, der personenbezogene Daten verarbeitet, behandeln Sie den Vorfall als mögliche Verletzung des Schutzes personenbezogener Daten. Artikel 33 DSGVO verlangt die Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Artikel 32 verlangt Maßnahmen, die dem Risiko angemessen sind und den Stand der Technik berücksichtigen. Sobald ein Fix für eine Lücke mit Codeausführung öffentlich ist, lässt sich der Betrieb des alten Builds schwer begründen.

Halten Sie fest, wann Sie welches System gepatcht haben und warum eines davon gewartet hat. Dieser Nachweis beantwortet die erste Frage, die Ihr Datenschutzbeauftragter oder ein Auditor stellt. Die rechtliche Bewertung nimmt Ihr Datenschutzbeauftragter vor; dieser Abschnitt ist keine Rechtsberatung.

Was kontinuierliche Überwachung abdecken muss

Ein Quartalsscan beantwortet die Frage, ob Sie im März verwundbar waren. Diese Lücke verlangte eine Antwort in derselben Woche, und der Fix lag seit Februar im Upstream-Repository.

Kontinuierliche Überwachung besteht aus vier Bausteinen. Das Inventar muss Images, Hosts und CI-Runner abdecken, weil ein Lockfile nicht sagt, welche Laufzeit den Traffic beantwortet. Die Betroffenheitsanalyse hält fest, welche Dienste komprimierte Daten von außen annehmen oder abrufen. Die Prüfung nach jedem Deploy macht aus der laufenden Version eine Tatsache. Drift-Erkennung auf Base-Image-Tags fängt den Pin ab, den niemand nachgezogen hat.

Außerdem muss jemand die Quell-Advisories lesen. Node.js veröffentlicht auf der Mailingliste nodejs-sec, Python-Pakete landen in PYSEC und OSV, teils einen Tag nach dem Release. Wenn Ihr einziger Input ein Scanner-Dashboard ist, erfahren Sie von der nächsten Lücke zu spät.

Was wir übernehmen

Wir behalten die Laufzeiten unserer Kunden im Blick. Unsere Supportverträge decken Patch-Management für Ihren Stack ab, Node.js, Python und PHP eingeschlossen, dazu Monitoring der Dienste, die davon abhängen, und die Prüfung, ob Backups tatsächlich zurückspielbar sind. Für den Tag, an dem ein Release wie dieses landet, gibt es ein schriftliches Vorgehen. Jeder Patch bekommt Datum und Begründung im Log, und genau dieser Nachweis gehört in Ihre DSGVO-Dokumentation.

Dienste in Go, Java, Ruby und .NET bekommen dieselbe Behandlung in drei Schritten: erfassen, was den Traffic beantwortet; mit dem gefixten Release vergleichen; den Fix am laufenden Prozess belegen.

Wenn Sie nicht sicher sind, welche Ihrer Server einen betroffenen Build fahren, vereinbaren Sie ein kostenloses 30-Minuten-Gespräch. Wir gehen die Laufzeiten auf Ihren Servern mit Ihnen durch, in welcher Sprache sie auch geschrieben sind, sagen Ihnen, welche exponiert sind und was zuerst gepatcht wird. Ein Inventar müssen Sie nicht vorab schicken; eine grobe Zahl an Servern und Diensten reicht für den Anfang. Wie wir arbeiten, steht auf unserer Leistungsseite.

Quellen

• Node.js: Security Releases vom 21. Oktober 2026
• Node.js v24.22.1 Release Notes (Brotli-Cherry-Pick)
• CVE-Record CVE-2026-111497 (Google, CNA)
• GitHub Advisory GHSA-9v8h-qqgm-4m35
• OSV: PYSEC-2026-4323 (brotlicffi)
• Google Brotli v1.2.1 Release
• brotlicffi auf PyPI (Changelog zu 1.2.1.0)
• Imperva: Node2Shell, From Brotli Data to Remote Code Execution
• Debian Security Tracker: CVE-2026-111497
• expressjs/body-parser README (Option inflate)