✉️info@mh-service.de | 📞+49 (7275) 9692381
Kontakt EN DE
Kritische RCE · CVSS 10.0 · Aktive Ausnutzung

React2Shell – kritische RCE-Schwachstelle in React Server Components & Next.js

React2Shell (CVE-2025-55182, vormals teilweise als CVE-2025-66478 bei Next.js geführt) ist eine pre-auth Remote-Code-Execution-Schwachstelle im Flight-Protokoll der React Server Components. Eine einzelne HTTP-Anfrage kann zur vollständigen Kompromittierung des Servers, zum Zugriff auf Secrets und zu Folgeschäden bei Ihren Kunden führen. Inzwischen wurden mit CVE-2025-55183, CVE-2025-55184 und CVE-2025-67779 weitere Schwachstellen bekannt – frühe Patches (z. B. 19.2.2) gelten für DoS-Szenarien als unzureichend.

24/7 Hotline anrufen Incident-Response-Support anfragen
10+ Jahre Incident Response & DFIR EU-basiertes Digital-Forensics- & IR-Team React / Next.js / moderne Web-Stacks Stand: 15. Dez 2025
CVE
CVE-2025-55182 (React2Shell)
CVE-2025-55183 (Infoleak)
CVE-2025-55184, CVE-2025-67779 (DoS)
Next.js-CVE CVE-2025-66478 wurde als Duplikat von 55182 markiert.
Bewertung
CVSS 10.0 (kritisch)
Angriffstyp
Pre-auth RCE via unsichere Deserialisierung im Flight-Protokoll
Status
Massenscans & Ausnutzung durch mehrere Gruppen;
frühe DoS-Patches unzureichend – aktuelles Ziel: React 19.2.3
(Stand ca. 15. Dez 2025)

Executive Summary

Was ist React2Shell?

React2Shell ist eine Schwachstelle in der Art und Weise, wie React Server Components Daten vom Client entgegennehmen und verarbeiten. Angreifer können speziell präparierte Flight-Payloads senden, die interne Strukturen manipulieren – bis hin zur Ausführung von Angreifer-Code im Kontext des Server-Prozesses.

Wer ist betroffen?

Betroffen sind Anwendungen, die React Server Components in verwundbaren Versionen nutzen – direkt oder über Frameworks wie Next.js (App Router), React Router mit RSC, Waku, RSC-Plugins für Parcel/Vite oder Redwood/Expo. Klassische „Client-only“ React-SPAs ohne RSC-Server sind von dieser konkreten Schwachstelle nicht betroffen.

Warum ist es jetzt besonders kritisch?

Die Schwachstelle ist ohne Authentifizierung über das Netz ausnutzbar und betrifft einen weit verbreiteten Technologie-Stack. Inzwischen liegen mehrere Folge-CVEs vor, frühe Patches wurden für DoS-Szenarien als unzureichend identifiziert, und Threat-Intelligence-Berichte zeigen Kampagnen mit Tunneler-Malware (MINOCAT), Downloadern (SNOWLIGHT), Backdoors (HISONIC, COMPOOD), Linux-Implants (ANGRYREBEL.LINUX) und Kryptominern (XMRig).

Timeline (vereinfacht)

  1. Ende November 2025

    Verantwortungsvolle Meldung

    Sicherheitsforscher Lachlan Davidson meldet eine kritische Schwachstelle im Flight-Protokoll der React Server Components an das React/Meta-Team.

  2. 3. Dezember 2025

    Öffentliche Advisories & erste Patches

    React veröffentlicht ein Advisory zu CVE-2025-55182; Next.js publiziert ein eigenes Advisory (CVE-2025-66478). Erste gepatchte Versionen der RSC-Pakete und von Next.js werden veröffentlicht.

  3. Kurz nach Disclosure

    PoCs & automatisierte Scans

    Erste – teils fehlerhafte – Proof-of-Concepts tauchen auf GitHub und in Foren auf. Sicherheitsanbieter beobachten automatisierte Internet-Scans nach verwundbaren Next.js/RSC-Anwendungen.

  4. Folgende Tage

    Ausnutzung „in the wild“

    Threat-Intelligence-Feeds berichten über aktive Ausnutzung – von opportunistischen Kryptominern bis zu mutmaßlich staatlich unterstützten Gruppen, die Backdoors und Tunnel einsetzen.

  5. 12. Dezember 2025

    Google GTIG: mehrere Kampagnen & Malware-Familien

    Google Threat Intelligence beschreibt konkrete Kampagnen: MINOCAT-Tunneler, SNOWLIGHT-Downloader (Teil von VSHELL), COMPOOD-Backdoor, aktualisierte HISONIC-Implants und ANGRYREBEL.LINUX, plus XMRig-Kryptomining über Shell-Skripte. Erste detaillierte IoCs wie Domains, IPs und Persistenzmechanismen werden veröffentlicht.

  6. Mitte Dezember 2025

    Weitere CVEs & unzureichender DoS-Patch

    Mit CVE-2025-55183, CVE-2025-55184 und CVE-2025-67779 werden Folge-Schwachstellen veröffentlicht (Information Disclosure und DoS). React 19.2.2 schließt zwar Teile der Probleme, erweist sich aber für DoS als unzureichend – empfohlen wird explizit ein Update auf React 19.2.3.

Betroffene Komponenten & Versionen

React Server Components (RSC)

Die Kernschwachstellen betreffen die React-Server-Bibliotheken, welche das Flight-Protokoll implementieren:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack

Explizit verwundbare Versionen (RCE)

  • 19.0.0
  • 19.1.0
  • 19.1.1
  • 19.2.0

Empfohlene Zielversionen

  • ≥ 19.0.1 / 19.1.2 / 19.2.1 (RCE-Fix für 55182)
  • ≥ 19.2.2 (zusätzlich Infoleak 55183)
  • ≥ 19.2.3 (zusätzlich DoS 55184 & 67779)

Praktisch bedeutet dies: 19.2.3 ist der sinnvolle Mindeststand, wenn Sie React 19 nutzen – frühere „gepatchte“ Versionen decken nicht alle bekannten Probleme ab.

Klassische Client-only-React-Apps ohne RSC-Server sind von React2Shell nicht direkt betroffen, können aber andere Schwachstellen aufweisen.

Next.js & weitere Frameworks

Next.js integriert RSC-Funktionalität und exponiert sie über den App Router und Server Actions – für viele Organisationen die sichtbarste Angriffsfläche. Die ursprüngliche Next.js-CVE CVE-2025-66478 wird inzwischen als Duplikat von CVE-2025-55182 geführt.

Risiko-Releases (vereinfacht)

  • 14.3.0-canary.77+ (bestimmte Canaries)
  • 15.x vor gefixten Stand
  • 16.x vor gefixten Stand

Gepatchte Stände (Beispiele)

  • 15.0.5, 15.1.9, 15.2.6
  • 15.3.6, 15.4.8, 15.5.7
  • 16.0.7
  • 15.6.0-canary.58
  • 16.1.0-canary.12

Wichtig: Auch bei aktuellen Next.js-Versionen sollten Sie verifizieren, dass die transitive Abhängigkeit auf React RSC mindestens 19.2.3 erreicht. Lockfiles und Build-Artefakte spielen hier eine zentrale Rolle.

Weitere betroffene Frameworks & Ökosysteme

Über Next.js hinaus können alle Frameworks betroffen sein, die React Server Components oder das Flight-Protokoll verwenden, u. a.:

React Router (RSC-Modus) Waku @parcel/rsc @vitejs/plugin-rsc RedwoodSDK Expo mit RSC-Support

In SBOMs und SCA-Reports tauchen diese Komponenten häufig nur indirekt als React-Abhängigkeit auf. Eine gezielte Analyse der Dependency-Trees ist daher empfehlenswert.

Angriffspfad – technischer Überblick

Die ursprüngliche Schwachstelle basiert auf unsicherer Deserialisierung von Flight-Payloads im React-Server. RSC-Clients senden strukturierte Daten, die Komponentenbäume und Server-Funktionen repräsentieren. Beim Dekodieren werden bestimmte Strukturen und Schlüssel nicht streng genug validiert. So können Angreifer interne Objekte manipulieren und Codepfade erreichen, in denen ihre Daten letztlich als Code ausgeführt werden.

  1. Identifikation der Endpunkte: RSC-/Server-Action-Endpunkte lassen sich über typische Routen, Response-Header und Framework-Signaturen (z. B. Next.js App Router) ermitteln.
  2. Präparierte Flight-Payload: Statt legitimer Daten sendet der Angreifer eine manipulierte Payload, die interne Typen oder Prototypen „vergiftet“.
  3. Unsicheres Decode & Dispatch: Der Flight-Decoder wandelt die Daten in Objekte um und übergibt sie an Server-Logik. Fehlende Validierung erlaubt es, dass Angreifer-Werte an Stellen landen, die nicht für untrusted Input vorgesehen waren.
  4. Gadget-Chain zur RCE: Über bestehende Codepfade („Gadgets“) lässt sich schließlich beliebiger JavaScript-Code im Kontext des Node/Next.js-Prozesses ausführen.
  5. Post-Exploitation: Typische Schritte sind Zugriff auf Secrets und Datenbanken, Einrichtung persistenter Backdoors, Kryptomining oder laterale Bewegung in interne Netze.
Hinweis zu öffentlichen PoCs: Viele erste PoCs in Repositories waren fehlerhaft oder enthielten KI-generierten Code. Mittlerweile existieren legitime Exploits – teils mit Unicode-Obfuskation oder integrierten Web-Shells. Prüfen Sie PoC-Code vor der Nutzung sorgfältig und führen Sie ihn niemals unreflektiert in produktionsnahen Umgebungen aus.

Beobachtete Kampagnen & Malware-Familien (Auswahl)

Threat-Intelligence-Berichte zeigen, dass React2Shell von mehreren, teils staatlich vermuteten Gruppen sowie von finanziell motivierten Angreifern genutzt wird. Einige besonders relevante Bausteine:

  • MINOCAT-Tunneler: 64-bit-ELF für Linux mit integriertem Fast Reverse Proxy (FRP). Wird über Skripte ausgerollt, die versteckte Verzeichnisse anlegen (z. B. $HOME/.systemd-utils), Prozesse wie ntpclient beenden und systemd-Services sowie Cron-Jobs zur Persistenz anlegen.
  • SNOWLIGHT-Downloader (Teil von VSHELL): Wird über curl/wget nachgeladen und kontaktiert C2-Infrastruktur, u. a. reactcdn.windowserrorapis[.]com, um weitere Payloads abzurufen.
  • COMPOOD-Backdoor: Über Skripte als vermeintliches vim-Binary (z. B. von 45.76.155[.]14) heruntergeladen; tarnt sich als legitimer Prozess, um auf Zielsystemen unauffällig zu bleiben.
  • HISONIC-Implant: Go-basierter Backdoor-Agent, der Konfigurationen über legitime Cloud-Dienste (Cloudflare Pages, GitLab usw.) bezieht und verschlüsselt im Traffic versteckt.
  • ANGRYREBEL.LINUX: Wird u. a. als „gefälschter“ sshd im /etc/-Verzeichnis abgelegt, nutzt Timestomping und löscht Shell-History (z. B. history -c), um Spuren zu verwischen.
  • XMRig-Kryptomining: Opportunistische Angreifer nutzen React2Shell, um via Skripte (z. B. sex.sh) XMRig zu installieren und als Dienst (system-update-service) zu persistieren.

Erkennung & Telemetrie

Infrastruktur- & Runtime-Sicht

  • Prozess-Monitoring: Unerwartete Child-Prozesse (Shells, Kryptominer, Tools), die von Node-/Next.js-Servern gestartet werden.
  • Dateiaktivität: Neue ELF- oder Script-Dateien in Home- oder App-Verzeichnissen, insbesondere in versteckten Ordnern wie $HOME/.systemd-utils.
  • Persistenz-Artefakte: Neue systemd-Services (z. B. system-update-service), Cron-Jobs oder Manipulationen an Shell-Konfigurationen (~/.bashrc etc.).
  • Netzwerkverhalten: Ausgehende Verbindungen von Web-Servern/Containern zu auffälligen Hosts oder Domains (z. B. reactcdn.windowserrorapis[.]com), insbesondere kombiniert mit curl/wget.
  • Security-Sensoren: eBPF-/Syscall-basierte Lösungen (z. B. Falco), EDR und Cloud-Workload-Schutz, die ungewöhnliche Systemcalls, Prozessketten und Netzwerkflüsse aus Next.js-/Node-Prozessen heraus melden.

HTTP, Logs & Applikationssicht

  • HTTP-Muster: Große, binäre oder ungewöhnlich strukturierte Requests auf Routen, die RSC/Server-Actions zugeordnet werden können. Wiederkehrende Muster von wenigen Quell-IPs sind ein besonders starkes Signal.
  • Fehlerbilder: Cluster von 5xx-Fehlern mit RSC/Flight-bezogenen Stacktraces nach dem Zeitpunkt der Disclosure. Insbesondere, wenn diese mit verdächtigen Requests oder Prozessstarts korrelieren.
  • WAF/IDS-Regeln: Aktivieren Sie aktuelle Signaturen Ihrer Anbieter (z. B. Cloud-Armor-Regeln oder vergleichbare WAF-Regeln) und prüfen Sie geblockte Requests gezielt.
  • Threat Hunting: Korrelieren Sie verdächtige HTTP-Requests mit System-Events (Prozessstart, Dateiänderungen, Nutzer-/Rechteänderungen). Besonders wertvoll sind Logs aus Container-Runtimes und Orchestrierungsumgebungen.

Empfohlene Maßnahmen & Priorisierung

1. Patching & Versionsmanagement (höchste Priorität)

  • React aktualisieren: Bringen Sie betroffene RSC-Pakete mindestens auf 19.2.3. Damit schließen Sie RCE (55182), Information Disclosure (55183) und die bekannten DoS-Schwachstellen (55184, 67779). Prüfen Sie Lockfiles und Build-Pipelines ausdrücklich mit.
  • Next.js aktualisieren: Aktualisieren Sie auf eine Version, die die Empfehlungen aus dem offiziellen Next.js-Advisory umsetzt und auf eine nicht verwundbare React-RSC-Version (mindestens 19.2.3) referenziert.
  • Weitere RSC-Frameworks: Folgen Sie den Vendor-Advisories zu React Router, Waku, Redwood, Expo etc. und verifizieren Sie dort ebenfalls, dass die React-RSC-Version konsistent auf dem geforderten Stand ist.
  • Neu bauen & ausrollen: Nach dem Update müssen Artefakte neu gebaut und Deployments ausgerollt werden, damit alte Bundles und Container nicht im Hintergrund weiterlaufen.

2. Härtung & temporäre Schutzmaßnahmen

  • WAF-Regeln: Aktivieren oder ergänzen Sie Regeln, die typische React2Shell-Payloads und verdächtige Flight-Requests blockieren. Nutzen Sie – wo verfügbar – spezifische Reaktionsregeln Ihrer Cloud- oder WAF-Anbieter.
  • Angriffsfläche reduzieren: Deaktivieren Sie nicht benötigte RSC-/Server-Action- Endpunkte, limitieren Sie öffentlich erreichbare Routen und segmentieren Sie interne Admin-/Ops- Oberflächen.
  • Least Privilege: Minimieren Sie Berechtigungen von App-Containern und Service-Accounts. Ein ausgenutzter RSC-Server sollte im Idealfall nicht direkt auf kritische Backend-Systeme oder Produktionsdatenbanken zugreifen können.

3. Forensik & Incident Response

  • Zeitraum definieren: Prüfen Sie Logs und Telemetrie mindestens ab der öffentlichen Disclosure am 3. Dezember 2025 für exponierte Next.js/RSC-Anwendungen.
  • Schwerpunktsetzung: Fokussieren Sie Systeme, in denen gleichzeitig verdächtige HTTP-Requests, neue Prozesse, ungeplante Systemd-Services oder Konfigurationsänderungen sichtbar werden.
  • Im Verdachtsfall: Systeme isolieren, Artefakte sichern (Container-Images, Logs, Memory-Dumps), und strukturiert nach Incident-Response-Playbook vorgehen. Planen Sie ggf. parallele Notfallkommunikation mit Management und Behörden.

FAQ für Kundengespräche

„Wir nutzen React im Frontend – sind wir automatisch betroffen?“

Nicht zwingend. React2Shell betrifft primär React Server Components auf der Serverseite. Klassische SPAs, die ausschließlich im Browser laufen und keinen RSC-Server einsetzen, sind von dieser konkreten Schwachstelle nicht betroffen – auch wenn andere Risiken bestehen können.

„Wir haben bereits gepatcht (19.2.1 oder 19.2.2) – sind wir fertig?“

Wahrscheinlich nicht. Frühere Patches schließen zwar die ursprüngliche RCE, aber erst React 19.2.3 adressiert die bekannten DoS-Probleme und Folge-CVEs vollständig. Sie sollten daher prüfen, ob Ihre Systeme bereits auf 19.2.3 (oder höher) aktualisiert sind und ob diese Version tatsächlich in allen Deployments ausgerollt wurde.

„Gibt es schon echte Angriffe?“

Ja. Mehrere Threat-Intelligence-Berichte dokumentieren aktive Ausnutzung durch China-nexus-Cluster, andere staatlich vermutete Gruppen und finanziell motivierte Angreifer. Der Einsatz reicht von Kryptomining über versteckte Tunnel bis zu persistierenden Backdoors auf Cloud-Infrastruktur.

„Wie priorisieren wir React2Shell gegenüber anderen Schwachstellen?“

Für Internet-exponierte Anwendungen mit React Server Components sollte React2Shell als Top-Priorität (P1) behandelt werden. In Umgebungen ohne RSC-Server sinkt die Priorität, aber das Thema sollte dennoch zeitnah im Rahmen Ihres normalen Patch-Managements adressiert werden.

Wie wir Sie bei React2Shell unterstützen können

Als spezialisiertes Sicherheitsteam helfen wir Organisationen, React2Shell strukturiert und risikobasiert zu bewältigen – von der technischen Analyse bis zur Kommunikation mit Stakeholdern:

  • Remote Discovery & Pre-Assessment: Identifikation von Next.js/RSC-Assets und erste Risikobewertung (z. B. passive Stack-Checks, schonende Remote-Scans).
  • Repository- & Build-Analyse: Untersuchung von Dependencies, Lockfiles und CI/CD-Pipelines, um verwundbare Versionen und RSC-Nutzung aufzuspüren.
  • Patching & Härtung: Unterstützung bei React/Next.js-Upgrades, Konfigurationsanpassungen, WAF-Regeln und Plattform-Härtung – inklusive Fokus auf 19.2.3-Baseline.
  • Detection Engineering & Incident Response: Aufbau von Erkennungsregeln (SIEM, EDR, WAF) und Durchführung von Forensik/IR, falls eine Kompromittierung vermutet wird.

Nächste Schritte für interessierte Organisationen

  1. Kurzes Scoping: Welche Anwendungen nutzen React / Next.js / moderne React-Frameworks – und wo sind sie exponiert (Internet, Partner-Netze, interne Portale)?
  2. Bereitstellung von Basisinformationen (Tech-Stack, Hosting, Cloud/On-Prem-Setup, Logging-/Monitoring-Status, bestehende Security-Tools).
  3. Gemeinsame Priorisierung kritischer Ziele und Planung von Assessment, Patching und – falls nötig – forensischen Maßnahmen inklusive Lessons Learned.

Auf Wunsch stellen wir leichtgewichtige Skripte bereit, mit denen Kunden ihre eigenen Repositories und Deployments auf React2Shell-Exposition prüfen können (z. B. Versionsprüfungen für React-RSC & Next.js).