CVE-2025-55182 wird mit 10.0/10.0 Schweregrad bewertet. Wenn Sie sich die öffentlichen PoCs angesehen haben, ist Ihnen vielleicht aufgefallen, dass sie zwar zeigen, wie der Exploit funktioniert, die Erklärungen dafür, warum der Payload so aussieht, wie er aussieht, jedoch unzureichend wirken können – was angesichts der Komplexität des React Flight Protocol durchaus sinnvoll ist. Flight, die Serialisierungsschicht hinter React Server Components und Server Actions, ist eine komplizierte Zustandsmaschine mit über 1.100 Zeilen, deren Verhalten nicht intuitiv ist, es sei denn, man verfolgt den Code selbst.

Die Community-PoCs demonstrieren die Schwachstelle deutlich:

• https://github.com/msanft/CVE-2025-55182
• https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc
• https://x.com/rauchg/status/1997362942929440937

…aber wenn man versucht, die Frage "Warum funktioniert das?" zu beantworten, findet man sich schnell tief in den React-Interna wieder, die nie dafür gedacht waren, Zeile für Zeile gelesen zu werden.

Hinweis: Viele PoCs schreiben die Behebung fälschlicherweise Änderungen in requireModule zu. Wie wir in Die Behebung sehen werden, erreicht der Exploit-Payload diese Funktion nie – der tatsächlich anfällige Code befindet sich vollständig in ReactFlightReplyServer.js.

Dieser Artikel ist mein Versuch, die Exploit-Kette durch schrittweises Nachvollziehen der Decodierungs- und Chunk-Initialisierungslogik von React zu reverse-engineeren. Jedes hier besprochene Verhalten stammt direkt aus der Funktionsweise von ReactFlightReplyServer.js vor der Behebung (Referenz: https://github.com/facebook/react/blob/v19.2.0/packages/react-server/src/ReactFlightReplyServer.js), destilliert und vereinfacht, damit ein React/JS-Entwickler mit ausreichend Geduld folgen kann.

Nächster Abschnitt: Hintergrund