IT-Sicherheit
React2Shell: Der Server hat Besuch. Eingeladen war niemand.
Pixel erzählt – eine fiktive Hundeperspektive
Technischer Faktencheck: Ing. Roland Ortner


Unterm Schreibtisch · Pixel hat das Wort · Folge 004
Ich hatte einen ausgezeichneten Vormittag geplant.
Auf meiner Decke liegen. Gelegentlich ein Ohr bewegen. Den Postboten aus Gründen der allgemeinen Ordnung im Auge behalten. Vielleicht gegen Mittag Roland daran erinnern, dass ein Landseer nicht von guten Absichten allein lebt.
Dann klingelte das Telefon.
Ich bin gegen diese Dinger. Die Menschen haben sich daran gewöhnt, dass jederzeit irgendwer in ihren Tag hineinbellen darf. Bei uns funktioniert Kommunikation wesentlich effizienter: Blickkontakt, Haltung, notfalls ein deutliches Wuff. Ende der Besprechung.
Roland hob ab.
„Grüß Gott. Was ist passiert?“
An der anderen Seite musste sich ein Mensch gerade in größerer Aufregung befinden. Selbst durch den Hörer hörte ich Wortfetzen: „React“, „Shell“, „Server“, „im Internet“ und „sofort“.
Ich hob den Kopf. Shell? Schale? Napf? Endlich ein Thema von Bedeutung?
Leider nein.
Erst die Panik. Dann die Inventur.
„Welche Anwendung ist betroffen?“, fragte Roland.
Pause.
„Wissen Sie, ob React Server Components verwendet werden?“
Längere Pause.
„Welche Version läuft produktiv?“
Jetzt wurde es so still, dass ich die Heizung arbeiten hörte.
Ich kenne dieses Schweigen. Bei uns tritt es auf, wenn ein Mensch den Garten betritt und fragt, wer den frisch eingesetzten Strauch ausgegraben hat. Alle schauen sehr beschäftigt in unterschiedliche Richtungen.
Der Anrufer hatte offenbar eine Warnmeldung gelesen. Das war vernünftig. Weniger vernünftig war, dass niemand wusste, ob die eigene Anwendung überhaupt betroffen war.
Roland blieb ruhig. Er machte sich Notizen. Stellte Fragen. Wiederholte die entscheidenden Punkte. Kein Drama. Kein Heldentheater. Nur die unangenehme Angewohnheit, erst nachzudenken und dann zu handeln.
Die Menschen sollten das öfter versuchen.
„Aber wir haben doch eine Firewall!“
Da war er. Mein Lieblingssatz.
Roland erklärte, dass eine Firewall viel leisten kann, aber keine Sicherheitslücke in einer öffentlich erreichbaren Serveranwendung wegzaubert.
Ich verstand sofort.
Bei uns im Garten gibt es einen Zaun. Ein ordentliches Ding. Trotzdem muss das Gartentor offen sein, wenn Besuch hereinkommen soll. Wenn dann jemand vergisst, die Haustür zu sichern, ist der Zaun nicht plötzlich an allem schuld.
Der Unterschied ist nur: Ich würde fremde Besucher bemerken.
Server sind diesbezüglich weniger gesprächig. Zumindest ohne vernünftige Überwachung.
Nicht alles mit React ist automatisch kaputt.
Nach dem Telefonat erfuhr ich, worum es ging. React2Shell ist eine kritische Schwachstelle in bestimmten Versionen von React Server Components. Unter passenden Bedingungen konnten Fremde Anfragen so manipulieren, dass auf einem betroffenen Server unerwünschter Code ausgeführt wurde.
Das klingt schlecht. War es auch.
Aber eine Website, auf der irgendwo „React“ steht, ist deshalb noch nicht automatisch betroffen. Entscheidend ist, welche serverseitigen Komponenten und Versionen tatsächlich verwendet werden.
Das sagte Roland dem Anrufer mehrfach.
Ich fand es bemerkenswert. Die Menschen kaufen jahrzehntelang Computer und schaffen es trotzdem, manchmal nicht zu wissen, was darauf läuft. Bei uns reicht eine einzige Nase, um festzustellen, wer zuletzt im Garten war.
Wobei ich einräumen muss: Meine Methode funktioniert bei JavaScript nur eingeschränkt.
„Dann machen wir eben schnell ein Update.“
Das wäre zumindest ein Anfang.
Roland wollte zuerst die betroffenen Pakete und die erreichbare Anwendung identifizieren. Dann die passenden Sicherheitskorrekturen einspielen. Und weil das System möglicherweise schon verwundbar im Internet gestanden hatte, wollte er auch wissen, ob es Hinweise auf einen tatsächlichen Angriff gab.
Der Mensch am Telefon fragte, ob nach dem Update wieder alles gut sei.
Roland antwortete sinngemäß: „Ein Update schließt die Lücke. Es beweist nicht, dass vorher niemand durchgegangen ist.“
Sehr vernünftig.
Wenn ich nach einem Einbruch das Gartentor zumache, sind die verschwundenen Leberwürste schließlich auch nicht wieder da.
Darum braucht es bei einem möglichen Sicherheitsvorfall mehr als einen grünen Haken: Spuren sichern, Protokolle prüfen, Zugänge und Geheimnisse bewerten, gegebenenfalls Systeme isolieren und sauber wiederherstellen.
Erstaunlich, wie oft die Menschen hoffen, ein Neustart könne die Vergangenheit ungeschehen machen.
Bei uns klappt das nicht einmal mit einem zerbissenen Hausschuh.
Der Teil, der mich wirklich beeindruckt hat
Irgendwann wurde die Stimme am Telefon ruhiger.
Das war vermutlich der wichtigste Fortschritt des ganzen Gesprächs.
Denn Panik hilft niemandem. Nicht den Menschen, nicht den Servern und ganz sicher nicht mir bei meinem Vormittagsschlaf.
Roland versprach keine Wunder. Er erklärte, was man wusste, was noch geprüft werden musste und welche Schritte jetzt sinnvoll waren.
So sollte Führung aussehen: nicht am lautesten bellen, sondern wissen, weshalb man bellt.
Ich habe mich wieder auf meine Decke gelegt.
Pixels Fazit
Die Menschen können unglaublich komplizierte Systeme bauen.
Dann vergessen sie gelegentlich, aufzuschreiben, was sie gebaut haben, wer dafür verantwortlich ist und wann zuletzt jemand nach dem Rechten gesehen hat.
Und wenn plötzlich ein Fremder vor der digitalen Haustür steht, sind alle überrascht.
Wer nicht weiß, was auf seinem Server läuft, betreibt kein Sicherheitsmanagement. Er betreibt Hoffnung.
Hoffnung mag etwas Schönes sein. Ich bevorzuge einen geschlossenen Gartenzaun, eine kontrollierte Tür und jemanden, der gelegentlich nachschaut.
Apropos nachschauen: Mein Wassernapf ist leer.
Pixel · Landseer, Büroaufsicht und Leiter der Abteilung Hausverstand.
Roland, mein Herrli, beurteilt das gewohnt pragmatisch so:
Was ist passiert? Am 3. Dezember 2025 veröffentlichte das React-Team die kritische Schwachstelle CVE-2025-55182 (React2Shell, CVSS 10.0). Die Schwachstelle betrifft die Verarbeitung manipulierter Eingaben in bestimmten React Server Components und kann unter betroffenen Konfigurationen eine unauthentifizierte Remote Code Execution ermöglichen.
Welche Pakete waren ursprünglich verwundbar? Die RSC-Pakete react-server-dom-webpack, react-server-dom-parcel und react-server-dom-turbopack in den Versionen 19.0, 19.1.0, 19.1.1 und 19.2.0. Frameworks, die diese Pakete einbinden, darunter bestimmte Next.js-Anwendungen mit App Router, konnten ebenfalls betroffen sein. Eine rein clientseitige React-Anwendung ohne RSC-Unterstützung ist dadurch nicht automatisch verwundbar.
Was müssen Betreiber prüfen? Tatsächlich eingesetzte Versionen einschließlich transitiver Abhängigkeiten und der verwendeten Frameworks, produktiv erreichbare Serverfunktionen, Deployment-Stand und Expositionszeitraum. Nicht allein nach dem Schlagwort „React“ entscheiden.
Wie wird behoben? Nach dem aktuellen, offiziellen Hersteller-Advisory auf die neueste abgesicherte Version der jeweils betroffenen Release-Linie aktualisieren, neu bauen und korrekt ausrollen. Nicht blind auf einen alten Minimal-Patchstand aus Dezember 2025 zurückgehen: Später veröffentlichte Sicherheitsmeldungen erforderten weitere Updates, unter anderem gegen Denial-of-Service und Quellcodeoffenlegung (CVE-2025-55184, CVE-2025-67779, CVE-2025-55183 und CVE-2026-23864). Die ursprüngliche RCE und diese Folgeprobleme sind unterschiedliche Schwachstellen.
Was, wenn die Anwendung schon ungeschützt erreichbar war? Risikoabhängig eine Incident-Response-Prüfung durchführen: Protokolle und verfügbare Artefakte sichern, nach Kompromittierungsanzeichen suchen, gegebenenfalls isolieren und betroffene Zugänge beziehungsweise Geheimnisse rotieren. Ein Sicherheitsupdate beseitigt nicht automatisch bereits vorhandene Schadsoftware oder die Folgen früherer Zugriffe. Ob tatsächlich ein Angriff stattgefunden hat, darf ohne Untersuchung weder behauptet noch ausgeschlossen werden.
Hilft eine Firewall? Netzwerk- und Anwendungsschutz können Risiken reduzieren, ersetzen aber kein Sicherheitsupdate der anfälligen Serveranwendung.
Redaktioneller Hinweis: Das Telefonat ist frei erfunden. Es ist kein wiedergegebenes Kundengespräch und behauptet keine tatsächlich durchgeführte Incident Response durch ComputerCompetence.
Fachliche Freigabe: Durch Ing. Roland Ortner vor Veröffentlichung erforderlich. Quellenstand: 05.11.2026.