Neues zu DoS- und Quellcodeoffenlegungs-Schwachstellen in React Server Components

• In React Server Components wurden neue Denial-of-Service (DoS)- und Quellcodeoffenlegungs-Schwachstellen entdeckt und veröffentlicht
• Für diese Schwachstellen ist Remote Code Execution (RCE) nicht möglich, dennoch besteht ein Risiko von Serverausfällen oder Codelecks
• Betroffene Pakete sind react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack in den Versionen 19.0.0~19.2.2; als gefixte Versionen gelten 19.0.3, 19.1.4, 19.2.3
• Die DoS-Schwachstellen (CVE-2025-55184, CVE-2025-67779) können durch bösartige HTTP-Anfragen eine Endlosschleife auslösen, und die Quellcodeoffenlegungs-Schwachstelle (CVE-2025-55183) kann Teile des Codes von Serverfunktionen zurückgeben
• Das React-Team empfiehlt ein sofortiges Upgrade und erklärt diese zusätzliche Offenlegung als normalen Teil des Sicherheitsreaktionszyklus

---

Überblick über die neu veröffentlichten Schwachstellen

• Sicherheitsforscher entdeckten bei der Verifikation des in der Vorwoche veröffentlichten Patches für kritische Schwachstellen zwei zusätzliche Probleme
• Für die neuen Schwachstellen ist Remote Code Execution (RCE) nicht möglich; der bisherige React2Shell-Patch ist weiterhin wirksam
• Die neu veröffentlichten Schwachstellen sind folgende
  • Denial-of-Service (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, hohe Schwere)
  • Quellcodeoffenlegung — CVE-2025-55183 (CVSS 5.3, mittlere Schwere)
• Das React-Team empfiehlt ein sofortiges Upgrade

Unvollständigkeit des bisherigen Patches

• Der in der Vorwoche bereitgestellte Patch in den Versionen 19.0.2, 19.1.3, 19.2.2 war unvollständig und muss erneut aktualisiert werden
• Der vollständige Fix ist in 19.0.3, 19.1.4, 19.2.3 enthalten
• Den Update-Anweisungen aus dem vorherigen Beitrag ist zu folgen
• Weitere Details werden nach der Bereitstellung der Korrektur veröffentlicht

Betroffene Pakete und Versionen

• Die Schwachstellen betreffen dieselben Pakete und Versionen wie CVE-2025-55182
• Betroffene Versionen: 19.0.0~19.2.2
• Betroffene Pakete:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Gefixte Versionen: 19.0.3, 19.1.4, 19.2.3
• Anwendungen, die keinen Server einsetzen oder React Server Components nicht unterstützen, sind nicht betroffen

Typisches Muster nachfolgender Offenlegungen

• Nach der Veröffentlichung einer kritischen CVE werden in der Zusatzanalyse betroffener Codepfade häufig weitere Schwachstellen gefunden
• Als Beispiel wird auf zusätzliche CVEs nach Log4Shell verwiesen
• Solche zusätzlichen Offenlegungen bedeuten, dass die Sicherheitsreaktion korrekt funktioniert

Betroffene Frameworks und Bundler

• Die folgenden Frameworks und Bundler enthalten oder hängen von den betroffenen React-Paketen ab:
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• Den Update-Anweisungen aus dem vorherigen Beitrag ist zu folgen

Milderungsmaßnahmen durch Hosting-Anbieter

• Mit mehreren Hosting-Anbietern wurden temporäre Milderungsmaßnahmen umgesetzt
• Dennoch sollte man sich nicht auf diese Maßnahmen verlassen und ein sofortiges Update durchführen

Hinweise zu React Native

• Für reine React Native-Nutzung ist keine zusätzliche Maßnahme erforderlich
• In einem Monorepo sind nur die folgenden Pakete zu aktualisieren:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• react und react-dom müssen nicht aktualisiert werden
• Weitere Details sind in der React Native GitHub-Issue dokumentiert

Hohe Schwere: Denial-of-Service (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• Wird eine bösartige HTTP-Anfrage an den Server-Funktionsendpunkt von React gesendet, kann im Deserialisierungsschritt eine Endlosschleife entstehen
• Der Serverprozess kann abstürzen und übermäßig viel CPU-Ressourcen nutzen
• Auch ohne direkte Implementierung eines Endpunkts für Serverfunktionen kann eine App betroffen sein, sofern sie React Server Components unterstützt
• Der heute bereitgestellte Patch behebt das Problem durch Verhinderung der Endlosschleife
• Die erste Korrektur war unvollständig und wurde durch die zusätzliche Schwachstelle (CVE-2025-67779) ergänzt

Mittlere Schwere: Quellcodeoffenlegung

• CVE-2025-55183, CVSS 5.3
• Eine bösartige HTTP-Anfrage kann Teile des Quellcodes von Serverfunktionen zurückgeben
• Das tritt auf, wenn Serverfunktionen String-Argumente explizit oder implizit offenlegen
• In Beispielcode können hartkodierte Geheimwerte wie Datenbank-Verbindungsschlüssel offengelegt werden
• Der Patch behebt dies durch Verhinderung der Stringifizierung des Serverfunktions-Quellcodes
• Der Offenlegungsbereich ist auf den internen Code von Serverfunktionen beschränkt; Runtime-Geheimnisse wie process.env.SECRET sind nicht betroffen
• Die Verifikation sollte anhand von Produktions-Bundles erfolgen

Zeitplan

• 3. Dezember: Andrew MacPherson meldete die Quellcodeoffenlegung bei Vercel und der Meta Bug Bounty
• 4. Dezember: RyotaK meldete die DoS-Schwachstelle
• 6. Dezember: Das React-Team bestätigte beide Probleme und begann die Untersuchung
• 7. Dezember: Erstellen eines initialen Fixes und Aufstellen eines Verifizierungsplans
• 8. Dezember: Benachrichtigung von Hosting-Anbietern und Open-Source-Projekten
• 10. Dezember: Umsetzung von Milderungsmaßnahmen und Abschluss der Patch-Verifizierung
• 11. Dezember: Shinsaku Nomura meldete zusätzliche DoS-Schwachstelle; Veröffentlichung von CVE-2025-55183, CVE-2025-55184 und CVE-2025-67779

Meldende Personen

• Andrew MacPherson (AndrewMohawk) — Meldung zur Quellcodeoffenlegung
• RyotaK (GMO Flatt Security Inc) und Shinsaku Nomura (Bitforest Co., Ltd.) — Meldung zur DoS-Schwachstelle

[GN⁺]

Hacker-News-Kommentare

• React Server Components (RSC) haben sich für mich immer unbehaglich angefühlt
  weil man allein am JavaScript-Code schwer erkennen kann, welche Teile auf dem Client und welche auf dem Server laufen
  Außerdem braucht die Umsetzung einen tiefgreifenden serialisierten RPC-Mechanismus, der für Entwickler intransparent ist und das Risiko von Sicherheitslücken erhöht

  • Zu Zeiten des NextJS pages router war die Grenze zwischen Server- und Client-Code klar, das war gut
    Aber mit dem app router wurde es verwirrend. Weil Code auf beiden Seiten laufen kann, sind Objekte wie Headers nicht immer vorhanden, und es ist schwer zu erkennen, was wo ausgeführt wird
  • Ich habe in einem neu zusammengestellten Team gesehen, dass Next verwendet wird, und gefragt: „Weiß jemand, wie das hier funktioniert?“ Niemand konnte es klar erklären
    Wenn React+Next gut funktioniert, wirkt es wie Magie, aber bei Teamarbeit geht Vorhersehbarkeit immer mehr verloren, und das ist das Problem
  • Deshalb bin ich ein Fan von Inertia.js. Inertia.js verbindet traditionelle MVC-Backends wie Laravel, Rails und Django auf natürliche Weise mit Frontend-Tools wie React, Vue und Svelte
    Die Rollen sind klar, die Arbeit ist einfach, und ich halte es bei den meisten Projekten für die sicherste Wahl
  • Es wirkt so, als seien RSC und SSR übermäßig stark übernommen worden
    Für Landingpages oder Marketingseiten ist SSR nützlich, aber bei Apps wie gewöhnlichen SaaS-Dashboards gibt es im Verhältnis zur Komplexität kaum Nutzen
  • Ich frage mich, wie stark andere Frameworks (Angular, SvelteKit, Nuxt) solchen Schwachstellen ausgesetzt sind
    Ist React nur stärker im Fokus, weil es so populär ist, oder ist es strukturell riskanter?

• Ich habe mir letzte Woche RSC angesehen, und die Komplexität war extrem hoch, während es kaum Dokumentation gab
  React bezeichnet es noch als experimentelles Feature, aber NextJS hat es bereits breit ausgerollt
  Ich denke, es werden noch mehr Sicherheitsprobleme auftauchen, und das Build-System von Next war so komplex, dass selbst Debugging schwierig war
  Die Kosten sind im Verhältnis zum Nutzen viel zu hoch

  • Es gab schon länger Beschwerden darüber, dass Next „React-Features, die noch nicht produktionsreif sind“, als neueste Features verkauft
    Deshalb habe auch ich Next verlassen. Die kognitive Belastung war zu hoch, für zu wenig Gewinn
  • React hat schon lange ein Problem mit mangelnder Dokumentation
    Nicht nur bei RSC, auch allgemein kamen klare Leitfäden spät, und Werkzeuge wie CRA wurden nicht einmal offiziell anerkannt
    Erst jetzt ist die Dokumentation zu useEffect besser geworden, aber viel zu spät
    Selbst jetzt, im Jahr 2025, nutze ich es in der Praxis, und es fehlt weiterhin an klarer Dokumentation

• Der Kern von SPA war ursprünglich: „Die gesamte App an den Client senden und mit dem Server nur Daten austauschen“

  • Im C#-Umfeld ist derzeit aber Blazor Server populär
    Wie früher bei .aspx Web Forms wird jeder Klick und jede Eingabe an den Server geschickt, und das geänderte DOM wird wieder zurückgesendet
    Im Grunde ist man zu der alten Methode zurückgekehrt, was etwas absurd wirkt
  • Letztlich haben viele Entwickler die Gründe für Server-Side Rendering wiederentdeckt und sind zu Full-Stack-Frameworks wie PHP, Rails und Spring zurückgekehrt
  • Gleichzeitig werden heute mit Bibliotheken wie React oft statische Websites gebaut, was langsamer und komplexer ist als die Kombination aus einfacher Template-Engine + JS
    Schade, dass das Gespür dafür verloren gegangen ist, „das passende Werkzeug zu wählen“
  • Natürlich ist RSC nicht für reine SPAs gedacht. Es ist ein Ansatz mit einem anderen Ziel

• In dieser Sicherheitsmitteilung fiel mir am stärksten der Satz auf, dass „wenn eine kritische CVE entdeckt wird, oft nachfolgende Schwachstellen sichtbar werden“
  Das wirkte beunruhigend, weil es so aussah, als wolle man die CVE rechtfertigen, noch bevor Umfang, Auswirkungen oder Gegenmaßnahmen erklärt werden

  • Andere sehen das aber so: Das ist keine Rechtfertigung, sondern einfach eine Erklärung für den Punkt, den die Leute zuerst wissen wollen
  • Es heißt, die Formulierung sei nach Feedback geändert worden → Link zum überarbeiteten PR
  • Jemand bezeichnete das als perception management
    Passender Wikipedia-Artikel
  • Es gibt auch die Sichtweise, dass in dieser Angelegenheit karrierebezogene Interessen mit hineinspielen
  • Manche meinten: „Das liest sich, als hätte es das Marketingteam von Vercel geschrieben“

• Bereits vor 15 Jahren gab es bei Opa einen ähnlichen Versuch
  Client- und Server-Code wurden automatisch getrennt, und eine JSX-ähnliche Syntax wurde eingeführt
  Doch als die Sicherheitsanalyse verstärkt wurde, wurde der Compiler riesig, und am Ende erkannte man, wie wichtig eine klare Trennung statt des Konzepts einer einzelnen App ist
  Vielleicht erzeugen LLMs solchen Code eines Tages automatisch, aber im Moment halte ich einfachere Strukturen für besser

  • Tatsächlich hängen die Schwachstellen bei RSC weniger mit Code-Splitting zusammen als mit den dynamischen Eigenschaften des Serialisierungs-/Deserialisierungsprozesses
    Es wird bereits an Patches gearbeitet, um Probleme wie Prototype Pollution in JS, function toString und Promise-Overrides zu verhindern
    RSC trennt Umgebungen durch statische Prüfung wie import "server-only" oder import "client-only", also ist es strukturell ein sicherer Ansatz
  • Ein ähnliches Projekt ist Electric Clojure → Link
  • Zur Einordnung: Ocsigen Eliom hat solche Konzepte schon vor Opa ausprobiert

• React war ursprünglich gut, als es klein und einfach die View in MVC war
  Heute hat es zu viele Funktionen und wirkt aufgebläht

  • RSC ist allerdings eine separate Bibliothek und nicht Teil einer Standardinstallation von React
  • Wer zu einer älteren Version zurück will, braucht nur git checkout v15.0.0

• RSC hätte von Anfang an nicht existieren sollen
  Für die meisten Apps reicht es völlig, HTML auf dem Server zu rendern, und nur für einen kleinen Teil ist eine SPA wirklich nötig
  RSC hat nur Komplexität und Sicherheitslücken vergrößert

  • Stimme zu. Aber Bootcamps und von VC-Geld angetriebene Ökosysteme treiben diese Richtung weiter voran
    Projekte wie Bun und Vercel verkaufen die Illusion einer JS-Utopie, in der alles perfekt funktioniert, deshalb wird dieser Trend wohl nicht so schnell verschwinden

• Ich hatte früher auf X eine Diskussion mit Dan Abramov über RSC
  Er nannte es ein innovatives Feature, ich dagegen eine „Waffe, mit der man sich selbst in den Fuß schießt“. Am Ende ist es genau so gekommen

  • Ich habe persönlich eine App mit RSC gebaut und mag den Ansatz immer noch
    Allerdings habe ich die Möglichkeit von Bugs auf Protokollebene unterschätzt. Diese Schwachstellen konzentrieren sich auf das Serialisierungsprotokoll
    Die Security-Community schaut jetzt erst richtig tief hinein, und es wäre gut gewesen, wenn das Team früher reagiert hätte
  • Erfolgreiche Systeme werden am Ende leicht durch übermäßige Erweiterung zu Monstern
    Auch React ist von einer einfachen Rendering-Bibliothek zu einer Runtime geworden, wodurch die Komplexität explodiert ist
  • Persönlich halte ich Dans Ansatz nicht für besonders stark
    Vue und Vite wirken dagegen viel eleganter entworfen → Evan Yous persönliche Website
  • Natürlich scheitern die meisten Ideen, daher sollte man sich auch vor einer Haltung hüten, die nur kritisiert
    Manchmal wird ein mutiger Versuch eben doch ein Volltreffer
  • Es gab auch einen aufmunternden Kommentar: „Vielleicht bist du ja der Fähigere“

• Wenn RSC der Versuch ist, dass das Frontend das Backend verschlingt, dann ist HTMX das Gegenteil
  HTMX hält die Grenze zwischen Client und Server aufrecht, wodurch das Backend sicherer bleibt, aber im Frontend besteht ein XSS-Risiko

  • HTMX hat das XSS-Problem jedoch bereits über automatisches Escaping in der Template-Engine gelöst
    Dazugehöriger Artikel

• Das Next-Team hat ein neues Sicherheitsupdate veröffentlicht → NextJS Security Update 2025-12-11
  Betroffen sind die Versionen 14.x, 15.x und 16.x