PHP2Shell, Node2Shell, HTTP2Shell, Brotli2Shell und sogar Broccoli2Shell: Wer die Sicherheitsmeldungen im Oktober 2026 verfolgt, könnte meinen, innerhalb weniger Tage sei eine ganze Familie neuer Angriffe entstanden. Tatsächlich steckt hinter vier dieser Namen dieselbe Sicherheitslücke. Die Häufung erzählt vor allem etwas darüber, wie moderne Schwachstellen benannt, verbreitet und vermarktet werden.
Der Name einer Lücke ist längst nicht mehr nur eine technische Randnotiz. Er hilft bei der Orientierung, erzeugt Aufmerksamkeit und wird zum Suchbegriff. Doch wenn Forscher, Hersteller und Sicherheitsunternehmen dieselbe Schwachstelle unterschiedlich benennen, entsteht das Gegenteil: Verwirrung.
Der Ausgangspunkt: Log4Shell wurde zum Vorbild
Im Dezember 2021 ging Log4Shell durch die Schlagzeilen. Die kritische Schwachstelle in der Java-Protokollierungsbibliothek Log4j erhielt die Kennung CVE-2021-44228. Der leicht merkbare Name verband den betroffenen Bestandteil mit dem möglichen Ergebnis einer erfolgreichen Ausnutzung: Angreifer konnten unter bestimmten Bedingungen Code auf einem entfernten System ausführen.
2022 folgte Spring4Shell (CVE-2022-22965) im Java-Framework Spring. Schon damals war die Anlehnung an Log4Shell unverkennbar. Die Ziffer 4 ist in diesen Namen kein Schweregrad und keine technische Kategorie, sondern Teil eines griffigen Wortspiels.
Die eigentliche offizielle Identifikation läuft unabhängig davon über die CVE-Kennung. Die Spitznamen sind kommunikative Abkürzungen, keine eigene Sicherheitsnorm.
React2Shell machte aus dem Wortspiel ein neues Muster
Am 3. Dezember 2025 wurde React2Shell bekannt: CVE-2025-55182, eine kritische Schwachstelle in React Server Components. Google dokumentierte später Angriffe unterschiedlicher Tätergruppen auf verwundbare Systeme.
Aus „4Shell“ wurde „2Shell“: Das „2“ lässt sich als englisches to lesen – sinngemäß also „von React zur Shell“. Eine Shell bezeichnet hier den Zugang zur Befehlsausführung in einer Systemumgebung. Der Name soll vermitteln, dass ein Fehler unter bestimmten Voraussetzungen die Ausführung von Angreiferbefehlen ermöglicht.
Das ist allerdings keine garantierte technische Eigenschaft jedes so benannten Bugs. Ein griffiger Name sagt wenig darüber aus, ob ein Exploit öffentlich verfügbar ist, ob er zuverlässig funktioniert oder welche Systeme tatsächlich erreichbar sind.
Oktober 2026: PHP2Shell und Node2Shell treffen aufeinander
Im Oktober 2026 wurden mehrere gravierende Sicherheitsprobleme in zentralen Softwarekomponenten bekannt. Die Bezeichnung PHP2Shell wird für die PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 verwendet. Kurz darauf rückte unter dem Namen Node2Shell ein anderer Fehler in den Fokus: CVE-2026-111497.
Wichtig ist die Unterscheidung: PHP2Shell und Node2Shell sind nicht dieselbe Schwachstelle. Sie wurden in zeitlicher Nähe bekannt, betreffen jedoch unterschiedliche technische Ursachen. Wer beide Namen für einen gemeinsamen Fehler hält, kann leicht die falschen Updates priorisieren.
Node2Shell ist wiederum ein Beispiel dafür, dass ein Name sogar das betroffene Ökosystem zu eng beschreiben kann. Denn die Schwachstelle liegt im Brotli-Decoder, einer Bibliothek zur Dekomprimierung von Daten, die unter anderem Node.js einbindet.
Eine CVE, vier Namen: der Fall Broccoli2Shell
Die Fehlerkennung CVE-2026-111497 steht für einen Speicherfehler im Brotli-Decoder. Präparierte komprimierte Daten können beim Entpacken außerhalb eines vorgesehenen Puffers geschrieben werden. Je nach Einbindung drohen Abstürze, Speicherbeschädigung und unter geeigneten Bedingungen Remote Code Execution.
Der Fall zeigt besonders deutlich, wie eine einzige Schwachstelle unterschiedliche Spitznamen bekommen kann:
- Node2Shell: betont Node.js, in dessen Sicherheitsveröffentlichung die Schwachstelle im Oktober bekannt wurde. Imperva verwendete den Namen für seine technische RCE-Untersuchung.
- HTTP2Shell: soll die Auswirkungen auf HTTP-Clients und -Server verdeutlichen, die entsprechende Brotli-Daten dekomprimieren.
- Brotli2Shell: benennt die tatsächlich fehlerhafte Komponente statt eines einzelnen Produkts. JFrog verwendet diese Bezeichnung bewusst.
- Broccoli2Shell: ist eine spielerische Variante, die sich ebenfalls verbreitet hat. Sie ist ebenso wenig eine offizielle CVE-Bezeichnung wie die anderen Namen.
JFrog rekonstruierte die Entwicklung: öffentliche Bekanntgabe über Node.js am 21. Oktober, die Imperva-Forschung unter „Node2Shell“ am 22. Oktober, weitere Bezeichnungen in den folgenden Tagen. Dass sich ein Fehler über verschiedene Laufzeitumgebungen und Produkte hinweg auswirken kann, macht die Suche nach einem treffenden Namen schwierig.
Auch die britische Gesundheits-IT-Behörde NHS England nennt Node2Shell, Broccoli2Shell und HTTP2Shell gemeinsam und ordnet sie ausdrücklich der einen Kennung CVE-2026-111497 zu.
Warum Sicherheitsunternehmen eigene Namen verwenden
Ein kurzer Name lässt sich besser in eine Überschrift, eine Warnmeldung, einen Social-Media-Beitrag oder eine Suchanfrage einbauen als eine lange CVE-Nummer. Er macht komplexe Technik für eine breitere Öffentlichkeit zugänglich. Medien und Unternehmen profitieren außerdem davon, dass ein einprägsames Schlagwort häufiger wiedererkannt und geteilt wird.
Das bedeutet nicht, dass jeder Spitzname bewusst aus Marketinggründen erfunden wird. Oft entsteht er schlicht bei einer technischen Analyse oder als Bezeichnung eines Demonstrationsangriffs. Doch sobald sich ein Name verbreitet, wirken Aufmerksamkeit, Suchmaschinen und Unternehmenskommunikation als Verstärker.
Im Fall von Broccoli2Shell ist besonders auffällig, dass mehrere Namen miteinander konkurrieren, obwohl sie auf dieselbe CVE verweisen. Das kann leicht den Eindruck erwecken, es handle sich um mehrere unabhängige Notfälle.
Was sagt „Shell“ über die tatsächliche Gefahr aus?
Der Suffix „Shell“ deutet meist auf eine potenzielle Codeausführung beziehungsweise Systemübernahme hin. Er ist aber kein standardisiertes Sicherheitsurteil. Eine Schwachstelle ohne spektakulären Namen kann gravierender sein als eine mit eigener Webseite und Logo.
Für Betreiber zählt vor allem die konkrete technische Lage: Ist die betroffene Komponente vorhanden? Wird der verwundbare Verarbeitungspfad überhaupt genutzt? Können Angreifer ihn erreichen? Gibt es bestätigte Angriffe und bereits Sicherheitsupdates?
Für CVE-2026-111497 ist die Gefährdung keineswegs nur ein Namensspiel. Die Schwachstelle erreicht laut Google eine CVSS-v4.0-Bewertung von 9,2. CISA nahm sie am 27. Oktober 2026 in den Katalog aktiv ausgenutzter Schwachstellen auf. Dass mehrere Spitznamen dafür kursieren, ändert an der Priorität verfügbarer Patches nichts.
Worauf Administratoren und Leser achten sollten
Die verlässlichste gemeinsame Referenz ist die CVE-Kennung. Sie hilft, Herstellerwarnungen, Paketversionen, Sicherheitsanalysen und Monitoring-Meldungen demselben Fehler zuzuordnen. Wer nur nach einem Spitznamen sucht, kann Updates oder Erkenntnisse unter einem anderen Namen übersehen.
Gerade in automatisierten Newsfeeds, Schwachstellen-Scannern und Ticket-Systemen empfiehlt es sich deshalb, die CVE als eindeutiges Zuordnungsmerkmal zu verwenden und gebräuchliche Namen lediglich als zusätzliche Suchbegriffe zu speichern.
Das gilt auch für die Bewertung von Sicherheitsmeldungen: Nicht jeder neue „2Shell“-Name bedeutet eine neue Lücke. Und nicht jedes Vorkommen einer Bibliothek macht eine Anwendung sofort aus dem Internet angreifbar.
Fazit: Wenn ein Spitzname die Sicherheitsmeldung überholt
Von Log4Shell über Spring4Shell zu React2Shell und den aktuellen Oktober-Meldungen hat sich eine erkennbare Namenskultur entwickelt. Namen machen Sicherheitsprobleme merkbar, vereinfachen die Berichterstattung und können dringend benötigte Aufmerksamkeit schaffen.
Im Fall von Brotli zeigt sich jedoch die Kehrseite: Node2Shell, HTTP2Shell, Brotli2Shell und Broccoli2Shell klingen wie vier Angriffe, sind aber vier Bezeichnungen für CVE-2026-111497. PHP2Shell ist dagegen ein anderer Fall.
Die entscheidende Frage sollte deshalb nicht lauten, welcher Name am dramatischsten klingt, sondern welche CVE betroffen ist, wo der Fehler tatsächlich steckt und welches Update ihn behebt. Genau diese Informationen sind für die Sicherheit wichtiger als jedes Wortspiel.
Quellen und weiterführende Informationen
