A critical 10.0 CVSS remote code execution (RCE) vulnerability was disclosed on December 3, 2025 in React Server Components (RSC) and Next.js, affecting a large portion of modern JavaScript applications.
The flaw, tracked as CVE-2025-55182 (React) and CVE-2025-66478 (Next.js), allow an unauthenticated attacker to execute arbitrary code on a server using nothing more than a crafted HTTP request.
If your organization uses RSC or frameworks that bundle them, including Next.js,, this is an urgent, high-severity situation that requires immediate attention.
This post provides a technical overview of the vulnerabilities, explains the real-world impact, and outlines how Oligo helps teams rapidly identify and remove exposure for zero-days.
What Happened?
React Server Components use a serialized transport format – “Flight” – to send structured component data and server function calls between the client and server.
At the heart of the vulnerabilities is a logic flaw in how React deserializes incoming RSC payloads.
The issue stems from:
- Unsafe handling of client-supplied RSC payloads
- Deserialization of attacker-controlled data
- Translation of that data into server-side execution paths
As the React team summarizes:
“An unauthenticated attacker could craft a malicious HTTP request to any Server Function endpoint that, when deserialized by React, achieves remote code execution on the server.”
Because this logic executes before authentication checks, any public-facing application with RSC enabled is exposed.
Why Next.js is impacted
Next.js implements the same RSC protocol. Its App Router architecture includes server actions and server-side transformations that rely on the vulnerable deserialization logic. As a result, Next.js inherits the flaw directly from the upstream React implementation.
Vulnerable Packages, Versions, and Functions
React packages
Affected versions of:
- react-server-dom-webpack
- react-server-dom-parcel
- react-server-dom-turbopack
Vulnerable: 19.0.0, 19.1.0, 19.1.1, 19.2.0
Fixed: 19.0.1, 19.1.2, 19.2.1
Next.js
Affected:
- 14.3.0-canary.77+
- 15.x
- 16.x
Not affected:
- Next.js 14.x stable
- Next.js 13.x
- Pages Router
- Edge Runtime
Fixed versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7
For reference, the specific vulnerable functions for the vulnerability are below.
Most common
- requireModule
- decodeReplyFromBusboy
And also
- resolveField
- resolveFileInfo
- resolveFileChunk
- resolveFileComplete
- ReactFlightReplyServer
Why the flaw is so severe
These are some of the most impactful vulnerabilities to hit the JavaScript ecosystem in recent years. The severity stems from several compounding factors:
- Full remote code execution (CVSS 10.0): attackers can execute arbitrary JavaScript on the server, gaining the ability to run system commands, access environment variables, pivot deeper into cloud and backend systems.
- Unauthenticated attack surface: No log in, session, or CSRF token is required - just a single HTTP request.
- Default configurations are exploitable: A standard create-next-app build is vulnerable without any custom settings.
- Large ecosystem impact: RSC is widely adopted across frameworks, and Next.js has one of the largest production footprints in the world.
Immediate Required Action
1. Upgrade all RSC-related React packages
Move to: 19.0.1, 19.1.2, or 19.2.1
2. Upgrade Next.js to a patched version
If you are on:
- 15.0.x → upgrade to 15.0.5
- 15.1.x → upgrade to 15.1.9
- 15.2.x → upgrade to 15.2.6
- 15.3.x → upgrade to 15.3.6
- 15.4.x → upgrade to 15.4.8
- 15.5.x → upgrade to 15.5.7
- 16.0.x → upgrade to 16.0.7
If you are running 14.3.0-canary.77 or later canary, downgrade to the latest 14.x stable.
Responding to Zero-Days
When a vulnerability of this magnitude hits, organizations face the same urgent questions:
- Where are we using vulnerable packages?
- Are the affected components actually loaded and running in production?
- Is this vulnerability exploitable in our environment?
- Are we already seeing exploit attempts?
Traditional tools can’t answer these questions quickly. They rely on static scans, repo metadata, or build pipelines, none of which reflect what is truly running in production.
Oligo solves this problem directly.
How to Check Your Exposure in Oligo
- Open Oligo Console → Dependencies
- Search for:
- react-server-dom-webpack
- react-server-dom-parcel
- react-server-dom-turbopack
- next
- Filter by Dependency Status → Executed
- Compare your versions to the patched releases
- Prioritize and remediate only what is actually exploitable
This gives teams high-confidence answers immediately, without waiting for new scans or digging through thousands of findings.
See example for next.js:
Detecting Exploit Attempts
In addition to helping customers respond to zero days, Oligo was purpose-built to detect exploitation in the wild through its runtime approach – especially for vulnerabilities involving unsafe deserialization, server-side execution, or logic flaws inside framework internals.
Oligo’s Deep Application Inspection observes how code actually behaves inside the running application process. For deserialization vulnerabilities like CVE-2025-55182 and CVE-2025-66478, Oligo can:
- See and stop deserialization flows that actually lead to code execution.
- Spot subtle shifts in the deserialization stack trace that distinguish real attacks from routine application activity.
Final Thoughts
These vulnerabilities will not be the last to target RSC, server actions, or framework-level serialization layers.
What matters now is reducing uncertainty: patching quickly, confirming which vulnerable components are actually executed in production, and having the ability to see exploitation attempts as they happen.
Oligo gives teams the runtime evidence required to make those decisions with confidence, all without slowing releases or relying on incomplete inventory data.
