• Node.js
• npm

Installation

[!NOTE] Die package.json ist auf die verwundbare Version 19.0.0 gepinnt.

Proof of Concept

1. Starten Sie den verwundbaren Server

Dieses Skript richtet einen rohen HTTP-Server ein, der die verwundbare React-Laufzeit zum Dekodieren von Anfragen verwendet.

2. Führen Sie das Exploit-Skript aus

Führen Sie in einem separaten Terminal den Exploit aus. Dieser sendet eine bösartige Flight-Payload an den Server.

Sie sollten die Befehlsausgabe in der Antwort sehen:

Erwartete Ausgabe:

Analyse

Warum ist die Schwachstelle aufgetreten?

Die Funktion requireModule in ReactFlightDOMServerNode.js hat im Grunde jedem name vertraut, den der Client gesendet hat. Sie führte moduleExports[metadata[NAME]] aus, ohne zu prüfen, ob diese Eigenschaft tatsächlich exponiert werden sollte. Wenn der Client also sagte: „Alter, ich will diese Eigenschaft“, antwortete der Server einfach: „Klar, kein Problem! Hier hast du sie, Kumpel.“

Warum ist es eine schlechte Idee, Menschen Zugriff auf beliebige Eigenschaften zu geben?

Weil dadurch jeder in die Prototypenkette eindringen kann, sogar auf den constructor, was extrem gefährlich ist. Wenn das Modul zufällig eine Funktion exportiert (wie module.exports = () => {}), dann ist dessen constructor buchstäblich der globale Function-Konstruktor.

Warum bedeutet der Zugriff auf den Function-Konstruktor RCE?

Sobald ein Angreifer den Function-Konstruktor in die Hände bekommt, kann er die Funktion „Bound Server Action“ missbrauchen. Er bindet eine Zeichenkette mit bösartigem JavaScript daran (was im Grunde zu new Function("evil code") wird). Und sobald das ausgeführt wird, führt der Server jeden Code aus, den sie hineingelegt haben.

Warum würde React diese bösartige Funktion tatsächlich ausführen?

Weil Server Actions per ID ausgelöst werden können. Wenn der Angreifer eine Payload mit einer Action-ID erstellt, die auf seine module#constructor-Referenz zeigt, löst React sie wie eine normale Aktion auf und führt sie aus. Diese „Aktion“ ist eigentlich seine bösartige Funktion.

Warum wurde das alles nicht validiert?

Das System ging einfach davon aus, dass sich id und name aus den Server-Referenz-Metadaten immer auf gültige, vom Entwickler definierte Exporte beziehen. Es gab keine Sicherheitsprüfung wie hasOwnProperty, um sicherzustellen, dass die angeforderte Eigenschaft ein echter Export ist und nicht etwas, das von der Prototypenkette geerbt wurde.

Warum server.js statt Next.js?

Ich verwende ein rohes server.js (und ein Hilfsskript webpack-runtime.js), um die React-Server-Components-Laufzeit manuell zu konfigurieren. Das erlaubt uns:

1. Das verwundbare Setup erzwingen: Der Exploit funktioniert nur, wenn ein Modul als Funktion exportiert wird (module.exports = fn)s. Ein echtes Bundler-Tool könnte je nach Konfiguration ändern, wie Exporte verpackt werden.
2. Den Fehler isolieren: So können wir zeigen, dass das Problem in react-server-dom-webpack liegt, nicht in Next.js.
3. Die Bundler-Umgebung nachbilden: react-server-dom-webpack geht davon aus, dass es in einem Webpack-Bundle läuft. Unser webpack-runtime.js liefert die erwarteten Globals (__webpack_require__, __webpack_chunk_load__). Das ist kein Mocking der Schwachstelle, sondern gibt der Bibliothek nur die minimale Laufzeit, die sie tatsächlich benötigt, um zu funktionieren.

Anmerkungen

Es gab Diskussionen über „Invalid PoCs“, die nur funktionieren, wenn der Entwickler absichtlich gefährliche Dinge wie child_process.exec exponiert.

Dieser PoC gehört nicht dazu. Er funktioniert mit einem normalen, sicheren Setup.

1. Die exponierte Funktion ist harmlos Die App exponiert eine einfache updateProfile-Funktion, die nur eine Zeichenkette zurückgibt und nichts Verdächtiges, keine Shell-Befehle.

2. Der Exploit entkommt dieser Funktion vollständig Die Schwachstelle erlaubt es dem Angreifer, den sicheren Export zu ignorieren und direkt zu updateProfile.constructor zu springen, also dem globalen Function-Konstruktor.

3. Das Kernproblem ist der Eigenschaftszugriff React hätte den Zugriff auf .constructor NICHT erlauben dürfen. Der Entwickler hatte nicht vor, den Function-Konstruktor zu exponieren – stattdessen hat die unsichere Deserialisierung das für ihn übernommen.

Die einzige wirkliche Voraussetzung ist, dass das Modul eine Funktion direkt exportiert (module.exports = fn), was in CommonJS und vielen Bundler-Setups sehr üblich ist.

Die Payload

Die Payload in exploit.js erstellt eine React-Flight-Nachricht mit drei Chunks:

• Chunk 0: Verweist auf eine Server-Referenz, die in Chunk 1 definiert ist.
• Chunk 1: Deklariert die Server-Referenz:
  • id: "user-profile-action#constructor", also „gib mir den Konstruktor“.
  • bound: verweist auf Chunk 2, der die Argumente enthält.
• Chunk 2: ["console.log('nice try, diddy!')"]: die bösartige Code-Zeichenkette.

Wenn React dies deserialisiert:

1. Es löst user-profile-action auf.
2. Liest die .constructor-Eigenschaft => erhält den globalen Function-Konstruktor.
3. Bindet die vom Angreifer bereitgestellte Zeichenkette daran.
4. Führt effektiv aus: new Function("console.log('nice try, diddy!')")

Und das ist die RCE!

Gegenmaßnahmen

Aktualisieren Sie sofort auf die gepatchten Versionen:

• react-server-dom-webpack >= 19.0.1
• react-server-dom-parcel >= 19.0.1
• react-server-dom-turbopack >= 19.0.1

Der Patch fügt hasOwnProperty-Prüfungen hinzu, um den Zugriff auf geerbte Eigenschaften zu verhindern, und schränkt base64-Datei-Uploads ein.

Wenn Sie diesen PoC gegen eine gepatchte Version ausführen, stürzt der Server ab oder gibt einen Fehler aus:

Dies bestätigt, dass der Exploit nicht auf die constructor-Eigenschaft zugreifen konnte (sie gab undefined statt Function zurück) und daher der anschließende .bind-Aufruf fehlschlug.

Haftungsausschluss

Dieser Code dient nur zu Bildungs- und Testzwecken. Verwenden Sie diesen Exploit nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben.

Lizenz

Veröffentlicht unter der DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE.