By ByteBot
React 19 and Next.js contain a critical unauthenticated RCE vulnerability rated CVSS 10.0—maximum severity. Wiz security researchers discovered insecure deserialization in the React Server Components Flight protocol that affects 39% of cloud environments. The worst part? Default Next.js applications created with create-next-app are vulnerable with zero code changes required. Millions of React developers must patch immediately.
You Did Nothing Wrong—The Framework Failed You
This isn’t a developer misconfiguration or forgotten security checklist. A standard Next.js app scaffolded with create-next-app and built for production is vulnerable out-of-the-box. No mistakes needed.
CVE-2025-55182 exposes a fundamental flaw in how React Server Components handle deserialization. Security researchers achieved near-100% exploitation reliability with nothing more than a crafted HTTP request. No authentication, no complex exploit chains, no social engineering—just a malicious payload to any Server Function endpoint.
The React Team confirmed: “An unauthenticated attacker could craft a malicious HTTP request to any Server Function endpoint that, when deserialized by React, achieves remote code execution.” That’s every Next.js 15-16 and React 19.0-19.2 application in production right now.
The Timeline: From Bug Bounty to Emergency Patches in Four Days
- November 29: Lachlan Davidson reports the vulnerability via Meta Bug Bounty
- November 30: Meta security confirms the issue
- December 1: Fix development begins with hosting provider coordination
- December 2: Cloudflare deploys emergency WAF rules at 5:00 PM GMT
- December 3: CVE-2025-55182 published with CVSS 10.0 rating
Four days from discovery to public disclosure with coordinated patching across the ecosystem. That’s modern security disclosure working as intended. But it raises an uncomfortable question: React 19 shipped in October 2024. This vulnerability lurked in production for over 13 months before external researchers found it.
What Went Wrong: The Flight Protocol’s Fatal Flaw
React Server Components use an internal Flight protocol to serialize data between server and client. The vulnerability exists in how this protocol deserializes incoming payloads. When a server receives a specially crafted request, the RSC payload handler fails to validate the structure correctly. Attacker-controlled data influences server-side execution logic, resulting in privileged JavaScript code running on the server.
The affected packages—react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack—all share the same insecure deserialization logic. Wiz Research data shows 39% of cloud environments contain vulnerable instances.
Cloudflare observed zero exploitation attempts before disclosure, suggesting attackers hadn’t discovered this vector yet. But with CVSS 10.0 severity and 100% reliability, that window closes fast.
Patch NOW—Here’s How
Affected versions:
- React: 19.0, 19.1.0, 19.1.1, 19.2.0
- Next.js: 15.0 through 16.0
Patched versions:
- React: 19.0.1, 19.1.2, 19.2.1
- Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7
Check your versions:
npm list react nextUpdate immediately:
npm update react react-dom
npm update nextCloudflare customers are automatically protected through emergency WAF rules deployed December 2. But the React Team emphasized: “You should not depend on [hosting provider mitigations] to secure your app, and still update immediately.”
Should React Have Caught This Before Release?
React 19 shipped to production in October 2024. Over 13 months passed before external security researchers discovered a CVSS 10.0 vulnerability in a core framework feature. That’s not a minor edge case—it’s insecure deserialization in the primary server-client communication protocol.
Did React Server Components ship too fast? The architecture blurs server-client boundaries in ways that confuse even experienced developers. Security experts warn that RSC introduces complexity where deserialization is inherently risky, developer mental models don’t match security reality, and it’s too easy to accidentally expose server-side vulnerabilities.
The Node.js security community recommends treating all server component variables as hostile input requiring validation, sanitization, and authorization before use. That’s not a framework limitation—it’s an admission that RSC’s security model requires constant vigilance developers don’t always maintain.
The React Team’s position: bug bounty programs exist for exactly this reason. Four-day turnaround from report to coordinated disclosure protected users. Security risks are manageable with proper practices.
Fair enough. But millions of production applications sat vulnerable for over a year, built with official tooling and following documented best practices. That’s a framework security failure, not a developer failure.
What Developers Must Do
Immediate actions:
- Check React and Next.js versions
- Update to patched versions within 24 hours
- Deploy behind Cloudflare WAF if possible
- Review Server Actions/Functions for additional vulnerabilities
Medium-term actions:
- Implement input validation on all server-side operations
- Add authorization checks everywhere
- Use server-only package to prevent client imports
- Audit RSC usage for security gaps
Long-term considerations:
Consider whether RSC complexity is worth the security overhead for your use case. Simpler architectures sometimes win.
The coordinated response was fast and effective. Cloudflare deployed emergency protections within 3 days. Patches shipped across multiple version branches. No known exploitation occurred.
But the question lingers: should React have caught this before React 19 shipped? Or is this just the cost of running bleeding-edge framework code in production?
