Skip to main content

Sicherheitshinweis: Kritische RCE-Schwachstellen in React Server Components (CVE-2025-55182)

Artikel von
blog feature security alert purple

3. Dezember 2025

0 Min. Lesezeit

Kurzfassung

Am 3. Dezember 2025 wurde koordiniert offengelegt, dass mehrere Releases von React 19 und Next.js eine kritische Schwachstelle im „Flight“-Protokoll von React Server Components (RSC) enthalten, die unauthentifizierte Remote Code Execution (RCE) ermöglicht. Ursache der Schwachstelle ist die unsichere Deserialisierung von angreifergesteuerten Daten bei der serverseitigen Verarbeitung von RSC-Payloads.
Für einen Angriff genügt eine manipulierte HTTP-Anfrage. Die Schwachstelle lässt sich in Standardkonfigurationen zuverlässig ausnutzen und betrifft nicht nur React und Next.js, sondern auch alle Frameworks und Bundler, die die RSC-Implementierung einbetten.
Patches sind verfügbar und sollten sofort installiert werden. Systeme mit ungepatchten Versionen sind einer vollständigen Serverkompromittierung ausgesetzt.

Aktualisierung (5. Dez. 2025):

Der ursprüngliche Meldende dieser Schwachstelle, Lachlan Davidson, hat seine ursprünglichen PoCs auf GitHub veröffentlicht.

Überblick über die betroffene Komponente

React Server Components (RSC) und das „Flight“-Protokoll

Mit React 19 wurde ein Mechanismus eingeführt, der die UI-Darstellung zwischen Client und Server aufteilt. Dabei werden der Komponentenstatus und Aufrufe von Serverfunktionen über ein spezielles Transportformat serialisiert, das häufig als „Flight“-Protokoll bezeichnet wird.

Zu den betroffenen Paketen gehören:

  • react-server-dom-webpack

  • react-server-dom-parcel

  • react-server-dom-turbopack

Diese Pakete deserialisieren eingehende RSC-Payloads, um serverseitige Vorgänge weiterzuleiten. Die Schwachstelle entstand, weil die Deserialisierungslogik strukturelle und typbezogene Einschränkungen nicht ausreichend durchsetzte. Dadurch konnten schädliche Payloads das Ausführungsverhalten verändern.

Warum die Standardkonfiguration betroffen war

Die meisten Frameworks, die RSC verwenden – darunter der Next.js App Router –, liefern diese Logik standardmäßig aktiviert aus. Das bedeutet: Ein mit create-next-app erstelltes, gebautes und bereitgestelltes Next.js-Standardprojekt war ohne Codeänderungen und bei Standardeinstellungen angreifbar.

Bekannte Ereignisse im Zeitverlauf

Datum

Ereignis

29. Nov. 2025

Sicherheitsforscher Lachlan Davidson meldet vertraulich eine Schwachstelle darin, wie React Payloads dekodiert, die an Endpunkte für Serverfunktionen gesendet werden. Er identifiziert einen Angriffsweg für unauthentifizierte RCE.

30. Nov. 2025

Das Sicherheitsteam von Meta bestätigt die Meldung und arbeitet mit der React-Entwicklungsgruppe an einer Lösung.

1. Dez. 2025

Ein Patch wird entwickelt. Große Ökosysteme und Hosting-Anbieter beginnen mit der Umsetzung von Gegenmaßnahmen und der Validierung von Updates.

3. Dez. 2025

Das Meta-/React-Team veröffentlicht einen Sicherheitshinweis zu CVE-2025-55182, der die React-RSC-Pakete betrifft.

3. Dez. 2025

Vercel veröffentlicht einen Sicherheitshinweis zu CVE-2025-66478, der die Next.js-Integration derselben zugrunde liegenden Schwachstelle betrifft.

3. Dez. 2025

Aktualisierte Releases für React (19.0.1 / 19.1.2 / 19.2.1) und Next.js (gepatchte 15.x/16.x sowie Hinweise zum Downgrade für Canary-Nutzer) werden öffentlich verfügbar.

Ab 3. Dez. 2025

Das Ökosystem zieht mit Paketupdates nach (Vite RSC, Parcel RSC, React-Router-Vorschauen, RedwoodSDK, Waku usw.). Die Untersuchungen dauern an.

4. Dez. 2025

Die CVE-Kennung CVE-2025-66478 wurde zurückgezogen und durch CVE-2025-55182 ersetzt.

Hinweis: Bis zur Offenlegung wurden keine Angriffe in freier Wildbahn öffentlich bestätigt. Für einen Angriff ist jedoch nur sehr wenig technisches Können erforderlich.

Betroffene Komponenten

Betroffene React-Versionen

  • 19.0.0

  • 19.1.0

  • 19.1.1

  • 19.2.0

Betroffene Next.js-Versionen

  • Alle stabilen 15.x-Versionen

  • Alle stabilen 16.x-Versionen

  • Experimentelle Versionen ab 14.3.0-canary.77

Weitere Tools und Frameworks sind aufgrund der Einbindung von RSC wahrscheinlich ebenfalls betroffen:

  • Vite-RSC-Plugin

  • Parcel-RSC-Plugin

  • React-Router-RSC-Vorschau

  • RedwoodSDK

  • Waku

  • Jedes Paket, das die verwundbaren react-server-dom-*-Module einbettet

Auswirkungen auf die Cloud

Laut Forschungsergebnissen liefen bei etwa 39 % der untersuchten Cloud-Umgebungen Workloads mit verwundbaren React-/Next.js-RSC-Versionen.

So kam es zum Vorfall

Ursache der Schwachstelle: unsichere Deserialisierung

Im Kern akzeptiert die serverseitige RSC-Engine einen serialisierten „Flight“-Payload, der Folgendes beschreibt:

  • Komponentengrenzen

  • Referenzen auf Serverfunktionen

  • Datenströme

Die verwundbaren Implementierungen vertrauten der eingehenden Struktur zu stark. Wurden fehlerhafte, aber syntaktisch gültige Payloads übermittelt, tat der Server Folgendes:

  1. Unerwartete Objektstrukturen oder Referenzen wurden nicht zurückgewiesen.

  2. Vom Angreifer bereitgestellte Bezeichner wurden verarbeitet.

  3. Privilegierte JavaScript-Ausführungspfade wurden ausgeführt, obwohl sie nie von außen erreichbar sein sollten.

Dies führt direkt zu Remote Code Execution vor der Authentifizierung – daher liegt der CVSS-Score bei 10,0 (kritisch).

Angriffsvektor

  • Remote: Kein lokaler Zugriff und keine Zugangsdaten erforderlich

  • Unauthentifiziert: Jede Person kann einen Angriff versuchen

  • Eine Anfrage: Eine manipulierte HTTP-Anfrage an einen RSC-Endpunkt genügt

  • Hohe Zuverlässigkeit: Tests berichten von nahezu 100 % Zuverlässigkeit bei Standardkonfigurationen

Warum die Schwachstelle besonders gefährlich ist

  • Die meisten Next.js-Apps mit App Router machen RSC-Endpunkte öffentlich zugänglich.

  • Die RCE erfolgt vor jeglicher Routing-Logik oder Authentifizierungsprüfung.

  • Bei Cloud- und serverlosen Bereitstellungen liegen RSC-Endpunkte häufig an der Wurzel ihrer API-Oberflächen.

Empfehlungen zur Erkennung und Überprüfung

Für Code- und Abhängigkeitsscanner

Achten Sie auf:

  • Versionen von "react-server-dom-webpack": 19.0.0, 19.1.0, 19.1.1 und 19.2.0

  • Versionen von "react-server-dom-parcel": 19.0.0, 19.1.0, 19.1.1 und 19.2.0

  • Versionen von "react-server-dom-turbopack": 19.0.0, 19.1.0, 19.1.1 und 19.2.0

  • Die im Abschnitt zu betroffenen Versionen aufgeführten Next.js-Versionen

Für Laufzeit- und Netzwerküberwachung

Melden Sie:

  • Anfragen an RSC-Routen mit fehlerhaften oder unerwarteten RSC-Flight-Frames

  • Payloads mit hoher Entropie oder ungewöhnlichen Tokens in serialisierten RSC-Daten

  • Plötzliche Zunahmen von Fehlern bei Aufrufen von Serverfunktionen

Für Cloud-Posture-Tools

Suchen Sie nach Workloads mit:

  • Containern, die vor dem 3. Dez. 2025 erstellt wurden

  • Noch nicht gepatchten React-19- oder Next.js-15/16-Images

  • Öffentlich zugänglichen Workloads mit App Router oder Server Actions

Bei Apps auf Vercel sorgen Filter auf Plattformebene für zusätzlichen Schutz. Upgrades sind dennoch erforderlich.

Hinweise zur Behebung

1. Sofort aktualisieren 

React

  • 19.0.0 → 19.0.1

  • 19.1.x → 19.1.2

  • 19.2.0 → 19.2.1

Next.js

Gepatchte Versionen:

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7
  • Canary-Nutzer → Wenn Sie Version 14.3.0-canary.77 oder höher verwenden, führen Sie ein Downgrade auf eine stabile Version durch:

npm install next@14

2. Anwendungen nach dem Upgrade neu erstellen

Stellen Sie sicher, dass CI/CD-Pipelines Docker-Images oder serverlose Bundles mit dem gepatchten Abhängigkeitsgraphen neu erstellen.

3. Frameworks von Drittanbietern überprüfen

Wenn Sie Redwood, Waku, experimentelle RSC-Vorschauen oder Bundler verwenden, überprüfen Sie Folgendes:

  • Eine aktualisierte RSC-Implementierung wurde bereitgestellt.

  • Keine veralteten Lockfiles legen verwundbare Versionen fest.

4. Schutzmaßnahmen nach dem Defense-in-Depth-Prinzip aktivieren

  • Laufzeit-Sandboxing für serverseitiges JavaScript

  • Striktes Routing für RSC-Endpunkte

  • Web Application Firewall (WAF)-Regeln zur Erkennung fehlerhafter RSC-Payloads

Nächste Schritte für die Community

Für Maintainer abhängiger Ökosysteme

  • Prüfen Sie alle benutzerdefinierten RSC-Erweiterungen.

  • Veröffentlichen Sie aktualisierte Sicherheitshinweise und gepatchte Builds.

  • Ziehen Sie in Betracht, Deserialisierungsschemas durch explizite Validierung abzusichern.

Für Unternehmen

  • Erfassen Sie alle Workloads, die React Server Components verwenden.

  • Priorisieren Sie Apps mit Internetzugriff.

  • Überwachen Sie verdächtige Aktivitäten im Vorfeld des Patch-Zeitraums.

  • Führen Sie nach dem Patch eine forensische Untersuchung durch, um sicherzustellen, dass kein Angriff stattgefunden hat.

Fazit

Dieser Vorfall verdeutlicht eine systemische Herausforderung moderner JavaScript-Ökosysteme: Hochdynamische Serialisierungsmechanismen können zu wirksamen RCE-Angriffsvektoren werden, wenn die Validierung unzureichend ist. Da React Server Components in immer mehr Frameworks zur Grundlage werden, ist die Reichweite dieser Schwachstelle ungewöhnlich groß.

Die Schwachstelle lässt sich leicht beheben, doch Verzögerungen erhöhen das Risiko erheblich. Unternehmen sollten jetzt ein Upgrade durchführen, abhängige Frameworks überprüfen und die weitere Entwicklung der Untersuchungen im Ökosystem verfolgen.

Warten Sie mit der Behebung nicht länger. Prüfen Sie jetzt die Snyk-Sicherheitshinweise, um betroffene Versionen zu bestätigen und alle Informationen zur Behebung zu erhalten:

Entdecken Sie die Snyk Vulnerability DB

Verlässliche Daten und konkrete Erkenntnisse, damit Sie Software sicher entwickeln können.

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Ihr Schwachstellen-Backlog ist keine technische Schuld mehr, sondern eine Angriffsfläche

Ein wachsender Schwachstellen-Backlog ist mehr als eine technische Altlast: Er ist eine Angriffsfläche. Erfahren Sie, warum veraltete Risikoeinschätzungen, automatisierte Angreifer und verkettete Findings einen neuen Ansatz erfordern.