HTTP2Shell ist kein HTTP/2-Fehler – und genau das ist beunruhigend

Ihr Team hat vermutlich eine Liste der Frameworks, von denen es abhängt. Gibt es auch eine Liste der Dekompressoren? HTTP2Shell ist einer der Namen, die inzwischen für eine Schwachstelle zur Remote-Codeausführung kursieren, die Node.js und laut Berichten auch Python-Bibliotheken betrifft. Trotz des Namens ist nicht das Protokoll schuld, sondern ein Kompressionsdecoder.

Der Fehler steckt im Dekompressor, nicht im Protokoll

Wie Brandefense erläutert, handelt es sich um eine einzelne Schwachstelle, CVE-2026-111497, im Brotli-Decoder, den Node.js mitliefert. Zunächst hieß sie Node2Shell, seit dem späten 23. Oktober (UTC) auch HTTP2Shell. Node.js behob sie am 21. Oktober 2026 in den Versionen 22.23.4, 24.22.1 und 26.12.1. Der CVE-Eintrag stuft sie mit 9,2 nach CVSS 4.0 ein. Laut Advisory geht die Meldung auf OpenAI Codex Security zurück.

Aikido zufolge betrifft dieselbe Brotli-Lücke viele Bibliotheken und Anwendungen, die HTTP mit installiertem Brotli oder brotlicffi nutzen. Remote-Codeausführung im offiziellen Node.js-24.22.0-Image ist bislang das, was Forscher gemeldet haben. Aikido stellt das als Meldung dar, nicht als eigenen Test, und fügt hinzu, der Exploit habe nicht jedes Mal funktioniert. Öffentlicher Proof-of-Concept-Code bringt ungepatchtes Node.js Berichten zufolge zum Absturz, eine funktionierende RCE wurde in öffentlichem Code aber nicht gezeigt. Unserer Ansicht nach ändert diese Unterscheidung, wie laut man die Lücke beschreiben sollte. Sie ändert nicht, wie schnell man patchen sollte.

Der falsche Name weist auf die falsche Schicht

Den Namen HTTP2Shell kann man nachvollziehen. Die Lücke zeigt sich auf dem HTTP-Pfad, und der Name ist eingängig. Er lenkt aber auf die falsche Schicht. Niemand sollte nach einer HTTP/2-Einstellung suchen, die sich abschalten ließe.

Die Analyse von Brandefense, die die Erklärung von Vercel wiedergibt, zeigt, wie gewöhnlich die Angriffsfläche ist. Node.js dekodiert Brotli nicht von sich aus. Eine App ist angreifbar, wenn ihr eigener Code oder eine genutzte Bibliothek Brotli-Daten dekomprimiert, die ein Angreifer kontrolliert. Der Forscher Ron Masas schrieb auf X, bei einer verwundbaren Runtime genüge „app.use(express.json)“. Brandefense zufolge deckt sich das mit dem Quellcode von Express 5. Eine JSON-Anfrage mit Brotli als Content-Encoding wird dekodiert, bevor Ihr Routen-Code läuft.

Das ist der unbequeme Teil. In vielen Teams, vermuten wir, hat niemand eine Brotli-Funktion geschrieben und niemand eine geprüft. Die Angriffsfläche kam als Standardverhalten von etwas, das man bewusst gewählt hat. Zudem weist Brandefense darauf hin, dass auch andere Middleware, Frameworks, Reverse-Proxys und eigener Code Brotli dekodieren können. Jede dieser Stellen gehört geprüft.

Patchen muss Infrastrukturarbeit werden, kein Sprint-Ticket

Der Zeitablauf ist das Argument. Node.js veröffentlichte die Korrekturen am 21. Oktober um 10:38 Uhr UTC. Laut Brandefense tauchte das erste GitHub-Repository zur CVE rund fünf Stunden später auf, und bis zum späten 23. Oktober lieferte eine Suche 25 Treffer. Unserer Ansicht nach haben Verteidiger keine Schonfrist, sobald sich Patches mit dem alten Code vergleichen lassen.

Am selben Tag veröffentlichte PHP eigene Korrekturen für die separaten PHP2Shell-Lücken. Das Sicherheitsteam der University of Toronto warnt, dass rasch mit Massenausnutzung zu rechnen sei und Cloudflare bereits erste Angriffe gemeldet habe. Wir wollen zwei voneinander unabhängige Fehler nicht zu einer Geschichte verschmelzen. Aber zwei kritische Runtime-Lücken zugleich zeigen, wie eine schlechte Woche aussieht, wenn so viel auf wenigen gemeinsamen Runtimes läuft.

Eine zweite Lehre betrifft Software am Ende ihres Lebenszyklus. Brandefense zitiert Vercel mit der Aussage, Node.js 20 „wird diese Korrektur nicht erhalten“. Teams, die auf einer nicht mehr unterstützten Runtime festsitzen, sind nicht einen Patch im Rückstand. Sie haben gar keinen Patch, den sie einspielen könnten. Eine Budgetentscheidung von vor Monaten wird an einem Wochenende fällig.

Wiz argumentiert in seiner PHP2Shell-Analyse, dass Frontier-KI-Modelle es ermöglichten, funktionierende Exploits in Stunden zu entwickeln und anzupassen. Wir würden das als ernst zu nehmende Behauptung behandeln, nicht als gesicherte Tatsache. Hält sie stand, wird der alte Trost schwächer, eine Lücke sei zu komplex, als dass jemand sie ausnutzen könnte.

Aufgabe für Montag: inventarisieren, aktualisieren, Verantwortliche benennen

Unsere Empfehlung ist schlicht. Prüfen Sie Ihre Versionen mit node --version und finden Sie jede Stelle, an der Ihr Code oder eine Abhängigkeit Brotli von außen dekomprimiert. Aktualisieren Sie auf die korrigierten Versionen und verlassen Sie Node.js 20. Führen Sie Proof-of-Concept-Code von GitHub nicht außerhalb eines isolierten Labors aus, denn Exploit-Code von unbekannten Konten kann Malware enthalten.

Die größere Veränderung ist organisatorisch. Updates für Runtimes und Bibliotheken sollten nicht in einem Backlog hinter der Feature-Arbeit warten. Sie brauchen eine verantwortliche Person, ein Inventar und eine Frist innerhalb derselben Woche. Eine Lücke wie diese wird nicht die letzte sein, und wir meinen, dass die Teams, die sie als routinemäßige Infrastrukturwartung behandeln, die nächste kaum bemerken werden.