Denial of service and source code exposure in React Server Components

Security impact and patching

• React disclosed new RSC vulnerabilities: denial of service and source code exposure in the server components protocol.
• The new issues affect the patches from the previous week; projects that already upgraded must upgrade again.
• Some note npm audit and GitHub advisories lag behind, so tools may say “no issues” while upgrades are still required.
• There’s debate over messaging: some see the “follow‑up CVEs are common” line as defensive perception management; others view it as reasonable context.
• Several commenters question why the DoS issue is rated more severe than source code exposure, arguing breaches are usually worse than downtime.

Concerns about RSC design and security model

• Many criticisms center on RSC blurring client/server boundaries, making it hard to know what runs where and how data flows.
• RSC requires a custom deep (de)serialization/RPC protocol, seen as opaque and risky, especially given JavaScript’s dynamic features (prototypes, Function from string, Promise hijacking).
• Some argue these bugs validate earlier worries that tightly coupling client and server in one codebase is an architectural foot‑gun that will keep surfacing vulnerabilities.
• Others stress that the main problems so far are in the serializer, not in static client/server separation, and claim the surface area is now relatively fixed.

React/Next complexity, docs, and developer experience

• Multiple people say RSC and the Next.js App Router dramatically increased complexity compared to the older Pages router or classic SPA setups.
• Complaints include: unclear execution environment, awkward constraints, difficulty debugging, and an “impenetrable” codebase with heavy vendoring.
• There’s frustration with React’s documentation pace and Next’s tendency to expose experimental React features as “the new standard.”
• Some, however, report great productivity with RSC/App Router, appreciating the ability to avoid REST/GraphQL layers and write “URL → HTML” directly.

Architectural philosophy and alternatives

• A large contingent calls for returning to clearer separations: server-rendered HTML (Rails, Laravel, Django, etc.) plus light JS or JSON APIs for SPAs.
• Others defend server‑driven UI (e.g., Phoenix LiveView, Blazor, Hotwire, Inertia) as reducing duplication and client/server drift, at the cost of latency and server resources.
• There’s recurring criticism that React/Next/Vercel are driven by ecosystem lock‑in and hosting incentives, not just technical merit, while Meta itself does not yet use RSC.
• Many suggest simpler stacks—traditional SSR, htmx, Inertia.js, Vue/Svelte, Remix/TanStack, or plain SPAs—as safer, more understandable defaults for most apps.