Die servertötende Schwachstelle von React erklärt

Das schlimmste Szenario für React Server Components ist eingetreten: ein höchst kritischer, CVSS 10.0 Remote-Code-Ausführungsfehler, den Sicherheitsforscher schnell als „katastrophal“ einstuften. Auf dem Spiel steht jede Anwendung, die das anfällige React-Server-Paket verwendet, von Hobby-Next.js-Projekten bis hin zu stark frequentierten Produktionsseiten, die plötzlich unbefugten Angreifern ausgesetzt sind. Eine gezielte HTTP-Anfrage könnte beliebigen Code auf dem Server ausführen, ohne dass eine Anmeldung erforderlich ist.

Die React-Maintainer reagierten mit ungewöhnlich direkter Sprache auf die Veröffentlichung des Frameworks und forderten die Entwickler auf, "sofort auf alle betroffenen Versionen zu aktualisieren". Die Hosting-Plattformen zogen nach: Vercel, Cloudflare und andere veröffentlichten hastig Notfall-WAF-Regeln und warnten, dass diese Filter nur teils Schutz bieten. Die Sicherheitsteams behandelten die Mitteilung wie eine Null-Tag-Feuerübung und schoben innerhalb von Stunden Patches in die Produktion.

Sicherheits-Mailinglisten und Discord-Kanäle, gefüllt mit roten Bannern und Nachrichten wie „Alles stehen lassen und React patchen“. Die DevOps-Teams haben die Bereitstellung von Funktionen gestoppt, um Priorität auf Abhängigkeits-Upgrades, Abhängigkeitspinning und erneute Bereitstellungen zu legen. CI-Pipelines, die normalerweise Tage für Änderungen benötigen, lieferten plötzlich neue React-Bauten in Minuten aus.

Der Name für den Bug kam ebenso schnell. Forscher und die React-Community einigten sich auf React2Shell, ein absichtliches Echo von Log4Shell, das dieselbe Art von Albtraum signalisierte: eine allgegenwärtige Komponente, einen Serialisierungsfehler und triviale Remote-Code-Ausführung. Die dedizierte Website react2shell.com und ein wachsendes GitHub-Ökosystem von Proof-of-Concept-Exploits festigten die Markenbildung.

Vergleichnungen mit Log4Shell waren nicht nur Marketing. Wie Log4j im Jahr 2021 sitzen React Server Components tief in modernen Web-Stacks, verborgen hinter Frameworks, Boilerplates und Vorlagen. Viele Teams benötigten Stunden, um eine grundlegende Frage zu beantworten: „Laufen wir irgendwo React Server Components, und auf welchen Versionen?“

Berichte über aktive Ausnutzung trafen fast sofort ein. Die Sicherheitsteams von AWS warnten vor „Cyberbedrohungsgruppen, die schnell versuchen, dies auszunutzen“, wobei Scanner das Internet nach anfälligen Next.js-Servern durchkämmen. Bug-Bounty-Jäger und kriminelle Betreiber begannen, Payloads auszutauschen, die eine einzelne POST-Anfrage in eine Shell-Eingabeaufforderung auf der Infrastruktur anderer verwandelten.

React2Shell befindet sich in der schlimmsten Kategorie von Bugs: nicht authentifizierte Remote-Codeausführung auf öffentlich zugänglichen Servern. Kein Login, kein CSRF-Token, kein Trick, um einen Nutzer dazu zu bringen, irgendetwas zu klicken. Eine einzig gestaltete HTTP-Anfrage erreicht einen Endpunkt für React Server Components und der Angreifer führt beliebige Befehle mit den Rechten aus, die dein Node-Prozess hat.

Sicherheitsexperten fürchten RCE, da es jede andere Verteidigung zum Einsturz bringt. Sobald ein Angreifer Code ausführen kann, kann er Umgebungsvariablen lesen, Datenbanken dumpen, Webshells einfügen, Krypto-Miner installieren oder tiefer in Ihre Cloud eindringen. An diesem Punkt „leaken“ Sie keine Daten mehr; Sie hosten das Operationszentrum eines anderen.

React2Shell endet nicht bei Next.js. Der Fehler steckt im React-Server-Paket und dessen Implementierung des React Flight-Protokolls, sodass jedes Framework, das in diesen Stack integriert, den Auswirkungen ausgesetzt ist. Dazu gehören Projekte wie Waku, die serverseitigen Funktionen von React Router und jedes benutzerdefinierte Backend, das sich entschieden hat, direkt mit Flight zu kommunizieren.

CVSS 10.0 ist kein Marketing-Geschwätz; es ist die Spitze der standardisierten Risikoskala. Ein so hoher Wert impliziert drei Dinge zugleich: triviale Ausnutzbarkeit, keine Authentifizierungsbarriere und vollständige Kompromittierung von Vertraulichkeit, Integrität und Verfügbarkeit. Sie benötigen keine verketteten Fehler, Wettlaufbedingungen oder lokalen Zugriff; die Erreichbarkeit über das Internet und eine anfällige Version sind ausreichend.

Unter CVSS erreicht React2Shell in allen Kategorien die maximalen Werte: Angriffsvektor: Netzwerk, Angriffs Komplexität: Niedrig, Erforderliche Berechtigungen: Keine, Benutzerinteraktion: Keine. Auch die Auswirkungen maximieren sich, da die Ausführung von beliebigem Code vollständige Lese-/Schreibkontrolle über Anwendungsdaten und die Fähigkeit bedeutet, den Dienst zum Absturz zu bringen oder umzuprogrammieren. Aus diesem Grund wird diese Sicherheitswarnung als „Kritisch“ und nicht als „Hoch“ eingestuft.

Das beunruhigendste Detail: Sie müssen keine exotischen Funktionen aktivieren, um betroffen zu werden. Der verwundbare Code befindet sich im zentralen Serialisierungspfad, den React Server Components standardmäßig verwenden, sodass ein brandneues „npx create-next-app“ mit betroffenen Versionen bereits am ersten Tag ausnutzbare Logik mitliefert. Keine Serveraktionen, keine benutzerdefinierten Deserialisierer, keine experimentellen Flags erforderlich.

React2Shell verwandelt Boilerplate in eine Angriffsoberfläche. Wenn Ihr Stack über den anfälligen React-Server-Paket spricht und über HTTP erreichbar ist, befinden Sie sich im Geltungsbereich.

React2Shell lebt nicht in den Server-Aktionen. Es gehört zum React Flight-Protokoll selbst – dem Low-Level-Serializer/Deserializer, der alle React Server Components antreibt. Wenn dein Stack Flight-Payloads mit einer verwundbaren `react-server`-Version analysiert, inheritierst du nicht authentifizierte RCE, unabhängig davon, ob du jemals `use server` in deinem Code geschrieben hast.

Metas Beratung hebt das `react-server`-Paket als anfällig in bestimmten Versionen 19.x hervor. Jedes Framework, das diese Versionen bündelt und einen Flight-Endpunkt bereitstellt, ist betroffen. Diese Liste umfasst Next.js sowie andere Flight-Nutzer wie die Daten-APIs von React Router und aufkommende RSC-Frameworks.

Der Next.js App Router macht dies besonders gefährlich, da seine Standardarchitektur Flight automatisch für Sie einrichtet. Eine frische `create-next-app` mit dem App Router und einer verwundbaren Next.js-Version (zum Beispiel 14.x in Kombination mit React 19.0.0–19.2.0) erzeugt Endpunkte, die Flight-Formulardaten ohne zusätzliche Konfiguration akzeptieren. Erstellen, bereitstellen, und Sie haben eine RCE-Oberfläche, die dem Internet ausgesetzt ist.

Jeder HTTP-Handler, der eine Serverkomponenten-Nutzlast verarbeitet, wird zu einem potenziellen Einstiegspunkt. Dazu gehören: - Eingebaute Datenendpunkte des App-Routers - Benutzerdefinierte Routen-Handler, die `renderToReadableStream` oder ähnliche Flight-APIs aufrufen - Jede Proxy- oder Edge-Funktion, die Flight-Nutzlasten an einen Node-Server weiterleitet

Authentifizierung schützt Sie nicht standardmäßig. Wenn ein Angreifer einen Flight-Endpunkt vor der Authentifizierung erreichen kann, erhält er eine Vor-Authentifizierung RCE. Wenn Ihre Flight-Parsing-Funktion hinter einem Login sitzt, Sie sie jedoch für Browser zugänglich machen, wird jeder Cross-Site Request Forgery oder Token-Diebstahl sofort zu einem vollständigen Serverkompromiss.

Metas eigene Mitteilung, Kritische Sicherheitsanfälligkeit in React-Serverkomponenten (CVE-2025-55182), warnt ausdrücklich, dass die WAF-Regeln der Hosting-Anbieter nur eine vorläufige Lösung sind. Patchen Sie `react-server` und Ihr Framework, oder gehen Sie davon aus, dass jede exponierte Flight-Schnittstelle bereits untersucht wird.

Eine HTTP-Anfrage ist alles, was ein Angreifer benötigt. React2Shell verwandelt einen langweiligen POST-Endpunkt in einer React Server Components-App in eine Remote-Shell, indem es ausnutzt, wie das React Flight-Protokoll gestreamte Komponentendaten deserialisiert. Keine Authentifizierung, kein CSRF-Token, keine Benutzersitzung erforderlich.

Angreifer beginnen damit, eine bösartige POST-Anfrage zu erstellen, die wie eine normale Formularübermittlung aussieht. Der Body verwendet `multipart/form-data`, dasselbe Format, das React Flight verwendet, um Serverkomponenten-Lasten und Serveraktionen zu streamen. Innerhalb dieser Formulardaten versteckt der Angreifer eine Reihe von „Chunks“, die die interne, mit `$`-präfixierte Referenzsyntax von Flight nachahmen.

Jeder Abschnitt gibt vor, Teil eines legitimen Komponentenbaums zu sein, doch die Struktur ist manipuliert. Ein Feld verweist auf einen anderen Abschnitt, indem es `$0`, `$1`, `$2` und so weiter verwendet, während eine speziell gestaltete Pfadzeichenfolge `:`-Trennzeichen nutzt, um in verschachtelte Eigenschaften vorzudringen. In diesem Pfad versteckt sich die eigentliche Payload: ein Versuch, auf `__proto__` zuzugreifen und in die internen Objekte von JavaScript einzudringen.

Wenn der verwundbare Server die Anfrage erhält, wird der Flight-Deserializer von React automatisch aktiviert. Er analysiert die Formulardaten, rekonstruiert den Chunk-Graph und beginnt damit, die `$`-Referenzen und durch Doppelpunkte getrennten Pfade aufzulösen. Entscheidend ist, dass ältere React-Serverversionen niemals überprüft haben, ob ein angeforderter Schlüssel eine „eigene“ Eigenschaft war, wodurch `__proto__` unbehelligt durchkam.

Dieser Fehler verwandelt eine einfache Abfrage in eine vollständige Prototyp-Verschmutzung. Indem ein Pfad wie `$1:__proto__:execSync` aufgelöst wird, kann der Deserialisierer dem Angreifer eine aktive Referenz auf `child_process.execSync` (oder ähnliche Primitives) übergeben, die an das verschmutzte Prototyp angeschlossen sind. Von dort aus weist die Nutzlast den Server an, beliebige Shell-Befehle als Teil des Deserialisierungsprozesses selbst auszuführen.

Proof-of-Concept-Code auf React2Shell und die Original- sowie Detail-POCs nutzen dies zu einem One-Shot-Exploit. Der vom Angreifer gestaltete POST-Befehl zwingt den Server, einen Befehl auszuführen, der „you have been pawned“ ausgibt und dann `cat secret.txt` ausführt, um eine Datei vom Desktop des Servers zu lesen. In der Demo werden die Inhalte direkt in die Next.js-Serverprotokolle gestreamt, jedoch könnte das gleiche Primitive auch Geheimnisse über `curl` exfiltrieren, eine Reverse Shell einrichten oder mit einer einzigen Anfrage dauerhaften Malware installieren.

React Flight existiert, um ein echtes Problem zu lösen: Wie kann man einen Baum von React Server Components vom Backend zum Browser streamen, ohne die Hälfte deiner Serverlaufzeit als JavaScript zu versenden? Anstelle von JSON hat das React-Team ein benutzerdefiniertes Datenformat entwickelt, das Komponenten, Props und Referenzen als eine Folge kleiner „Chunks“ beschreibt, die über das Netzwerk übertragen werden und schrittweise auf dem Client hydratisiert werden.

Jedes Stück im React Flight-Protokoll enthält ein winziges Stück der Benutzeroberfläche: vielleicht einen Komponententyp, vielleicht Props, vielleicht einen Platzhalter für ein Versprechen. Um Daten zu vermeiden, die wiederholt werden, verwendet Flight spezielle String-Token, die mit "$" beginnen, um auf andere Stücke zu verweisen. Ein Payload könnte `"$1"` sagen, um „schau dir Stück 1 an“, oder `"$1:name"` sagen, um „zum Stück 1 zu gehen und dann dem `name`-Pfad auf dem Objekt dort zu folgen.“

Diese `$`-Referenzen bilden ein kompaktes Diagramm von Objekten, das der Deserializer wieder zusammensetzt. Chunk 0 kann einfach `["$1"]` sein, Chunk 1 kann ein Objekt sein, das selbst auf Chunk 2 verweist, und so weiter. Das Ergebnis auf der Server- oder Client-Seite ist ein sauberes JavaScript-Objekt wie `{ name: "cherry" }`, obwohl das Übertragungsformat wie eine seltsame Mischung aus Indizes und Pfadzeichenfolgen aussah.

Die Hauptursache für React2Shell verbirgt sich in dieser pfadverfolgendenden Logik. Der Flight-Deserializer akzeptierte bereitwillig von Angreifern kontrollierte Anweisungen zur Pfadüberquerung wie `"$1:__proto__:toString"` und folgte ihnen, ohne zu fragen, ob diese Schlüssel zugänglich sein sollten. Keine Sicherheitsvorkehrungen, keine Überprüfungen von Eigenschaften, nur direkter Zugriff auf das, was der Pfadstring beschrieb.

Anstatt bei Benutzerdaten Halt zu machen, drangen diese Traversierungsschritte direkt in die Interna von JavaScript ein. Durch das Auflösen von Wegen wie `__proto__` bei einfachen Objekten öffnete der Deserializer die Tür zur klassischen Prototypenverunreinigung. Von dort aus verbanden Angreifer sich mit mächtigen eingebauten Funktionen und lenkten schließlich die Ausführung auf `child_process`, wodurch sie mit einer einzigen bösartigen Anfrage die entfernte Codeausführung erreichten.

JSON wäre hier langweilig und sicherer gewesen. Standard-JSON fehlt es an Referenzen, Pfaden oder speziellen `$`-Semantiken; es beschreibt nur Daten, nicht wie man sie durchläuft oder rekonstruiert. Flights maßgeschneidertes Format fügte Querverweise zwischen Abschnitten und Traversierungssyntax hinzu, jedoch ohne die härtenden Validierungsschichten, die ausgereifte Serialisierer und JSON-Parser über Jahre hinweg durch Sicherheitsüberprüfungen angesammelt haben.

Benutzerdefinierte Protokolle tauschen immer Sicherheit gegen Flexibilität ein. Mit der Erfindung einer ad-hoc-Mini-Sprache innerhalb von Zeichenfolgen wie `"$1:foo:bar"` schuf das Flight-Format von React eine neue Angriffsfläche, die generische Tools – JSON-Validatoren, Schema-Prüfer, WAF-Regeln – nicht verstanden. Sobald diese Mini-Sprache `__proto__` erreichen konnte, erbte jeder Server, der React Server Components verwendete, den gleichen kritischen Fehler.

Prototypen-Verschmutzung scheint abstrakt zu sein, ist aber in JavaScript eine der gefährlichsten Fehlerklassen, die Sie ausliefern können. Anstatt ein einzelnes Objekt zu beschädigen, ermöglicht Prototypen-Verschmutzung einem Angreifer, `Object.prototype` selbst zu manipulieren, den gemeinsamen Vorfahren fast jedes Objekts in einem Node- oder Browser-Prozess. Sobald diese Wurzel kompromittiert ist, beginnt der gesamte Objektgraph, die vom Angreifer kontrollierten Eigenschaften zu erben.

Die React Server Components gerieten durch die Logik der React Flight Protocol-Pfadverarbeitung in diese Falle. Der Deserialisierer unterstützt eine durch Doppelpunkt getrennte Syntax, um durch verschachtelte Strukturen zu navigieren, sodass ein Verweis wie `:$1:fruit:name` bedeutet: „Folge Chunk 1, dann `fruit`, dann `name`.“ Die Forscher bemerkten, dass nichts sie daran hinderte, einen normalen Schlüssel gegen JavaScript-Innereien auszutauschen und stattdessen nach `:__proto__` zu fragen.

Diese eine Änderung verwandelte ein Komfortmerkmal in eine Waffe. Als der anfällige Code einen Pfadsegment wie `__proto__` sah, behandelte er es als einfach eine weitere Eigenschaft und ging blind in `value['__proto__']`. In JavaScript übergibt dieser Sprung Ihnen das lebende `Object.prototype` des Ziels und nicht ein harmloses Feld in einem Datenbehälter.

Sobald der Exploit-Pfad `__proto__` erreichte, konnten Angreifer beginnen, darauf zu schreiben. Indem sie gezielte Flight-Chunks sendeten, konnten sie Dinge wie `payload: { ":$1:__proto__:pwned": "yes" }` tun, was effektiv `Object.prototype.pwned = "yes"` setzt. Von diesem Moment an hat jedes einfache Objekt im Prozess plötzlich eine `pwned`-Eigenschaft, selbst solche, die lange nach Abschluss der Exploit-Anfrage erstellt wurden.

Verschmutzung macht vor String-Flags nicht halt. Angreifer können gesamte Funktionen in das Prototyp-Objekt injizieren, wie `Object.prototype.toJSON` oder benutzerdefinierte Hooks, denen der nachgelagerte Code vertraut. Wenn eine spätere Bibliothek `JSON.stringify(user)` ausführt oder `options.onSuccess?.()` aufruft, könnte tatsächlich der von Angreifern bereitgestellte Code ausgeführt werden, der Minuten zuvor in das Prototyp-Objekt eingepflanzt wurde.

React2Shell verwandelt dies in remote code execution, indem es leistungsstarke, selten geprüfte Stellen im Stack anvisiert. Zum Beispiel können kontaminierte Eigenschaften beeinflussen, wie ein Framework Shell-Befehle, Dateipfade oder dynamische `require`-Aufrufe erstellt. Sobald ein kontaminierter Wert in `child_process.exec`, eine Template-Engine oder einen dynamischen Import gelangt, geschieht der Übergang von “seltsames zusätzliches Feld” zu “willkürlicher Befehl auf dem Server” in einer einzigen Zeile.

Vollständige technische Details im NVD-Eintrag für CVE-2025-55182 und der detaillierte Proof-of-Concept zeigen, wie eine einzelne HTTP-Anfrage sowohl `Object.prototype` kontaminiert als auch diese beschädigten Eigenschaften in die gefährlichsten APIs von Node überträgt. Diese Kombination rechtfertigt die CVSS-Bewertung von 10.0: eine nicht authentifizierte Anfrage, vollständige Kompromittierung des gesamten Prozesses.

Die bloße Prototyp-Verschmutzung allein verschafft Ihnen keinen Shell-Zugang; Angreifer benötigen weiterhin einen Weg, um ein beschädigtes Objektgraph in ausführbare Systembefehle umzuwandeln. Der letzte Trick von React2Shell verband diesen verschmutzten Prototyp zu einem vollständig bewaffneten ausgelagerten Codeausführungs-Pfad und nutzte nichts Exotischeres als die Reflexionseigenschaften und asynchronen Semantiken von JavaScript.

Sobald der Angreifer die Kontrolle über das Basisobjekt-Prototyp erlangte, konnte er die Prototypenkette durchlaufen, um den globalen Function-Konstruktor zu erreichen. In JavaScript erbt jede Funktion letztendlich von `Function.prototype`, und `Function` selbst ist über Konstruktoren wie `({}).constructor.constructor` zugänglich.

Mit diesem Zugriff führt die Payload einfach das aus, was jeder „no eval“-Umgehung entspricht: `new Function("require('child_process').execSync('id > /tmp/pwned');")`. Dieser String kann jeden Shell-Befehl enthalten: `curl`, um Daten zu exfiltrieren, `rm -rf`, um Festplatten zu löschen, oder eine Einzeiler, um eine Reverse-Shell zu starten. Auf einem Next.js-Server werden diese Befehle mit den gleichen Berechtigungen wie der Node-Prozess ausgeführt, was oft direkten Zugriff auf Umgebungsvariablen, API-Schlüssel und private Dateien bietet.

Angreifer standen weiterhin vor einem Problem: Sie konnten eine bösartige Funktion erstellen, kontrollierten jedoch keinen offensichtlichen Aufrufort. Sie benötigten den eigenen Kontrollfluss des Servers, um ihre Funktion automatisch auszuführen, ohne einen expliziten Aufruf `malicious()` im Anwendungscode.

Das `await`-Schlüsselwort von JavaScript lieferte die fehlende Verbindung. Intern überprüft `await value`, ob `value` "thenable" ist, und ruft, falls ja, `value.then(resolve, reject)` auf. Dieses stille Verhalten ist genau das, was Promises antreibt – und genau das, was React2Shell ausnutzt.

Durch die Verschmutzung des gemeinsamen Prototyps, um eine `.then`-Eigenschaft zu definieren, die auf die Function-Instanz des Angreifers verweist, wurde jedes erwartete Objekt plötzlich zu einem Auslöser. Wenn der Code der React Server Components auf ein `await` für einen deserialisierten Wert traf, rief die JS-Engine pflichtbewusst `.then` auf, das nun beliebige Shell-Befehle ausführte. Keine zusätzlichen Hooks, keine seltsamen Gadgets—nur normale asynchrone Code-Pfade, die in ein universelles RCE-Trampolin umgewandelt wurden.

Reacts Lösung für React2Shell sieht fast beleidigend einfach aus. Nach einer Kette, die von Pfadnavigation über Prototyp-Verschmutzung bis hin zu gehackten Promises und `child_process.execSync` reicht, fügt der offizielle Patch des React-Teams im Wesentlichen einen einzigen Zugangskontrolleur hinzu: ein einzelnes `if`, das `Object.prototype.hasOwnProperty` aufruft, bevor eine Eigenschaft während der Flight-Deserialisierung gelesen wird.

Anstatt blind `value = value[path]` für jedes Segment der Traversierung auszuführen, überprüft der gepatchte Code zuerst `if (!Object.prototype.hasOwnProperty.call(value, path))` und bricht mit einem Fehler ab, wenn der Schlüssel fehlt. Diese kleine Bedingung ändert das Verhalten von „die gesamte JavaScript-Objektstruktur durchlaufen“ zu „nur Felder vertrauen, die dieses Objekt tatsächlich besitzt.“ Böswillige `__proto__`-Referenzen, die nur in der Prototypkette existieren, stoßen plötzlich auf eine harte Wand.

Das funktioniert, weil `hasOwnProperty` die vererbte Prototypenkette vollständig ignoriert. In JavaScript erbt jedes einfache Objekt von `Object.prototype`, wo gefährliche Metaeigenschaften wie `__proto__` und `constructor` existieren. Indem Reacts Flight-Protokoll darauf besteht, dass jeder dereferenzierte Schlüssel eine „eigene Eigenschaft“ ist, wird verhindert, dass Angreifer je auf diese Interna zugreifen können, sodass das verunreinigte Prototype niemals entsteht.

Sicherheitsforscher sagen gerne, dass die meisten katastrophalen Fehler auf eine fehlende Überprüfung zurückzuführen sind, und React2Shell beweist das. Vor dem Patch vertraute der Deserialisierer implizit jedem Pfad, den der Client sendete, selbst wenn er direkt in die Innereien von JavaScript zeigte. Danach verwandelt diese eine `if`-Anweisung eine CVSS 10.0 RCE-Kette in einen langweiligen „ungültiger Verweis“-Fehler.

Vor dem Hintergrund der unauthentifizierten RCE in Tausenden von Deployments von React Server Components wirkt die Eleganz fast beunruhigend. Ein weitreichendes Ökosystem, das auf React Server Components und Next.js aufgebaut ist, ruht auf einem einzigen Schutzmechanismus, der von Anfang an vorhanden sein sollte. Eine einzige Zeile defensiven Codes trennt jetzt ein routinemäßiges Server-Rendering von einer vollständigen Übernahme des Servers.

React2Shell hat sich in wenigen Tagen von einem theoretischen Albtraum zu einem praktischen Angriffswerkzeug entwickelt. Proof-of-Concept-Repos, Exploit-Beschreibungen und einsatzbereite Payloads sind jetzt auf GitHub verfügbar, wodurch die Hürde von Staatshackern auf Wochenend-Tüftler gesenkt wird. Jede internetfähige App, die anfällige React Server Components nutzt, bewirbt effektiv “unauthentifizierte Shell auf Port 443 verfügbar.”

Sicherheitsteams sehen bereits die Auswirkungen. AWS berichtet, dass „Cyberbedrohungsgruppen schnell versuchen, dies auszunutzen“, wobei Scanner nach charakteristischen React Flight-Endpunkten über riesige IP-Bereiche fegen. Unabhängige Forscher und MSSPs beschreiben zunehmende Proben, die fehlerhafte Flight-Payloads senden und subtile Zeit- und Fehlerunterschiede beobachten, um verwundbare Ziele zu identifizieren.

Angreifer benötigen keine pixelgenauen Kopien des ursprünglichen Exploits. Mit öffentlichen PoCs und detaillierten Berichten wie CVE-2025-55182 (React2Shell): Remote Code-Ausführung in React Server Components können sie Payloads endlos verändern. Ändern Sie Feldnamen, ordnen Sie Teile neu an oder verstecken Sie die kontaminierte Prototypenkette hinter zusätzlichen Ebenen der Indirektion, und Sie weichen bereits von den Signaturen ab, die die meisten WAF-Regeln erwarten.

Hosting-Anbieter haben schnell Notfallfilter eingeführt. Vercel, Cloudflare und AWS haben WAF-Updates veröffentlicht, die offensichtliche Missbrauchsmuster von React Flight blockieren, wie z. B. `__proto__`-Referenzen in Multipart-Formulardaten oder verdächtige, mit `$`-beginnenende Chunk-Referenzen. Diese Regeln helfen gegen Copy-Paste-Angriffe, zielen jedoch nur auf bekannte Formen eines Fehlers ab, der grundsätzlich darin besteht, wie der Server Eingaben deserialisiert.

Die Geschichte zeigt, dass WAF-Only-Verteidigungen schlecht altern. Sobald eine CVSS 10.0 RCE öffentlich wird, iterieren Exploit-Autoren schneller, als Anbieter neue Signaturen ausliefern können. Obfuskationstricks – Unicode-Homoglyphen, alternative Zugangspfade wie `constructor.prototype`, verschachtelte Arrays oder komprimierte Payloads – umgehen routinemäßig generische „blockiere diesen String“-Filter.

Nur eine Kontrolle verändert die Regeln des Engagements: das Patchen. Das Upgrade von React, Next.js und jedem Framework, das das verwundbare React-Server-Paket einbettet, entfernt die unsichere Flight-Deserialisierung vollständig. Kein noch so clever konfiguriertes WAF kann die Sicherheit ersetzen, den Bug von vornherein nicht auszuführen.

React2Shell lädt sofortige Log4Shell-Vergleiche aus einem einfachen Grund ein: Explosionsradius. Ein einzelner nicht authentifizierter POST kann Remote Code Execution auf fast jeder Anwendung auslösen, die anfällige React Server Components verwendet, von Hobby-Next.js-Projekten bis hin zu stark frequentierten SaaS-Dashboards. Ähnlich wie bei Log4Shell befindet sich der Fehler im Infrastruktur-Code, den Tausende von Teams implizit übernommen haben, nicht in einem offensichtlichen "sicherheitssensiblen" Feature, das sie bewusst aktiviert haben.

Log4Shell profitierte von der Allgegenwart von Log4j in Java-Stacks; React2Shell nutzt die Dominanz von React in modernen Web-Frontends aus. Jedes Framework, das das React Flight-Protokoll integriert hat – Next.js, die Daten-APIs von React Router, aufkommende RSC-Frameworks – erbte plötzlich eine CVSS 10.0-Verantwortlichkeit. Solch ein Risiko auf Ebene des Ökosystems ist genau das, was Log4Shell zu einem Vorfall gemacht hat, der einmal pro Jahrzehnt vorkommt.

Wo Log4Shell Annahmen über Logging-Bibliotheken zerschlug, zerreißt React2Shell das mentale Modell von „Frontend“-Frameworks. React Server Components verwischen die Grenze zwischen Client und Server, aber dieser Fehler beweist, dass auch die Sicherheitsgrenze verschwommen ist. Ein Komponentenbaum fungiert nun gleichzeitig als Protokolloberfläche, und ein Serialisierungsformat wurde stillschweigend zu einem primitiven Werkzeug für Remote-Code-Ausführung.

Die Sicherheitsverantwortung ließ sich früher klar aufteilen: Backend-Teams schützten APIs und Datenbanken; Frontend-Teams hatten sich um XSS und CSRF gekümmert. Die Stacks der RSC-Ära beseitigen diese Grenze. Wenn eine JSX-Komponente Serverlogik über ein benutzerdefiniertes Datenformat auslösen kann, kann eine "Frontend"-Änderung eine Backend-Schwachstelle einführen, und keine der beiden Seiten fühlt sich möglicherweise vollständig verantwortlich.

Entwickler müssen jetzt eine unangenehme Frage stellen: Haben Serverkomponenten ein Sicherheitsmodell, über das sie tatsächlich nachdenken können? React2Shell hat aufgezeigt, wie wenige Menschen die inneren Abläufe von Flight vor dieser Woche verstanden haben, einschließlich vieler, die es in der Produktion eingesetzt haben. Wenn Sie nicht erklären können, welche Eingaben den Deserializer erreichen, können Sie Ihr App-Modell nicht sinnvoll Bedrohungen gegenüberstellen.

Framework-Autoren sehen sich einem strengeren Mandat gegenüber. Protokolle wie Flight, die Daten-Loader von Remix oder die benutzerdefinierten Codierungen von tRPC verdienen die gleiche Prüfung wie ORM-Abfrage-Builder oder TLS-Stacks. Das bedeutet formale Bedrohungsmodelle, Fuzzing, Red-Teaming-Überprüfungen und externe Audits, die sich auf Serialisierung, Referenzauflösung und grenzüberschreitende Datenflüsse konzentrieren.

Reacts schnelle Aktualisierung verhinderte ein vollständiges Log4Shell-ähnliches Desaster, aber der Warnschuss ist laut. Jedes Tool, das Logik über das Netzwerk bewegt – egal, wie sehr es nach „Frontend“ aussieht – gehört jetzt eindeutig in die Kategorie der kritischen Angriffsfläche.

Was ist die React2Shell-Sicherheitsanfälligkeit (CVE-2025-55182)?

React2Shell ist eine kritische nicht authentifizierte Remote Code Execution (RCE) Sicherheitsanfälligkeit in React Server Components. Sie ermöglicht es einem Angreifer, beliebigen Code auf einem Server mit einer einzigen bösartigen Anfrage auszuführen, und hat die höchstmögliche Schweregradbewertung von CVSS 10.0.

Welche Versionen von React und Next.js sind betroffen?

Die Sicherheitsanfälligkeit betrifft die React Server-Versionen 19.0.0 bis 19.2.0. Dazu gehören auch Frameworks, die es verwenden, wie Next.js. Jede Next.js-Version, die eine betroffene React Server-Version nutzt, wie die in den Demos gezeigte Version 16.0.6, ist anfällig. Benutzer sollten umgehend auf die neuesten, gepatchten Versionen aktualisieren.

Wie funktioniert der React2Shell-Exploit?

Der Exploit nutzt eine unsichere Deserialisierungsanfälligkeit im React Flight-Protokoll aus. Durch das Senden einer präparierten Payload kann ein Angreifer eine 'Prototype Pollution'-Schwachstelle herbeiführen, die die Kernverhalten von JavaScript-Objekten modifiziert und letztendlich Befehle verkettet, um Code auf dem Server auszuführen.

Ist eine WAF ausreichend, um meine Anwendung vor React2Shell zu schützen?

Nein. Während Web Application Firewalls (WAFs) von Anbietern wie Vercel und Cloudflare bekannte Angriffsarten blockieren können, sind sie keine vollständige Lösung. Angreifer können oft Payloads verschleiern, um WAF-Regeln zu umgehen. Die einzige zuverlässige Lösung besteht darin, Ihre React- und Next.js-Abhängigkeiten auf gepatchte Versionen zu aktualisieren.