In 2025, the web development community faced a serious wake-up call. A zero-day Remote Code Execution (RCE) vulnerability CVE-2025-66478 was discovered in applications built using Next.js App Router. What made it worse? The flaw didn’t require any authentication: no credentials, no CSRF tokens, not even a user click. Just one well-crafted HTTP request could trigger a full server compromise.

The underlying issue lies in how React Server Components (RSC) deserialize incoming data. On December 3, 2025, the React team publicly revealed CVE-2025-55182, a critical security flaw in React Server Components that allows unauthenticated remote code execution.

As part of the ongoing review of CVE-2025-55182, the React team has disclosed two more related vulnerabilities:

• CVE-2025-55184 – Denial of Service. Rated High severity (CVSS 7.5)
• CVE-2025-55183 – Source Code Exposure. Rated Medium severity (CVSS 5.3)

While these two flaws don’t enable Remote Code Execution, they were introduced in the patches released last week.

In this blog post, we’ll walk through how Amrood Labs Next.js developers can assist in detecting possible exposure to this vulnerability and help you enhance your overall security strategy.

1. What Is the Next.js RSC Vulnerability?

React Server Components (RSC) represent a fundamental shift in how React applications are structured and rendered. They allow professional Next.js developers to define components that render exclusively on the server, eliminating the need to send their JavaScript code to the browser. This not only optimizes performance but also reduces bundle sizes significantly.

RSCs are a cornerstone of the App Router introduced in Next.js 13, and their adoption has been growing steadily. Under the hood, RSCs rely on a custom binary or textual serialization format to encode the component tree, which is streamed from server to client using a protocol designed by the React team.

CVE-2025-55182

The vulnerability discovered in React’s implementation arises from insufficient input validation during deserialization of the RSC payload. Specifically, the deserializer accepts inputs that are attacker-controlled and allows manipulation of internal markers, object references, or even module invocations.

This leads to the possibility of injected server-side execution by interpreting parts of the payload as legitimate internal module references or commands. For instance, an attacker could spoof references to known Node.js modules or internal utility components, resulting in unanticipated behavior when those modules are invoked server-side.

In a typical exploit, a malicious request might:

• Embed a reference to a server utility function.
• Inject a call with custom arguments (e.g., shell commands).
• Trigger its evaluation as part of the RSC hydration process.

Without stringent validation and sanitization, the server trusts and interprets this input, violating core security principles.

CVE-2025-66478: Why Next.js Needs Its Own Advisory

Although React is the origin point, Next.js applications are uniquely vulnerable because:

• They integrate RSC deeply within the App Router.
• They expose specific API routes and render logic optimized for SSR + RSC workflows.
• They abstract many RSC behaviors through framework-managed pipelines.

As a result, the Next.js team published CVE-2025-66478 to provide targeted patches and guide framework users through a safe upgrade process.

2. How the RSC Protocol Works Under the Hood

The RSC protocol serializes React elements into a streamed payload sent over HTTP. Each part of the payload might reference:

• React components (by module path or ID).
• Props or context values.
• Server-side functions or fetch operations.

This design aims to provide lazy-loading and fine-grained streaming of server-rendered trees. However, the protocol inherently trusts the structure of the data it receives. When input is attacker-controlled, and the deserialization layer lacks strict type enforcement or sandboxing, arbitrary code paths can be triggered.

This vulnerability is a classic example of data becoming code, one of the most dangerous and subtle forms of exploitation.

3. Vulnerable Versions

As of this writing, any user or organization operating the following versions of Next.js and React is susceptible to the vulnerability.

Affected Next.js Versions

The issue impacts custom mobile applications that utilize React Server Components (RSCs) in combination with the App Router on the following versions:

• Next.js 15.x
• Next.js 16.x
• Next.js 14.3.0-canary.77 and later canary builds

Affected React Versions

The vulnerability exists in the following versions of these pnpm packages:

• react-server-dom-webpack
• react-server-dom-parcel
• react-server-dom-turbopack

Here are the affected versions that include 19.0, 19.1.0, 19.1.1, and 19.2.0.

4. How to Know if Your App Is Vulnerable

Ø  App Router Detection

If you’re using the app/ directory introduced in Next.js 13 or newer and relying on server components, you're likely affected.

Key signs:

• Presence of layout.tsx or page.tsx in the app/ directory.
• Use of server or client directives.
• Deployment using SSR-enabled configurations (e.g., runtime: nodejs).

Ø  Version Audit

Run:

npm list next react react-dom

Check if your versions match the patched baseline provided in the next section.

5. Patch Everything That Matters

Time to apply the real fix, upgrading your framework and packages to versions where this vulnerability has been neutralized.

Upgrade Next.js (Stable)

Here’s what to install based on your current version:

Patched canary releases for Next.js 15 and 16 were also made available:

15.6.0-canary.58 (for 15.x canary releases)
16.1.0-canary.12 (for 16.x canary releases)

The hardened implementation of React Server Components is included in these versions.

Patch React Server Components

Upgrade each RSC package:

pnpm install react-server-dom-webpack@19.0.2

pnpm install react-server-dom-parcel@19.0.2

pnpm install react-server-dom-turbopack@19.0.2

You can also install 19.1.3 or 19.2.2 for broader patch coverage.

These updates also fix:

• CVE-2025-55183 (leaks)
• CVE-2025-55184 (DoS)

Canary Builds: Upgrade or Downgrade?

If you're using canaries ≥ 14.3.0-canary.77, you have two paths:

Want stability?
pnpm install next@14

Want features?
Upgrade to: pnpm install next@15.6.0-canary.58

6. Best Practices to Prevent Future Exploits

To build resilience against future supply chain vulnerabilities, teams must implement sustainable security practices into their development and deployment workflows. Below are four foundational best practices designed for long-term protection in modern React and Next.js environments.

Use Security-Focused Dependency Monitoring

Modern JavaScript applications rely heavily on third-party packages, making automated vulnerability detection essential. Several tools can help identify risks as soon as CVEs are disclosed:

GitHub Dependabot

Dependabot automatically scans your package.json and package-lock.json (or yarn.lock) files for dependencies affected by known vulnerabilities. It then raises pull requests with upgraded versions, along with security advisories. These PRs can be configured for automatic merging after successful CI checks.

• Integrates directly with GitHub repositories.
• Tracks the National Vulnerability Database (NVD) and GitHub Security Advisories.
• Supports version pinning and grouped update strategies.

Snyk

Snyk offers a broader security platform with real-time monitoring, license compliance checking, and CI integration. It analyzes your codebase and the entire dependency tree, including transitive dependencies, and continuously monitors deployed applications.

• CLI, GitHub App, and API integrations available.
• Offers rich remediation advice for each vulnerability.
• Ideal for enterprise-grade observability and security compliance.

pnpm audit

Included with pnpm by default, pnpm audit evaluates your project’s dependency tree and cross-references it against the pnpm Security Advisories database.

pnpm audit

For quick remediation of low-risk issues:

pnpm audit fix

Although less proactive than Dependabot or Snyk, it’s valuable in CI pipelines to enforce baseline dependency hygiene.

Enforce Lockfile Integrity

Lockfiles (package-lock.json or yarn.lock) capture the exact versions of every installed dependency, including transitive packages. Maintaining their integrity is vital to ensure reproducible builds and to prevent drift that could reintroduce vulnerable versions.

Commit Lockfiles to Version Control

Always commit your lockfiles. This ensures that all developers, build agents, and environments install the same versions, reducing the risk of inconsistencies or accidental upgrades.

Avoid Blind pnpm update.

Avoid running pnpm update or yarn upgrade without reviewing the changes. These commands may introduce version changes that pull in unreviewed dependencies.

Instead, prefer:

pnpm install <package>@<version>

Or use patching tools that scope changes only to affected versions.

Use pnpm ci in CI/CD Pipelines

pnpm ci installs dependencies strictly according to the lockfile, ensuring that your CI environment reflects exactly what you tested locally.

pnpm ci

It’s faster than pnpm install and avoids unintentional changes caused by version resolution.

ü  Harden SSR Environments

Server-side rendering (SSR) is powerful, but it introduces exposure to inbound request data. Insecure server environments can exacerbate the impact of deserialization flaws or RCE exploits.

Restrict Public Access to Internal Routes

• Do not expose experimental or private API endpoints.
• Use route-based authentication and middleware to protect sensitive paths.
• Place SSR handlers behind a secure reverse proxy or gateway.

Apply Strong Content Security Policies (CSP)

CSP headers limit the sources of executable code and reduce the impact of injection vulnerabilities.

Example (strict baseline CSP):

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Ensure that policies don’t break needed functionality (like third-party widgets), but don’t leave them disabled in production.

Implement Runtime Guards

Use schema validators like zod, joi, or superstruct to validate all inputs, especially those parsed from request bodies or query strings.

Consider runtime detection mechanisms that alert on:

• Suspicious request payloads
• Access to internal-only components or modules
• Unexpected user-agent patterns or headers

Static Analysis Tools

Integrate security-oriented static analysis in your pipeline:

• ESLint security plugins: Identify potentially dangerous code patterns (e.g., use of eval, unsanitized inputs).
• Semgrep: A powerful static analysis tool that can detect insecure patterns across large codebases with high customization.

7. Common Mistakes to Avoid

Despite clear documentation and tooling, several recurring mistakes make organizations more vulnerable during incidents like the React/Next.js RCE disclosure. Here’s what to watch for:

Partial Upgrades

Updating either React or Next.js, but not both, is a common oversight. Since the upstream flaw (CVE-2025-55182) originates in React and the downstream impact (CVE-2025-66478) exists in Next.js, patching only one of them leaves you exposed.

Skipping Rebuilds

After updating dependencies, failing to rebuild and redeploy your application means the new code is never actually executed in production. In serverless and container environments, this is especially risky since cached builds or pinned images can retain old code.

 Always trigger a clean build:

pnpm run build

And re-deploy using your CI/CD system or manual process.

Delaying Due to Infra Constraints

Some teams rely on:

• Pinned Docker images
• Internal npm mirrors
• Long approval cycles for dependency upgrades

These practices can delay patch rollout by days or weeks. In high-severity scenarios, that delay creates an extended vulnerability window.

Conclusion

The twin vulnerabilities CVE-2025-55182 (React) and CVE-2025-66478 (Next.js) highlight the evolving complexity of full-stack JavaScript applications and the critical role of supply chain security.

For teams managing production-grade React/Next.js applications, this is a call to action:

• Audit your app.
• Upgrade immediately.
• Harden your environments.
• Review your CI/CD and dependency policies.

Security is not a feature; it’s a continuous practice. Staying vigilant, proactive, and well-informed is the best defense against the next zero-day exploit.