React2Shell: Patch-Kette prüfen und Angriffe erkennen

Ist deine React- oder Next.js-Anwendung betroffen?

Maßgeblich ist der aufgelöste Paketstand im ausgelieferten Artefakt. Verwundbar sind serverseitige Deployments, die eine betroffene Version eines react-server-dom-*-Pakets enthalten und RSC-Endpunkte oder Server Functions bereitstellen. Reine Client-Anwendungen ohne RSC-fähiges Framework, einen entsprechenden Bundler oder ein solches Plugin nutzen diesen Angriffsweg nicht.

Ein Eintrag in package.json reicht für die Bewertung nicht aus. Die vollständige npm-Auflösung erfasst auch Pakete, die ein Framework oder Plugin transitiv installiert hat:

npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack --all
npm explain react-server-dom-webpack
npm explain react-server-dom-parcel
npm explain react-server-dom-turbopack

npm explain zeigt den Pfad vom Projekt bis zum RSC-Paket. Das Team prüft außerdem package-lock.json, pnpm-lock.yaml oder yarn.lock. Ein Versionsbereich in package.json belegt nicht, welche Version der Paketmanager installiert hat.

Direkte und transitive Abhängigkeiten unterscheiden

Direkte Abhängigkeiten stehen im Manifest des Projekts. Transitive Abhängigkeiten gelangen beispielsweise über Next.js, einen Bundler oder ein RSC-fähiges Plugin in den Paketbaum. Das manuelle Entfernen eines Unterpakets kann die Framework-Auflösung beschädigen. Das Team aktualisiert deshalb die Abhängigkeit, die das betroffene Paket verwaltet.

Die Prüfung schließt das Produktionsartefakt ein. Bei einem Container lässt sich npm ls im laufenden Pod ausführen, sofern Image und Laufzeitumgebung npm enthalten. Distroless-Images enthalten häufig weder npm noch eine Shell. Dann belegt eine während des Builds erzeugte CycloneDX- oder SPDX-SBOM den Paketstand. Alternativ untersucht ein externer Image-Scanner das fertige Image.

Der Next.js App Router nutzt React Server Components. Seine Bewertung umfasst deshalb die Framework-Version, die React-Version und das serverseitige Ausführungsmodell. Die Schulung zum Next.js-React-Framework behandelt das Zusammenspiel von App Router, Server Components und Client Components. Die React-Grundlagen-Schulung grenzt Client Components, Hooks und serverseitige Komponenten voneinander ab.

Die Versionsmatrix verbindet den ausgelieferten Paketstand mit der Release-Linie, für die das Team den vollständigen Patch-Stand bestimmen muss.

Den vollständigen Patch-Stand bewerten

Die RSC-Paketversionen 19.0.1, 19.1.2 und 19.2.1 schlossen die ursprüngliche RCE CVE-2025-55182. Zur Patch-Kette gehören außerdem CVE-2025-55183 wegen möglicher Quellcodeoffenlegung sowie die Denial-of-Service-Schwachstellen CVE-2025-55184, CVE-2025-67779 und CVE-2026-23864.

Reicht React 19.2.1 als Patch-Stand?

React 19.2.1 schließt CVE-2025-55182, enthält aber nicht die später veröffentlichten Korrekturen. Für die drei betroffenen Release-Linien enthalten 19.0.4, 19.1.5 und 19.2.4 alle in diesem Artikel aufgeführten Fehlerbehebungen. Eine neuere Korrekturversion innerhalb derselben Release-Linie hat Vorrang.

Das Sicherheitsupdate für Next.js muss zur verwendeten Next.js-Release-Linie passen. Framework-Updates können eigene Mindestversionen, Backports und geänderte transitive Abhängigkeiten mitbringen. Der Freigabenachweis nennt deshalb die Next.js-Version, react, react-dom und jedes vorhandene react-server-dom-*-Paket. Mit diesen Zielständen beginnt der Neuaufbau der Artefakte.

Abhängigkeiten aktualisieren und Images neu bauen

In Rollouts sehe ich regelmäßig, dass die Lockdatei bereits aktualisiert ist, während alte Container oder Node.js-Prozesse weiterlaufen. Der Update-Branch muss den neuen Abhängigkeitsbaum festschreiben, über die freigegebene npm-Registry installieren und ein neues Artefakt erzeugen.

Für ein Next.js-Projekt kann der Ablauf so aussehen. Die Platzhalter werden durch die für die jeweilige Release-Linie freigegebenen Versionen ersetzt:

npm install --package-lock-only next@<freigegebene-version> react@<zielversion> react-dom@<zielversion>
rm -rf node_modules .next
npm ci
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack --all
docker build --pull --no-cache -t app:<neue-version> .

Wenn das Framework die RSC-Pakete transitiv verwaltet, aktualisiert das Team das Framework und prüft den aufgelösten Paketbaum. Ein erzwungenes Überschreiben des Unterpakets ohne Kompatibilitätstest kann einen inkonsistenten Build erzeugen.

• Der Container-Build verwendet keine alten Build-Layer oder Paketkopien
• Der Rollout beendet alte Pods, Container und Node.js-Prozesse
• Das Team sperrt verwundbare Image-Digests gegen eine erneute Bereitstellung
• Das Team sichert verdächtige Artefakte vor dem Löschen für die forensische Analyse

Nach dem Rollout prüft das Team den effektiven Paketstand im laufenden Pod, Container oder Server. Der Image-Digest, die SBOM oder die Ausgabe von npm ls sowie der Rollout-Zeitpunkt gehören in den Änderungsnachweis. Dieser Laufzeitstand bestimmt den Zeitraum und die Systeme für die Kompromittierungsprüfung.

Eine bestehende Kompromittierung untersuchen

Ein Update entfernt weder eine Webshell noch ein angelegtes Benutzerkonto oder ein gestohlenes Cloud-Token. Die rückwirkende Analyse beginnt mit dem ersten Zeitpunkt, an dem ein verwundbarer Paketstand und die Erreichbarkeit des betroffenen Endpunkts zusammenkamen.

• Das Security-Team korreliert POST-Anfragen an RSC-Endpunkte oder Server Functions mit Node.js-Kindprozessen und ausgehenden Verbindungen im selben Zeitfenster
• Das Team prüft Prozessdaten auf sh, bash, cmd.exe oder powershell.exe als Kindprozess von Node.js
• Das Team sucht in DNS- und Verbindungsprotokollen nach unbekannten Zielen sowie Zugriffen auf die Metadatenadresse 169.254.169.254
• Die Forensik vergleicht Anwendungsverzeichnisse, temporäre Verzeichnisse, Cron-Konfigurationen und systemd-Units mit dem erwarteten Zustand
• Das Identitäts-Team prüft neue Benutzerkonten, geänderte SSH-Schlüssel und manipulierte Startkonfigurationen
• Das Plattform-Team untersucht Deployment-Tokens, CI/CD-Zugänge und Cloud-Rollen auf Änderungen oder ungewöhnliche Nutzung

Ein erfolgreicher Prozessstart konnte auf Umgebungsvariablen, lokale Konfigurationsdateien und Cloud-Metadatendienste zugreifen. Betroffen sein können API-Schlüssel, Passwörter und private Signaturschlüssel. Lässt sich ein Zugriff nicht ausschließen, widerruft das Team die Geheimnisse und stellt sie neu aus. Eine Passwortänderung ersetzt weder ein API-Token noch ein privates Schlüsselpaar.

Vor dem Aufräumen sichert die Incident Response die Reverse-Proxy- und WAF-Logs, die Anwendungs- und Container-Logs sowie die Cloud-Audit-Logs. Festplatten-Snapshots und verdächtige Images bewahren den Systemzustand, während Dateihashes und Prozessdaten die spätere Zeitleiste stützen.

Decken die Protokolle den Expositionszeitraum nicht vollständig ab, lässt sich eine Ausnutzung allein mit den verbleibenden Daten nicht ausschließen. Methoden für Log-Korrelation, Forensik und Reaktion vertiefen die IT-Security-Trainings. Lücken in Protokollierung und Aufbewahrung fließen anschließend in die Pipeline- und Plattformkontrollen ein.

Die nächste Lücke in der Patch-Kette verhindern

Ein Scan von package.json übersieht den tatsächlich ausgelieferten Stand, wenn Lockdatei und Produktionsimage fehlen. Die CI/CD-Pipeline muss direkte und transitive RSC-Pakete erfassen.

• Die Pipeline scannt das Manifest, die Lockdatei und das Produktionsimage
• Eine CycloneDX- oder SPDX-SBOM erfasst Frameworks, Bundler, Plugins und transitive RSC-Pakete
• Der Patch-SLA nennt die Frist und das verantwortliche Team für kritische Schwachstellen
• Das Security-Ticket bleibt offen, bis das Team nachgelagerte Sicherheitshinweise geprüft hat
• Regressionstests prüfen RSC-Endpunkte, Server Functions und den Paketstand des fertigen Artefakts

Supertest oder Playwright senden gültige und fehlerhafte Server-Anfragen an eine isolierte Testumgebung. Die Prozessüberwachung erfasst, ob Node.js eine Shell startet oder unerwartete Netzwerkverbindungen öffnet. Die React-Schulung für Fortgeschrittene zu Redux, Routing und Testing behandelt Regressionstests und die API-Integration in größeren React-Projekten.

Das Entwicklungsteam aktualisiert die Abhängigkeiten, während das Plattform-Team Build und Rollout verantwortet. Application Security bewertet die Exposition und die Kompromittierungsindikatoren. Pipeline- und Deployment-Verfahren behandeln die DevOps-Schulungen. Die Versionsmatrix nennt für jeden Dienst ein verantwortliches Team, damit neue CVE-Hinweise ohne erneute Zuständigkeitssuche bearbeitet werden.

Am Ende muss die freigegebene Version mit dem Paketstand im tatsächlich laufenden Image übereinstimmen.

Fazit: Laufzeitstand nachweisen

React2Shell ist erst erledigt, wenn Paketstand, Artefakt und Incident-Prüfung zusammenpassen. Dokumentiere für jedes RSC-Deployment den aufgelösten Paketstand, die Zielversion, den Image-Digest und den Rollout-Zeitpunkt in der Versionsmatrix.