React RCE-Schwachstelle (CVE-2025-55182): Was war das Problem und warum trat es auf?

React RCE-Schwachstelle (CVE-2025-55182) – Problem und Ursache

Im frühen Dezember 2025 wurde die React Server Components-Schwachstelle (CVE-2025-55182, auch bekannt als React2Shell / React4Shell) veröffentlicht. Sie wurde mit CVSS 10.0 bewertet und ermöglicht Remote-Code-Ausführung (RCE) ohne vorherige Authentifizierung. Bereits gibt es veröffentlichte PoCs sowie beobachtete Scans und Angriffe.

Dieser Beitrag fasst „Wer, warum und wie gefährlich?“ systematisch zusammen.

Überblick in Kürze

• Kernproblem Der Fehler liegt in der Flight-Protokoll-Deserialisierung von React Server Components (RSC). Ein manipuliertes Request kann dazu führen, dass auf dem Server beliebiger JS-Code ausgeführt wird.

• Betroffene Hauptkomponenten

• react-server-dom-webpack / -parcel / -turbopack 19.0 / 19.1.0 / 19.1.1 / 19.2.0

• Integrierte Next.js 15.x, 16.x, 14.3.0‑canary.77 und höher (bei Verwendung des App Router)

• Reine Client‑React‑Apps Anwendungen, die ausschließlich im Browser laufen und weder RSC, Server Actions noch Server‑Rendering nutzen, sind nicht betroffen.

• Was tun, wenn Sie Next.js verwendet haben? 1. Prüfen Sie die Versionen von react-server-dom-* und next in Ihrem Projekt. 2. Aktualisieren Sie React auf ≥ 19.0.1 / 19.1.2 / 19.2.1. 3. Aktualisieren Sie Next.js auf die gepatchten Versionen (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) oder downgraden Sie auf eine stabile Version. 4. Prüfen Sie bei öffentlich zugänglichen Servern Logs, WAF‑Regeln und andere Anomalien.

Was genau ist die Schwachstelle?

Zusammengefasst: Die Schwachstelle betrifft die React Server Components (RSC) Implementierung (react-server-dom-*). Sie liegt im Flight‑Protokoll‑Decoding (Deserialisierung), das Client‑seitig gesendete Daten an den Server übergibt.

• Angriffsmethode 1. Angreifer sendet einen spezialisierten Flight‑Payload an die RSC/Server Actions HTTP‑Endpunkte. 2. Der Server „vertraut“ diesem Payload und deserialisiert ihn. 3. Durch unsichere Modul‑Lade‑ und Objekt‑Erstellungslogik kann der Angreifer beliebigen Code ausführen.

Wichtig: Der Angriff ist unauthenticated – ohne Login oder Session. Jeder öffentlich zugängliche Next.js RSC‑Server ist sofort ein Ziel.

Konkrete Bedingungen für die Ausnutzung

1. Versionsbedingungen

2. Architektur‑/Runtime‑Bedingungen

Die Schwachstelle ist nur dann ausnutzbar, wenn alle folgenden Bedingungen erfüllt sind: 1. RSC wird verwendet (z. B. Next.js App Router oder ein anderes RSC‑fähiges Framework). 2. React‑Code läuft auf dem Server (Node.js, etc.). 3. Der Server ist über HTTP von außen erreichbar (Internet oder internes Netzwerk).

Nicht betroffen: * CRA/Vite‑basierte reine Client‑React‑SPAs * Projekte, die RSC/Server Actions nicht nutzen und nur statische Bundles auf S3/CDN hosten * Architekturen, bei denen React ausschließlich im Browser läuft und der Server ein separater Tech‑Stack ist (z. B. React + Django REST, React + FastAPI)

Warum sind React‑DRF und React‑FastAPI Kombinationen relativ sicher?

In einer Architektur, in der React mit Django REST Framework oder FastAPI kombiniert wird, läuft React nicht auf dem Server. Der Server kommuniziert lediglich über JSON/HTTP‑APIs. Dadurch: 1. Der Server muss das Flight‑Protokoll nicht verstehen. 2. Es gibt keine RSC‑Logik auf dem Server. 3. Die Kommunikationsgrenzen sind klar definiert.

Die Schwachstelle existiert also nur in Next.js‑ähnlichen Setups, wo React‑Serialisierung/Deserialisierung tief in den Server‑Code eingreift.

Flight‑Protokoll und Prototype‑Pollution

Technisch gesehen folgt die Schwachstelle dem klassischen Muster: Flight‑Protokoll‑Deserialisierung → Prototype‑Pollution → RCE.

1. Problematischer Code‑Pattern

// Schwacher Code (konzeptionell)
export function requireModule<T>(metadata: ClientReference<T>): T {
  const moduleExports = parcelRequire(metadata[ID]); // Modul laden
  return moduleExports[metadata[NAME]];              // Client‑Input unverändert nutzen
}

• metadata[ID]: Welches Modul geladen werden soll
• metadata[NAME]: Welches Export des Moduls verwendet wird

Hier wird metadata[NAME] ohne Validierung benutzt. Wenn ein Angreifer __proto__ oder constructor übergibt, kann er die Objekt‑Prototype‑Kette manipulieren.

2. Prototype‑Pollution → RCE

Wenn ein Objekt mit einem manipulierten Prototype erstellt wird, erben neue Objekte die schädlichen Eigenschaften. Wenn dort z. B. spawnSync('sh') eingebunden ist, kann ein Angreifer mit einem einzigen HTTP‑Request Remote‑Code ausführen.

Was wurde tatsächlich gepatcht?

Der Kern des Patches besteht darin, Client‑seitige Eingaben nicht blind zu vertrauen. Die requireModule‑Funktion wurde wie folgt geändert:

// Nach Patch (konzeptionell)
export function requireModule<T>(metadata: ClientReference<T>): T {
  const moduleExports = parcelRequire(metadata[ID]);
  if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
    return moduleExports[metadata[NAME]];
  }
  return undefined as any;
}

Durch diese Prüfung werden Schlüssel wie __proto__ oder constructor blockiert, da sie keine eigenen Eigenschaften sind. Damit wird die Hauptangriffs‑Route geschlossen.

Zusätzlich wurden: * Strengere Validierung der Flight‑Payload‑Struktur * Beschränkung gefährlicher Felder * Weitere defensive Logik in relevanten Code‑Pfaden

Strukturkonflikte durch die Server‑Erweiterung von React

React war ursprünglich eine Browser‑UI‑Bibliothek. Mit RSC und Server Actions wurde es zu einer Full‑Stack‑Komponente. Next.js integriert diese Features, sodass Client‑Daten direkt die Server‑Modul‑Lade‑Logik beeinflussen.

Das führte zu einem Missverhältnis im Sicherheitsmodell: Front‑End‑Annahmen (statischer, unveränderlicher Bundle) wurden auf den Server übertragen, wo sie nicht mehr gelten. Die Lösung erfordert neue Sicherheitsmodelle: * Strenge Schema‑Validierung der Flight‑Payload * Whitelist‑basierte Zugriffskontrolle * Signatur/Integritätsprüfung (z. B. HMAC) * Annahme, dass RSC immer untrusted Input erhält

Fazit: Grenzen zwischen Front‑ und Backend verschwimmen – Sicherheitsmodelle neu denken

Die React/Next.js‑Schwachstelle zeigt, dass ein Front‑End‑Framework, das auf dem Server ausgeführt wird, neue Angriffsflächen eröffnet. Traditionelle Architekturen wie React + DRF/FastAPI bleiben sicher, weil die beiden Schichten klar getrennt sind.

Für zukünftige Frameworks, die Front‑ und Backend nahtlos verbinden, gilt: Sicherheitsmodelle und Vertrauensannahmen müssen von vornherein neu definiert werden. Die Behebung dieser Schwachstelle ist ein Beispiel dafür, wie wichtig es ist, die Grenzen zwischen Client und Server konsequent zu berücksichtigen.