Critical Next.js RCE via React Server Components—Update Now

Read Articleadded Dec 4, 2025
Critical Next.js RCE via React Server Components—Update Now

A Critical RCE in React Server Components impacts Next.js 15.x and 16.x using the App Router, plus certain 14.3 canary builds. The flaw is exploitable over the network with no privileges or user interaction and carries a CVSS 10.0 score. Fixes are available in React 19.0.1/19.1.2/19.2.1 and Next.js 15.0.5–15.5.7 and 16.0.7; users must upgrade immediately.

Key Points

  • Critical RCE affecting Next.js App Router due to vulnerable React Server Components; CVSS 10.0 with network vector and no user interaction required.
  • Affected: Next.js >=15 and >=16, and canary builds starting 14.3.0-canary.77; also React 19.0.0, 19.1.0, 19.1.1, 19.2.0.
  • Patched Next.js: 16.0.7, 15.5.7, 15.4.8, 15.3.6, 15.2.6, 15.1.9, 15.0.5; patched React: 19.0.1, 19.1.2, 19.2.1.
  • Impacted packages: react-server-dom-parcel, react-server-dom-turbopack, react-server-dom-webpack.
  • Action: upgrade immediately; canary users should downgrade to a stable 14.x or 14.3.0-canary.76.

Sentiment

The Hacker News discussion exhibits a strongly critical sentiment towards the design philosophy of React Server Components and Next.js. Many users express a 'we told you so' attitude, arguing that such a critical RCE vulnerability was predictable due to the inherent risks of blurring client-server boundaries and deserializing untrusted input without explicit security measures. While recognizing the swift deployment of fixes and mitigations, the community largely views this as a symptom of deeper architectural flaws and a concerning direction for the React ecosystem.

In Agreement

  • The CVSS v3 score of 10.0 accurately reflects the critical nature and severity of the RCE vulnerability, which is network-exploitable pre-authentication with no user interaction.
  • The vulnerability stems from the unsafe deserialization of untrusted client input into server-side function calls within React Server Components, confirming the technical details provided in the advisory and Facebook/React's own advisories.
  • The rapid deployment of platform-level mitigations by hosting providers like Vercel, Cloudflare, Netlify, and Deno Deploy underscores the urgency and seriousness of the issue.

Opposed

  • The design of React Server Components (RSC) and Server Actions is fundamentally flawed by implicitly creating an RPC layer without the explicitness, schemas, and security considerations typical of traditional RPC frameworks, making such vulnerabilities predictable.
  • The vulnerability is seen as a result of 'unacceptable carelessness' or 'sloppiness' by the React team, as the risks of deserializing untrusted input for server-side execution were widely warned about since RSC's inception.
  • The blurring of client and server boundaries in React and Next.js, and the 'magic' involved in server-side function calls, inherently increases the attack surface and makes securing applications more difficult.
  • React's direction with features like RSC is criticized for reinventing the wheel, adding complexity, and not addressing more pressing developer experience issues, leading to a 'nosedive' in usability.
  • The 'experimental' labeling of affected packages (like `react-server-dom-webpack`) is misleading given their widespread, often indirect, adoption through frameworks like Next.js, implying a lack of caution despite critical real-world usage.
  • This approach echoes past problematic technologies like .NET WebForms and Java JSF, which also attempted to hide network separation between client and server, demonstrating a failure to learn from historical mistakes.