Der Fehler existiert in den Paketen react-server-dom-webpack, react-server-dom-turbopack und react-server-dom-parcel von React. Next.js als der dominierende RSC‑Konsument erbt die Schwachstelle durch seinen App Router.

Wer ist betroffen?

Viele Dienste sind potenziell verwundbar. Next.js ist eines der beliebtesten React‑Frameworks und wird von Unternehmen jeder Größe eingesetzt – von Startups bis zu Großunternehmen. Der App Router mit React Server Components ist seit Version 13 die Standardarchitektur für neue Next.js‑Projekte, daher sind die meisten modernen Next.js‑Bereitstellungen betroffen.

Jede Anwendung, die Folgendes verwendet:

• React Server Components mit verwundbaren react-server-dom-*‑Paketen (19.0.0 – 19.2.0)
• Next.js App Router der Versionen 15.x (vor 15.0.5) und 16.x (vor 16.0.7)

Dies umfasst Produktionsbereitstellungen auf Vercel, AWS, selbst gehosteter Infrastruktur und überall dort, wo Next.js App Router‑Anwendungen ausgeführt werden.

Nicht betroffen:

• Next.js Pages Router‑Anwendungen (kein RSC)
• Stabile Releases von Next.js 13.x und 14.x
• Anwendungen, die nur clientseitiges React‑Rendering verwenden
• Edge Runtime‑Bereitstellungen (kein process.mainModule verfügbar)

Betroffene Versionen

React Server Components

Next.js

Abhilfe

Sofort aktualisieren. Es gibt keine Workarounds.

Für Next.js‑Anwendungen:

Für die direkte Nutzung von React RSC:

Überprüfen Sie Ihre installierten Versionen:

Wie der Exploit funktioniert

Voraussetzungen für den Exploit

1. Ein Server, der verwundbare React Server Components ausführt (über Next.js App Router oder direkte RSC‑Nutzung)
2. Netzwerkzugriff zum Senden einer HTTP‑POST‑Anfrage
3. Das war’s. Keine Authentifizierung. Kein spezifischer Endpunkt. Jede Route funktioniert.

Der Angriff

Es wurden mehrere Angriffsvektoren für diese Schwachstelle entdeckt. Der häufigste – und derjenige, der ohne Voraussetzungen funktioniert – nutzt Prototyp‑Verschmutzung über das Flight‑Protokoll‑Referenzsystem von React.

Der Exploit sendet eine maßgeschneiderte Multipart‑POST‑Anfrage mit einem Next‑Action‑Header. Die Payload missbraucht das Referenzsystem, um:

1. Die Prototypenkette über $1:__proto__:then zu traversieren
2. Ein gefälschtes „Chunk“‑Objekt zu konstruieren, das Reacts interne Chunk‑Klasse nachahmt
3. Den Deserialisierer dazu zu bringen, den JavaScript-Function‑Konstruktor aufzurufen
4. Beliebigen Code auszuführen, wenn die resultierende Funktion als Promise‑Thenable aufgerufen wird

Der Code wird während der Deserialisierung ausgeführt, bevor eine Validierung der Aktions‑ID erfolgt. Das bedeutet, dass jeder Next‑Action‑Header‑Wert den verwundbaren Codepfad auslöst – es ist keine gültige Aktions‑ID erforderlich.

Andere Angriffsvektoren existieren, darunter $F‑Funktionsreferenzen und direkte Modul‑Gadgets. Diese erfordern in der Regel eine gültige Aktions‑ID. Siehe Alternative Angriffsvektoren für Details.

Die Ursache

Das Flight‑Protokoll von React löst Referenzen wie $1:path:to:value auf, indem es an Doppelpunkten trennt und das Objekt traversiert:

Die Ironie: Ganz oben in derselben Datei, Zeile 35:

root@kitploit:~

import hasOwnProperty from 'shared/hasOwnProperty';

Die Absicherung wurde importiert. Sie war verfügbar. Sie wurde nur nicht in der einen Schleife verwendet, in der sie am wichtigsten gewesen wäre.

Diese einzelne fehlende Prüfung erlaubt es, mit $1:__proto__:then von einem Chunk‑Objekt aus die Prototypenkette hinauf zu Chunk.prototype.then zu gelangen – einer Funktion, die Promise‑ähnliche Objekte verarbeitet. Indem ein gefälschter Chunk mit den richtigen Eigenschaften erstellt wird, wird kontrolliert, welcher Code ausgeführt wird.

Lokale Reproduktion

Klonen Sie den verwundbaren Testserver:

In einem anderen Terminal:

Ein verwundbarer Server antwortet mit HTTP 500 und E{"digest" im Antworttext. Um RCE zu demonstrieren:

Die Befehlsausgabe erscheint in der Antwort. Für interaktive Erkundung:

Was in diesem Repository enthalten ist

Verwundbarer Testserver

Das Verzeichnis vulnerable-next-server/ enthält eine vorkonfigurierte Next.js‑16.0.6‑Anwendung mit React 19.2.0 für sicheres lokales Testen. Sie läuft standardmäßig auf Port 3443. Es handelt sich um eine minimale App‑Router‑Einrichtung, die demonstriert, dass Standardkonfigurationen verwundbar sind.

Exploit‑Skripte

Wir haben mehrere Exploit‑Varianten entwickelt, um verschiedene Szenarien abzudecken:

Produktionshinweis: React entfernt Fehlermeldungen in Produktions‑Builds, was die throw‑Methode unbrauchbar macht. Nur exploit-redirect.sh erfasst zuverlässig Befehlsausgaben in der Produktion ohne Voraussetzungen. Die Weiterleitungs‑URL wird in der digest‑Eigenschaft (Metadaten) des Fehlers gespeichert, die nicht bereinigt wird – im Gegensatz zu message, das in der Produktion nur {digest: "..."} wird.

Hilfsskripte:

• detect.sh – Zerstörungsfreie Schwachstellensonde (keine Code‑Ausführung)
• enumerate-actions.sh – Ermittelt gültige Server‑Action‑IDs aus der Ziel‑HTML
• exfil-file.sh – Chunkweise Dateiexfiltration (behandelt große Dateien automatisch)
• shell.sh – Interaktive Pseudo‑Shell über RCE

Die Redirect‑Methode wird empfohlen, weil sie in der Produktion funktioniert, keine Voraussetzungen erfordert und die Befehlsausgabe direkt zurückgibt. Sie funktioniert, indem ein speziell präparierter NEXT_REDIRECT‑Fehler ausgelöst wird – die Ausgabe wird base64‑kodiert in die Weiterleitungs‑URL eingebettet und im x‑action‑redirect‑Header zurückgegeben.

Ausführliche Nutzungshinweise zu jedem Skript finden Sie in USAGE.md.

So erkennen Sie verwundbare Server

Schnellerkennung

Dies sendet eine minimale Sonde, die den verwundbaren Codepfad auslöst, ohne beliebigen Code auszuführen.

Antwort eines verwundbaren Servers:

• HTTP‑Status: 500
• Content‑Type: text/x-component
• Antworttext enthält: E{"digest"

Gepatchter Server oder Server ohne RSC: Antwortet mit 404, einem anderen Fehlerformat oder keiner Flight‑Protokoll‑Antwort.

Manuelle Erkennung

Diese Sonde referenziert eine nicht vorhandene Eigenschaft auf einem leeren Objekt. Verwundbare Server stürzen beim Zugriff auf {}.a.a ab und antworten mit 500. Gepatchte Server haben eine hasOwnProperty‑Absicherung, die den Absturz verhindert.

Identifizierung des Next.js App Router

Achten Sie auf diese Indikatoren:

• RSC‑Payload in HTML: <script>‑Tags, die Flight‑Protokoll‑Daten enthalten (0:, 1:, usw.)
• x-nextjs-cache- oder x-nextjs-matched-path‑Header
• /_next/‑Pfade für statische Assets
• Server‑Action‑IDs in HTML: $ACTION_ID_‑Muster in versteckten Formularfeldern

Technischer Tiefgang

Der Angriffsablauf

Das folgende Diagramm zeigt, wie eine einzelne HTTP‑Anfrage eine Remote‑Code‑Ausführung erreicht:

Das Flight‑Protokoll

React Server Components verwenden ein eigenes Serialisierungsformat namens „Flight“, um Komponentenbäume vom Server zum Client zu streamen. Es verwendet Präfixcodes für verschiedene Werttypen:

• $1, $2, … – Referenzen auf andere Chunks per ID
• $@0 – Roh‑Chunk‑Objekt‑Referenz (liefert den Chunk selbst zurück, nicht seinen Wert)
• $B0 – Blob‑Referenz (löst _formData.get(_prefix + id) aus)
• $1:path:to:prop – Durchläuft einen Pfad auf dem Wert eines referenzierten Chunks

Die Schwachstelle nutzt die Kombination aus $@ (Rohreferenz) und durch Doppelpunkte getrennten Pfaden, um auf __proto__ zuzugreifen.

Die vollständige Angriffskette

Phase 1: Anfrageverarbeitung

1. POST mit Next-Action‑Header löst die RSC‑Aktionsverarbeitung aus
2. Busboy parst Multipart‑Formularfelder in den Chunk‑Speicher
3. await getRoot(response) gibt Chunk 0 als Thenable zurück

Phase 2: Prototyp‑Traversierung

4. Chunk hat eine then‑Methode – die JS‑Promise‑Spezifikation ruft thenable.then(resolve, reject) auf
5. Unsere Payload wird geparst; $1:__proto__:then löst zu Chunk.prototype.then auf
6. Gefälschtes Chunk‑Objekt mit then, status: "resolved_model" und _response wird erstellt

Phase 3: Code‑Ausführung

7. resolve(ourObject) löst einen weiteren then()‑Aufruf aus (JS‑Thenable‑Spezifikation)
8. Chunk.prototype.then wird mit unserem kontrollierten _response‑Objekt ausgeführt
9. $B0 löst _formData.get(_prefix + "0") aus – beides vom Angreifer kontrolliert
10. Konstruierte Funktion wird als Thenable aufgerufen → RCE

Phase 4: Ausgabe‑Exfiltration (optional, Redirect‑Methode)

11. Payload löst NEXT_REDIRECT‑Fehler mit base64‑kodierter Befehlsausgabe aus
12. Next.js fängt den Redirect ab, setzt x-action-redirect‑Header vor URL‑Validierung
13. HTTP 303 wird an den Angreifer zurückgesendet, Ausgabe im Header

Strategien zur Ausgabenerfassung

Die konstruierte Funktion wird als Thenable aufgerufen: fn(resolve, reject). Wie wir dies handhaben, bestimmt, ob wir eine Ausgabe zurückbekommen:

Empfohlen: Redirect. Funktioniert in Produktion, keine Voraussetzungen, Ausgabe im x‑action‑redirect‑Header.

Der Blind‑Ansatz bleibt hängen, weil das Promise nie erfüllt wird – await blockiert dauerhaft. Dies ist nützlich für Feuer‑und‑vergessen‑Szenarien (Reverse Shells, Out‑of‑Band‑Exfiltration via curl).

Alternative Angriffsvektoren

Die Kernschwachstelle wurde über drei verschiedene Angriffsklassen ausgenutzt. Dieses Repository verwendet den ersten Ansatz; andere PoCs demonstrieren die Alternativen:

Warum Prototyp‑Verschmutzung keine Aktions‑ID benötigt: Die Multipart‑Formularanalyse speist Chunks sofort in den Flight‑Deserialisierer ein. RCE tritt in getOutlinedModel() während der Chunk‑Referenzauflösung auf – bevor Next.js die Aktions‑ID validiert. URL‑kodierte Anfragen validieren die Aktions‑ID zuerst (anderer Codepfad in action-handler.ts:768).

Warum die $F‑Referenz eine Aktions‑ID benötigt: Die $F‑Referenz löst loadServerReference() aus, das eine Manifest‑Suche durchführt. Wenn die Aktion nicht existiert, schlägt die Anfrage fehl, bevor Code ausgeführt wird.

Eine detaillierte Analyse aller PoC‑Implementierungen und ihrer Vor‑/Nachteile finden Sie in external-pocs/COMPARISON.md.

Produktion vs. Entwicklung

React entfernt Fehlerdetails in Produktions‑Builds. Dies betrifft die Throw‑basierte Exfiltration:

Entwicklung:

Produktion:

Die Redirect‑Methode umgeht dies, da die Weiterleitungs‑URL in der digest‑Eigenschaft gespeichert wird, nicht in message. Der Header wird bedingungslos vor der URL‑Validierung gesetzt, sodass selbst ungültige URLs den Header erhalten.

Danksagungen

Die entscheidende Exploit‑Erkenntnis – die Verwendung von $@‑Roh‑Chunk‑Referenzen zur Erstellung eines selbstreferenziellen Fake‑Chunks – wird maple3142 zugeschrieben. Die hier referenzierte Erkennungsmethodik stammt von Searchlight Cyber / Assetnote.

Referenzen

Offizielle Bekanntmachungen:

• CVE-2025-55182 – RCE in React Server Components
• CVE-2025-66478 – Auswirkungen auf Next.js
• React Security Advisory – Offizielle React‑Bekanntgabe

Community‑Forschung:

Einen detaillierten Vergleich aller PoC‑Implementierungen finden Sie in external-pocs/COMPARISON.md.

Hintergrund:

• React Flight Protocol – RSC‑Serialisierung verstehen

Lizenz

Der Code ist unter der MIT‑Lizenz lizenziert. Die Dokumentation (*.md‑Dateien) ist unter CC‑BY‑SA 4.0 lizenziert.