TL;DR
On December 3, 2025, coordinated disclosures revealed that multiple releases of React 19 and Next.js contain a critical flaw in the React Server Components (RSC) “Flight” protocol, allowing unauthenticated remote code execution (RCE). The vulnerability originates from unsafe deserialization of attacker-controlled data in server-side RSC payload handling.
Exploitation only requires a crafted HTTP request, works reliably in default configurations, and affects not only React/Next.js, but also any framework or bundler embedding the RSC implementation.
Patches are available and should be applied immediately. Systems running unpatched versions are exposed to full server compromise.
Overview of the component involved
React Server Components (RSC) and the “Flight” protocol
React 19 introduced a mechanism to split UI rendering between the client and the server, serializing component state and server function calls via a special transport format often referred to as the “Flight” protocol.
Affected packages include:
react-server-dom-webpackreact-server-dom-parcelreact-server-dom-turbopack
These packages deserialize incoming RSC payloads to route server-side operations. The vulnerability stems from the fact that the deserialization logic did not adequately enforce structural or type constraints, enabling malicious payloads to alter execution behavior.
Why the default setup was exposed
Most frameworks that adopt RSC—including Next.js App Router—ship with this logic enabled out of the box. This means that a standard Next.js project created via create-next-app, built and deployed with no code modifications…was exploitable under default settings.
Timeline of known events
| Date | Event |
| Nov 29, 2025 | Security researcher Lachlan Davidson privately reports a flaw in how React decodes payloads received by Server Function endpoints, identifying a path to unauthenticated RCE. |
| Nov 30, 2025 | Meta’s security team validates the report and collaborates with the React engineering group to design a fix. |
| Dec 1, 2025 | A patch is developed; major ecosystems and hosting providers begin implementing mitigations and validating updates. |
| Dec 3, 2025 | Meta/React team publishes security advisory for CVE-2025-55182, covering React RSC packages. |
| Dec 3, 2025 | Vercel releases advisory for CVE-2025-66478, covering the Next.js integration of the same underlying flaw. |
| Dec 3, 2025 | Updated releases for React (19.0.1 / 19.1.2 / 19.2.1) and Next.js (patched 15.x/16.x + downgrade guidance for Canary users) become publicly available. |
| Dec 3, 2025 onward | Ecosystem follows with package updates (Vite RSC, Parcel RSC, React Router previews, RedwoodSDK, Waku, etc.). Investigation continues. |
Note: No exploitation in the wild has been publicly confirmed as of disclosure, but exploitation requires minimal sophistication.
Impacted components
Affected React versions
- 19.0.0
- 19.1.0
- 19.1.1
- 19.2.0
Affected Next.js versions
- All stable 15.x
- All stable 16.x
- Experimental 14.3.0-canary.77 and above
Other tools and frameworks likely affected due to bundling RSC:
- Vite RSC plugin
- Parcel RSC plugin
- React Router RSC preview
- RedwoodSDK
- Waku
- Any package embedding the vulnerable
react-server-dom-*modules
Cloud footprint
Research estimates show ~39% of cloud environments scanned had workloads running vulnerable versions of React/Next.js RSC.
How the incident happened
Underlying vulnerability: Unsafe deserialization
At the core, the server-side RSC engine accepts a serialized “Flight” payload describing:
- Component boundaries
- Server function references
- Data streams
The vulnerable implementations trusted the inbound structure too deeply. When malformed but syntactically valid payloads were submitted, the server:
- Failed to reject unexpected object shapes or references
- Processed attacker-supplied identifiers
- Executed privileged JavaScript paths that were never intended to be externally reachable
This leads directly to remote code execution prior to authentication, which is why the CVSS score is 10.0 (critical).
Attack vector
- Remote: No local access or credentials needed
- Unauthenticated: Anyone can attempt exploitation
- Single request: Crafted HTTP request to an RSC endpoint is sufficient
- High reliability: Testing reports nearly 100% reliability under default configs
Why this is particularly dangerous
- Most Next.js apps with App Router expose RSC endpoints publicly.
- The RCE occurs before any routing logic or auth gates.
- Cloud or serverless deployments often place RSC endpoints at the root of their API surfaces.
Detection and scanning recommendations
For code and dependency scanners
Look for:
-
"react-server-dom-webpack"versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 -
"react-server-dom-parcel"versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 -
"react-server-dom-turbopack"versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 - Next.js versions listed in the affected section
For runtime / network-level monitoring
Flag:
- Requests to RSC routes containing malformed or unexpected RSC Flight frames
- High entropy or anomalous tokens in serialized RSC payloads
- Sudden increases in server function invocation errors
For cloud posture tools
Search for workloads deploying:
- Containers built prior to Dec 3, 2025
- React 19 or Next.js 15/16 images not yet patched
- Public-facing workloads using App Router or server actions
Vercel-hosted apps benefit from platform-level request filtering, but still require upgrades.
Mitigation guidance
1. Upgrade immediately
React
- 19.0.0 → 19.0.1
- 19.1.x → 19.1.2
- 19.2.0 → 19.2.1
Next.js
Fixed versions:
npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7
- Canary users → If using 14.3.0-canary.77 or newer, downgrade to stable:
npm install next@14
2. Rebuild applications after upgrading
Ensure CI/CD pipelines rebuild Docker images or serverless bundles with the patched dependency graph.
3. Validate third-party frameworks
If using Redwood, Waku, experimental RSC previews, or bundlers, verify:
- Updated RSC implementation shipped
- No stale lockfiles are pinning vulnerable versions
4. Enable defense-in-depth controls
- Runtime sandboxing for server-side JS
- Strict routing for RSC endpoints
- Web Application Firewall (WAF) rules to detect malformed RSC payloads
Next steps for the community
For maintainers of dependent ecosystems
- Audit any custom RSC extensions
- Publish updated advisories and patched builds
- Consider hardening deserialization schemas with explicit validation
For organizations
- Inventory all workloads using React Server Components
- Prioritize internet-facing apps
- Monitor for suspicious activity leading up to the patch window
- Conduct post-patch forensics to ensure no exploitation occurred
Conclusion
This incident underscores a systemic challenge in modern JavaScript ecosystems: highly dynamic serialization mechanisms can become powerful RCE vectors when insufficient validation is applied. Because React Server Components are rapidly becoming foundational across frameworks, the blast radius of this vulnerability is unusually wide.
Patching this incident is straightforward, but delays dramatically increase risk. Organizations should upgrade now, verify dependent frameworks, and continue monitoring for further updates as ecosystem investigations progress.
Don’t delay your fix. Review the Snyk advisories now to confirm affected versions and get full remediation details:
Top comments (1)
Actually, I have confirmed exploitation attempts in my logs from this morning. My small Next.js app (just launched) got sprayed within 12 hours of disclosure. User-Agent was quite literally CVE-2025-55182-Exploit/12.0. Requests targeted /login and /formaction with Next-Action: true headers. All failed (404/500/307) because they hit wrong endpoints, but this is actively being scanned for in the wild.