Node2Shell: Welche Programme und Server wegen der Brotli-Lücke Updates brauchen

Sicherheit · Brotli-Lücke CVE-2026-111497 · Stand 26. Oktober 2026

Node2Shell: Welche Programme und Server jetzt Updates brauchen

Eine Lücke im Brotli-Decoder von Google steckt in Node.js, Bun, Python-Paketen, .NET, Proxys und Dutzenden eingebetteten Kopien. Unter Spitznamen wie Node2Shell und HTTP2Shell kursiert sie seit dem 22. Oktober. Hier steht, welche Versionen sicher sind, wie du deine Node.js-Version prüfst und was Privatnutzer, Entwickler und Admins jetzt konkret tun sollten.

• Node.js sicher ab 22.23.4, 24.22.1 und 26.12.1
• CVSS 9.2 „kritisch“ nach CVSS 4.0, Node.js stuft „hoch“ ein
• Keine Angriffe bekannt, Laborexploit existiert

Node-Version prüfen Zur Update-Matrix

Wer Node.js auf einem Server, im Container oder auf dem Entwicklungsrechner betreibt, sollte auf 22.23.4, 24.22.1 oder 26.12.1 aktualisieren – ältere Hauptversionen wie Node.js 20 bekommen keinen Fix mehr. Hinter dem Schlagwort Node2Shell steckt die Schwachstelle CVE-2026-111497: ein Schreibzugriff außerhalb des vorgesehenen Speicherbereichs im Brotli-Decoder von Google. Node.js hat die Lücke am 21. Oktober 2026 bestätigt und geschlossen, am selben Tag erschienen die korrigierten Brotli-Versionen 1.0.10, 1.1.1 und 1.2.1. Weil die Bibliothek in sehr vielen Programmen steckt, betrifft das Problem aber weit mehr als Node.js.

Dieser Beitrag ordnet ein, was die Lücke technisch bedeutet, wie gefährlich sie nach heutigem Stand ist und welche Software konkret Updates braucht – von Node.js über Bun, Python, .NET und Envoy bis zu Electron-Apps wie VS Code. Mit Versionsprüfung zum Eintippen, Update-Matrix, Rollen-Wegweiser und einer Checkliste für Admins. Und weil der Name zum Verwechseln einlädt: Mit der PHP-Lücke PHP2Shell, die ebenfalls am 21. Oktober bekannt wurde, hat Node2Shell technisch nichts zu tun.

Stand: 26. Oktober 2026, 17:30 Uhr. Datenbasis: Sicherheitsbeitrag von Node.js (21.10.), Brotli-Releases und GitHub-Advisory, Sicherheitstracker von Debian, Ubuntu und Red Hat, Berichte von Sicherheitsfirmen und Fachmedien. Die NVD- und Microsoft-Seiten waren bei Redaktionsschluss nicht direkt abrufbar, eine Warnung von BSI oder CERT-Bund haben wir nicht gefunden. Wir aktualisieren den Beitrag, sobald neue Herstellerangaben vorliegen.

Node2Shell: Das Wichtigste in 20 Sekunden

Was ist Node2Shell? Die Lücke im Brotli-Decoder

Node2Shell ist ein inoffizieller Spitzname für CVE-2026-111497, einen Out-of-Bounds-Write im Brotli-Decoder von Google. Brotli ist ein Kompressionsverfahren, das Webserver und Anwendungen nutzen, um HTML, CSS, JavaScript und API-Antworten zu verkleinern. Erkennbar ist es am Kürzel br im HTTP-Header Content-Encoding. Fast jeder Browser, viele Webserver und zahlreiche Programmiersprachen bringen einen Brotli-Decoder mit – häufig als Kopie der C-Bibliothek von Google.

Genau diese Bibliothek ist fehlerhaft. Betroffen sind laut den Brotli-Releases auf GitHub die Versionen 1.0.3 bis 1.2.0, behoben ist der Fehler in 1.0.10, 1.1.1 und 1.2.1. Der Fehler liegt in der Datei c/dec/decode.c und damit nicht im eigentlichen Code von Node.js. Node.js ist nur das prominenteste Programm, das die Bibliothek mitliefert – daher der Name, der sich nach einer Exploit-Demonstration durchgesetzt hat.

Node.js beschreibt die Lücke in seinem Sicherheitsbeitrag vom 21. Oktober 2026 als Schreibzugriff außerhalb der Grenzen im mitgelieferten Brotli-Decoder, der bis zur Ausführung von Schadcode aus der Ferne führen kann. Die Brotli-Lücke war eine von zehn Schwachstellen in diesem Sammel-Update, vier davon stufte Node.js als „hoch“ ein. Gefunden haben sie laut Node.js Khai Tran und Sylvie Mayer von OpenAI Codex Security, den Fix für Node.js schrieben Matteo Collina und Antoine du Hamel.

Einordnung: Dass eine einzelne C-Bibliothek so breit wirkt, ist typisch für Kompressions- und Parser-Code. Er wird selten neu geschrieben, sondern kopiert und in andere Projekte eingebettet. Genau das macht die Aufräumarbeit mühsam: Ein Systemupdate des Pakets libbrotli repariert nur Programme, die diese Systembibliothek tatsächlich nutzen. Programme mit eigener, eingebauter Kopie – darunter die offiziellen Node.js-Binärdateien – brauchen ein eigenes Update.

Was technisch passiert und wann ein Angriff möglich ist

Der Decoder behandelt einen ungültigen Datenstrom als „unvollständig“ statt als Fehler – und schreibt dann über einen kleinen Puffer hinaus. Laut Node.js erkennt der Streaming-Decoder einen ungültigen sogenannten Block-Switch nicht als Formatfehler, sondern als Signal, dass weitere Eingabedaten nötig sind. Daraufhin hängt er weitere Bytes an einen internen Puffer von nur acht Byte an. Das Ergebnis ist eine Speicherkorruption. Mögliche Folgen nennt Node.js gleich drei: Absturz des Prozesses, Offenlegung von Prozessspeicher und im ungünstigsten Fall Ausführung von Schadcode.

Entscheidend für das Risiko ist eine Bedingung: Die Anwendung muss Brotli-Daten aus einer nicht vertrauenswürdigen Quelle dekomprimieren. Darauf weist auch Red Hat hin. In Node.js gibt es laut den Analysen von Hadrian, Aikido und weiteren Sicherheitsfirmen drei typische Wege, auf denen das passiert:

Nicht automatisch betroffen ist dagegen ein schlichter Server mit http.createServer(): Er entpackt eingehende Request-Bodies nicht von sich aus. Auch reine Webseiten, die Brotli nur zum Komprimieren ihrer Auslieferung nutzen, sind nicht das Ziel – gefährlich ist das Entpacken. Einen offiziellen Workaround nennt Node.js nicht; als Behelf bleibt nur, fremde Brotli-Eingaben abzulehnen oder zu isolieren.

Unsere Einschätzung: Die Bedingung „fremde Brotli-Daten werden entpackt“ klingt nach Spezialfall, ist in der Praxis aber verbreitet. Fast jede moderne Node.js-Anwendung ruft irgendwo externe Adressen mit fetch() ab. Wie leicht sich daraus tatsächlich Codeausführung machen lässt, ist eine andere Frage – dazu der nächste Abschnitt.

Wie gefährlich ist Node2Shell? Bewertungen und Ausnutzung

Die Bewertungen reichen von „kritisch“ bis „mittel“ – je nachdem, wer bewertet und wie schwer die Ausnutzung eingeschätzt wird. Im GitHub-Advisory GHSA-9v8h-qqgm-4m35 steht die Bewertung von Google: 9.2 Punkte nach CVSS 4.0, also „kritisch“. Node.js selbst spricht von „hoch“. Red Hat kommt in seiner CVE-Einordnung auf 8.1 Punkte nach CVSS 3.1 („Important“) und setzt die Angriffskomplexität hoch an.

Die Unterschiede erklären sich aus verschiedenen Bewertungssystemen und daraus, wie schwer man die Ausnutzung einschätzt. Für die Praxis ist wichtiger, was bisher tatsächlich gezeigt wurde. Laut Berichten von HeroDevs und Hadrian demonstrierte das Imperva Red Team die Ausführung von Schadcode auf dem offiziellen Node.js-24.22.0-Image unter Linux für ARM64 – über fetch() und über Express 5 mit body-parser 2.x. Der Exploit ist nicht veröffentlicht und brauchte mehrere Versuche. Ein öffentlicher Proof of Concept auf GitHub erreicht Codeausführung nur auf einem absichtlich geschwächten Build, auf einem Standard-Build reicht er für Absturz und begrenztes Auslesen von Speicher.

Mit Zahlen zur Verbreitung werben vor allem Sicherheitsanbieter. Wiz meldet, 91 Prozent der von ihm beobachteten Cloud-Umgebungen enthielten verwundbare Ressourcen. Qualys berichtet in seinem Blogbeitrag vom 23. Oktober von Millionen Node.js-Installationen bei seinen Kunden, ein großer Teil davon auf Versionen ohne Support. Beide Werte beziehen sich auf die eigene Kundschaft und sind nicht repräsentativ; die Teilsummen bei Qualys passen zudem nicht ganz zur genannten Gesamtzahl.

Unsere Einschätzung: Kein Grund zur Panik, aber auch keiner zum Aufschieben. Ein öffentlich erreichbarer Node.js-Dienst, der Brotli von außen entpackt, sollte in dieser Woche aktualisiert werden. Erfahrungsgemäß werden Exploits für Lücken mit solcher Verbreitung zuverlässiger, sobald mehr technische Details öffentlich sind – und mehrere Analysen samt Upstream-Commit liegen bereits offen.

Node2Shell, HTTP2Shell, Brotli2Shell – und was ist PHP2Shell?

Alle „2Shell“-Namen rund um Brotli meinen dieselbe Lücke CVE-2026-111497 – offiziell ist keiner davon. Node.js verwendet in seinem Sicherheitsbeitrag keinen Spitznamen. Die Namen stammen von Sicherheitsforschern, die damit jeweils einen anderen Aspekt betonen wollten:

„HTTP2Shell“ soll deutlich machen, dass nicht nur Node.js betroffen ist, sondern jede HTTP-Software, die Brotli-Antworten oder -Uploads automatisch entpackt – Python-Clients, curl oder Proxys. Die Benennung nach dem Muster „X2Shell“ ist inzwischen eine Mode für Lücken, die bis zur Codeausführung reichen; 2025 machte etwa React2Shell Schlagzeilen.

Für Verwirrung sorgt, dass am selben 21. Oktober auch PHP2Shell bekannt wurde. Das sind zwei andere Lücken (CVE-2026-109618 und CVE-2026-109619) in der PHP-Laufzeit, zu denen das BSI informiert hat und die PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen. Mit Brotli haben sie nichts zu tun – gemeinsam ist nur das Datum. Wer eine WordPress-Seite mit PHP betreibt und daneben Node.js für Build-Prozesse nutzt, braucht also zwei getrennte Updates. Die PHP-Extension brotli ist allerdings ein eigener Fall: Sie bettet die Brotli-Bibliothek ein und ist in Version 0.21.1 gefixt.

Chronik: Von der stillen Korrektur zum Patchday

Der eigentliche Fehler wurde im Brotli-Code schon im Februar 2026 korrigiert – nur wusste damals niemand, dass es eine Sicherheitslücke war. Laut JFrog und SecurityWeek landete am 27. Februar eine Änderung mit dem Titel „Detect and report invalid stream earlier“ im Brotli-Repository, ohne Sicherheitskennzeichnung. Erst die Meldung von OpenAI Codex Security machte die Tragweite klar.

1. 27.02.2026Stille Korrektur im Brotli-CodeEine Änderung zur früheren Erkennung ungültiger Datenströme behebt die Ursache, ohne als Sicherheitsfix markiert zu sein.
2. 21.10.2026Node.js und Brotli veröffentlichen FixesNode.js 22.23.4, 24.22.1, 26.12.1 und Brotli 1.0.10, 1.1.1, 1.2.1 erscheinen; Vercel ergänzt WAF-Regeln.
3. 22.10.2026CVE öffentlich, Exploit-DemoNVD-Eintrag und GitHub-Advisory, Imperva zeigt Codeausführung, ein öffentlicher PoC erscheint, Python Brotli 1.2.1 und aktualisierte AWS-Lambda-Images folgen.
4. 23.10.2026„HTTP2Shell“ und weitere Paketebrotlicffi 1.2.1.0 und der Go-Port werden gefixt, Forscher betonen die Breite über Node.js hinaus.
5. 24.10.2026Ruby, PHP, Amazon LinuxRuby-Gem brotli 0.9.1, PHP-Extension 0.21.1 und Pakete für Amazon Linux 2023 erscheinen.
6. 25.10.2026Microsoft und Cloudflare ziehen nach.NET 8.0.33, 9.0.22, 10.0.14, Updates für Visual Studio und PowerShell; Cloudflare aktiviert eine WAF-Notfallregel.
7. offenElectron und eingebettete KopienKein stabiles Electron-Release mit Fix gefunden; DuckDB, Arrow, 7-Zip-Varianten und andere Projekte mit eigener Kopie sind teils noch offen.

Einordnung: Die Zeitachse zeigt ein bekanntes Muster. Der Upstream-Fix ist da, die großen Plattformen liefern innerhalb von Tagen – und dann beginnt die lange Phase, in der eingebettete Kopien in Apps, Datenbanken und Werkzeugen nachgezogen werden müssen. Diese Phase dauert erfahrungsgemäß Wochen bis Monate.

Welche Node.js-Versionen sind sicher?

Sicher sind Node.js 22.23.4, 24.22.1 und 26.12.1 sowie alle neueren Versionen dieser Linien. Alles darunter in diesen drei Hauptversionen ist verwundbar. Für Hauptversionen, die das Ende ihres Supports erreicht haben, veröffentlicht Node.js keinen Fix.

Für Node.js 20 und 18 hat der Anbieter HeroDevs laut eigenem Blog kommerzielle Sicherheitsupdates angekündigt. Das ist eine Option für Firmen, die nicht kurzfristig migrieren können, ersetzt aber keinen Plan für den Umstieg. Wer neu aufsetzt, nimmt die LTS-Version 24.

Ein Sonderfall sind Linux-Distributionen. Debian baut sein Node.js-Paket gegen die Systembibliothek libbrotli; dort genügt laut Debian Security Tracker das Update des Brotli-Pakets – Debian 12 bekommt Version 1.0.9-2+deb12u1, Debian 13 Version 1.1.0-2+deb13u1. Wichtig: Debian 12 meldet weiterhin Brotli 1.0.9, also eine Versionsnummer im betroffenen Bereich. Der Fix ist dort rückportiert, die Versionsnummer allein sagt deshalb nichts über den Patch-Stand aus. Die offiziellen Node.js-Downloads bringen Brotli dagegen selbst mit; hier hilft nur das Node.js-Update.

Node.js prüfen und aktualisieren: Schritt für Schritt

Die schnellste Prüfung ist ein Befehl im Terminal: node -v. Danach kommt die eigentliche Arbeit – denn auf vielen Rechnern und Servern liegen mehrere Node.js-Installationen nebeneinander.

Ein Hinweis, den viele Teams übersehen: npm audit findet die Lücke nicht. Das Werkzeug prüft npm-Pakete, die Brotli-Lücke steckt aber in der Laufzeitumgebung selbst. Qualys weist ausdrücklich darauf hin, dass Abhängigkeitsprüfungen solche eingebetteten Kopien übersehen. Ein grünes Audit-Ergebnis ist also kein Beleg für Sicherheit.

Die Befehle für Paketmanager wie winget oder Homebrew unterscheiden sich je nach Installation. Prüfe nach jedem Update erneut mit node -v, welche Version tatsächlich aktiv ist – gerade unter Windows gewinnt oft eine ältere Installation im Suchpfad.

Update-Matrix: Welche Programme und Server Updates brauchen

Neben Node.js brauchen vor allem Bun, Python-Pakete, .NET, Proxys wie Envoy und Istio sowie Linux-Pakete Updates. Die folgende Übersicht fasst den Stand vom 26. Oktober zusammen. Die Angaben stammen aus Herstellerquellen, Distributions-Trackern und den Analysen von Wiz, Aikido, JFrog und Phoenix Security; wo nur Sekundärquellen vorliegen, ist das vermerkt.

Was die Tabelle zeigt: Die großen Laufzeitumgebungen sind versorgt, die Lücken liegen im Detail. In Python reicht es nicht, nur requests, httpx oder aiohttp zu aktualisieren – diese Bibliotheken nutzen automatisch das installierte Brotli-Backend. Entscheidend ist also, dass Brotli mindestens 1.2.1 und brotlicffi mindestens 1.2.1.0 hat; die Aikido-Analyse zu Python empfiehlt zudem, Lockfiles neu zu erzeugen. Bei Bun müssen kompilierte Einzeldateien nach dem Update neu gebaut werden, weil die Laufzeit darin eingebettet ist.

Nicht betroffen sind laut den Analysen reine Neuimplementierungen ohne die C-Bibliothek, etwa der Rust-Decoder brotli-decompressor oder JavaScript-Ports wie das npm-Paket brotli. Unklar ist der Status des veralteten npm-Pakets iltorb, das eine eigene C-Kopie bündelt; es gilt ohnehin als überholt und lässt sich durch das eingebaute Modul node:zlib ersetzen. Bei Hosting-Panels wie Plesk oder cPanel hängt alles an der dort installierten Node.js-Version – Herstellerhinweise der Panel-Anbieter haben wir nicht gefunden.

Wer einen Überblick über alle bekannten eingebetteten Kopien sucht, findet ihn auf dem Community-Tracker broccoli2shell.com, der den Status vieler Projekte sammelt und ausdrücklich betont, die Lücke nicht selbst gefunden zu haben. Die bislang ausführlichste Analyse der Nebenschauplätze stammt von JFrog („Brotli2Shell“).

Docker, CI und Cloud: Wo alte Node-Versionen überleben

Container und Build-Pipelines sind die häufigsten Verstecke für veraltete Node.js-Versionen. Ein Update auf dem Host ändert nichts an einem Container, der auf einem fest eingetragenen Image wie node:24.22.0 basiert. Dieses Image bleibt verwundbar, auch wenn es niemand mehr anfasst.

Für Container-Landschaften lohnt ein Scan mit einem Image-Scanner wie Trivy, Grype oder Docker Scout. Ob jeder Scanner die CVE bereits kennt, konnten wir nicht verifizieren – im Zweifel hilft der direkte Blick auf die Node-Version im Image: docker run --rm image node --version. Laut Qualys sollten Teams außerdem eigenständige Node-Binärdateien (Single Executable Applications), Lambda-Funktionen und Build-Server in ihr Inventar aufnehmen, weil diese bei klassischen Paketprüfungen durchrutschen.

VS Code, Slack, Discord: Was gilt für Electron-Apps?

Ob Desktop-Apps auf Electron-Basis tatsächlich angreifbar sind, ist Stand 26. Oktober nicht geklärt – ein stabiles Electron-Release mit Fix gab es zu diesem Zeitpunkt aber noch nicht. Electron bündelt Chromium und Node.js. Laut den Electron-Releases enthielten alle stabilen Versionen bis zum 20. Oktober Node.js 24.22.0 oder 24.19.0. Erst eine Alpha-Version 46.0.0 und Nightly-Builds vom 23. Oktober bringen Node.js 24.22.1 mit.

Offen ist, ob Electrons Node-Teil die eigene, verwundbare Brotli-Kopie verwendet oder die bereits korrigierte von Chromium. Mehrere Projekte gehen vorsorglich von einer Verwundbarkeit aus. Dass konkret VS Code, Slack, Discord oder Signal betroffen seien, stützt sich bisher auf die Aussage eines Sicherheitsforschers und ist von den Herstellern unbestätigt. In den Release-Notes von VS Code 1.143.1 findet sich kein Hinweis auf Brotli.

Nicht auf Electron basiert das neue Microsoft Teams, das die Edge-Komponente WebView2 nutzt. Eine Herstellerangabe zur Brotli-Lücke haben wir für Teams nicht gefunden.

Was muss ich tun? Der Wegweiser nach Rolle

Wie dringend die Lücke für dich ist, hängt davon ab, ob du Node.js nur nutzt, damit entwickelst oder Dienste im Internet betreibst. Wähle deine Situation:

Ein Wort zu Phishing: Bekannte Sicherheitslücken mit griffigen Namen tauchen erfahrungsgemäß schnell in betrügerischen Mails auf, die ein angebliches „Sicherheitstool“ anbieten. Updates gibt es ausschließlich über nodejs.org, die Paketmanager deines Systems oder die Update-Funktion der jeweiligen App. Wie solche Maschen aussehen, zeigt unser Beitrag zur PayPal-Mail mit 24-Stunden-Frist.

Checkliste für Admins und Entwickler

Mit diesen acht Schritten ist ein typisches Node.js-Umfeld gegen Node2Shell abgesichert. Die Checkliste speichert deinen Fortschritt im Browser.

Für die Priorisierung gilt: Dienste, die direkt aus dem Internet erreichbar sind und Brotli entpacken, zuerst. Dazu zählen laut den Analysen Webhook-Empfänger, Proxys, Scraper, Link-Vorschau-Dienste und KI-Agenten, die Webseiten abrufen. Interne Werkzeuge ohne Kontakt zu fremden Daten können folgen. Wie wichtig eine saubere Update-Strategie für Systeme ohne Support ist, zeigt auch das Support-Ende von Windows 11 24H2 – das Prinzip „ohne Support kein Fix“ gilt bei Node.js genauso.

Wenn das Update dauert: Übergangsmaßnahmen

Wer nicht sofort patchen kann, kann die Angriffsfläche verkleinern – ersetzen lässt sich das Update damit nicht. Die folgenden Maßnahmen nennen Sicherheitsfirmen wie Phoenix Security und Wiz; Node.js selbst empfiehlt nur, fremde Brotli-Eingaben abzulehnen oder zu isolieren.

Einordnung: Schutzmechanismen wie ASLR, NX, FORTIFY_SOURCE und SELinux erschweren laut Red Hat eine zuverlässige Codeausführung, verhindern aber keine Abstürze. Ein Dienst, der sich gezielt zum Absturz bringen lässt, ist auch ohne Codeausführung ein Problem – etwa für Verfügbarkeit und Kosten. Wie unauffällig Angreifer vorgehen können, wenn Updates auf sich warten lassen, zeigt unser Beitrag zum BlackX-Bootkit unter Windows.

Bemerkenswert ist am Rande, wer die Lücke gefunden hat: ein KI-gestütztes Sicherheitswerkzeug von OpenAI. KI-Systeme spielen bei der Suche nach Schwachstellen eine wachsende Rolle – auf beiden Seiten. Hintergründe zu einem früheren Vorfall rund um OpenAI-Modelle und Sicherheit liefert unser Beitrag „OpenAI-KI hackt Hugging Face“.

Tech-News vom 26. Oktober 2026

Häufige Fragen zu Node2Shell und der Brotli-Lücke

TransparenzQuellen und Datenbasis28 Einträge

Grundlage sind der Sicherheitsbeitrag von Node.js, die Brotli-Releases und das GitHub-Advisory, die Sicherheitstracker von Debian, Ubuntu und Red Hat sowie Analysen von Sicherheitsfirmen und Fachmedien (Abruf jeweils 26. Oktober 2026). Angaben von Sicherheitsanbietern zu Verbreitung und Fix-Ständen sind als Bericht gekennzeichnet. NVD, cve.org und die Microsoft-Seite waren bei Redaktionsschluss nicht direkt abrufbar. Bereits im Text verlinkte Quellen führen wir ohne erneuten Link auf, Beiträge von drohnen.de nicht erneut.

• Node.js: October 2026 Security Releases (21.10.2026) – im Text verlinkt (Primärquelle)
• Google Brotli: Releases 1.0.10, 1.1.1, 1.2.1 (21.10.2026) – im Text verlinkt (Primärquelle)
• GitHub Advisory Database: GHSA-9v8h-qqgm-4m35 (22.10.2026) – im Text verlinkt (Primärquelle)
• Electron: Stable Releases (Stand 20./23.10.2026) – im Text verlinkt (Primärquelle)
• NVD: CVE-2026-111497 – bei Redaktionsschluss nicht direkt abrufbar (Behörde)
• cve.org: CVE-Record CVE-2026-111497 – bei Redaktionsschluss nicht direkt abrufbar (Primärquelle)
• Debian Security Tracker: CVE-2026-111497 – im Text verlinkt (Herstellerquelle)
• Ubuntu: CVE-2026-111497 – Priorität Medium, Pakete in Prüfung (Herstellerquelle)
• Red Hat: CVE-2026-111497 – im Text verlinkt (Herstellerquelle)
• Vercel: Security Bulletins (21.10.2026) – WAF-Regeln (Herstellerquelle)
• Docker Hub: Offizielle node-Tags – gefixte Images (Herstellerquelle)
• Visual Studio Code: Release Notes – kein Brotli-Hinweis in 1.143.1 (Herstellerquelle)
• Microsoft MSRC: CVE-2026-111497 – bei Redaktionsschluss nicht direkt abrufbar (Herstellerquelle)
• JFrog Research: Brotli2Shell (25.10.2026) – im Text verlinkt
• Wiz: CVE-2026-111497 Brotli RCE – Fix-Versionen Bun, Envoy, Istio, Go; Verbreitungsangaben (Bericht)
• Aikido: Python-Pakete und HTTP2Shell (23./26.10.2026) – im Text verlinkt
• Aikido: Node2Shell – Node.js Brotli RCE – Angriffswege (Bericht)
• HeroDevs: CVE-2026-111497 Node2Shell – Namensherkunft, KEV-Status, Updates für EOL-Versionen (Bericht)
• Phoenix Security: HTTP2Shell und eingebettete Kopien (25.10.2026) – Übergangsmaßnahmen, Webserver-Module (Bericht)
• broccoli2shell.com: Community-Tracker (Stand 26.10.2026) – im Text verlinkt
• Hadrian: Node2Shell – what we know (23.10.2026) – Express-5-Bedingung, Imperva-Demo (Bericht)
• SecurityWeek: Node2Shell triggers patching across Microsoft, Node.js, Python (26.10.2026) – .NET, Visual Studio, PowerShell (Fachmedium)
• Qualys: Node.js patches Brotli RCE flaw (23.10.2026) – im Text verlinkt
• Konfirmity: Node.js October 2026 Security Releases – AWS-Lambda-Images (Bericht)
• SecurityOnline: Node.js Security Release October 2026 (Fachmedium)
• All About Security: Node.js schließt zehn Sicherheitslücken (23.10.2026) (Fachmedium)
• WindowsForum: Node2Shell-Risiko für VS Code, .NET und eingebettete Laufzeiten (24.10.2026) – Forscheraussage zu Electron-Apps, geringe Gewichtung (Bericht)
• GitHub coder/xum: Pull Request #7374 (24.10.2026) – Electron-Status (Community)