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

HN is predominantly critical and skeptical. The majority view is that this vulnerability validates long-standing concerns about RSC's implicit RPC model and React's increasing complexity. While React team members offered defenses, the community largely interpreted this as an 'I told you so' moment about the dangers of 'magic' client-server boundaries. Broader framework frustration—hooks API, RSC complexity, Meta's priorities—added fuel to an already heated reaction.

In Agreement

• RSC implicitly built an RPC layer without acknowledging it—unlike gRPC or SOAP which require explicit schemas—making this class of vulnerability structurally predictable.
• The deserialization-of-untrusted-input pattern is a decades-old vulnerability class, and rolling your own object deserialization in a non-dedicated library is as dangerous as writing your own cryptography.
• The vulnerability affects default Next.js installs even without custom server components code, making the impact broader than it initially appears.
• The React/Next.js team had been warned repeatedly about security risks from blurring client/server boundaries, but dismissed community concerns.
• The US-centric coordinated disclosure timeline left European developers exposed to active exploitation before they could patch.
• The increasing complexity of React—hooks rules, RSC, server actions—has created a high-surface-area framework with more ways to introduce security issues.

Opposed

• Dan Abramov explained that RSC is a componentized BFF layer that solves a real problem: binding backend data preparation directly to frontend components, reducing the tension between evolving API and UI layers.
• React contributor sophiebits noted that 'use server' does explicitly mark functions as RPC-exposed, and that similar bugs could be introduced in any RPC implementation—it is not unique to RSC's design.
• One developer (fabioborellini) found the RSC/Next.js experience superior to writing a separate REST API for a tightly-coupled frontend, arguing the traditional frontend/backend separation is a false boundary for small-scale apps.
• The vulnerability is an implementation-level bug (missing hasOwnProperty check) that was corrected with a targeted fix, not evidence that the entire RSC architecture is fundamentally broken.
• Platform-level WAF mitigations from Vercel, Cloudflare, AWS, and Netlify were already deployed ahead of public disclosure, limiting real-world impact for hosted deployments.