CVE-2025-55182: React Server Components Remote Code Execution Vulnerability
A Deep Dive into CVE-2025-55182 and How Layered Defense Works
A Deep Dive into CVE-2025-55182 and How Layered Defense Works
Feel free to send us a message with your thoughts, or learn more about us!
Disclosure Timeline: This vulnerability was publicly disclosed on December 3, 2025. If you're running Next.js 14.3+, 15, or 16 with React Server Components, you should upgrade immediately, regardless of your hosting provider.
Today we witnessed defense in depth working exactly as intended. Within hours of CVE-2025-55182 being disclosed, a critical remote code execution vulnerability in React Server Components, we received alerts from two different sources:

This is what modern security infrastructure looks like: multiple layers working in concert. Vercel's WAF provided immediate protection before we could even review the PR, while Dependabot delivered the actual patch for permanent remediation.
In this post, we'll break down what CVE-2025-55182 is, why it matters, how these layered defenses protected our app, and what you should do to secure your own projects.
CVE-2025-55182 is a critical-severity vulnerability affecting React Server Components (RSC). Under certain conditions, specially crafted requests can lead to unintended remote code execution (RCE) on the server.
The vulnerability exists in React 19's server-side rendering packages:
react-server-dom-parcelreact-server-dom-webpackreact-server-dom-turbopackFor Next.js specifically, there's a related CVE: CVE-2025-66478.
RCE vulnerabilities are among the most severe security issues. An attacker exploiting this could potentially:
This isn't a theoretical risk, it's a practical attack vector that affects a significant portion of the React ecosystem.
If you're using React Server Components with any of these versions, you're affected:
| Package | Affected Versions | Fixed Versions |
|---|---|---|
| React | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
| Next.js | ≥14.3.0-canary.77, all 15.x, all 16.x | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
Other RSC-based frameworks are also affected, including Vite with RSC, Parcel, React Router (with RSC), RedwoodSDK, and Waku.
Quick check for Next.js projects:
# Check your current versions
npm ls next react
# Or in your package.json
cat package.json | grep -E '"(next|react)"'Here's what makes this disclosure interesting from a DevSecOps perspective: Vercel's platform detected and mitigated this vulnerability before Dependabot could even create a PR.
The disclosure unfolded rapidly on December 3rd:
Both systems worked, but with different roles:
Vercel took a proactive path:
"We have created new WAF rules to address this vulnerability and deployed them to Vercel WAF that will automatically and at no cost protect all projects hosted on Vercel." — Jimour Lai, Vercel Security Engineer
This means that by the time we saw the Dependabot PR, our production deployment was already protected, we had breathing room to review and merge the upgrade properly.
Vercel also worked with the React team to provide recommendations to major WAF and CDN providers. This collaborative approach helps protect the broader ecosystem, not just Vercel customers.
Even with WAF protection, you should still upgrade. WAF rules are a mitigation, not a permanent fix.
# Upgrade to the latest patched version
npm install next@latest react@latest react-dom@latest
# Or specify exact versions
npm install next@16.0.7 react@19.2.1 react-dom@19.2.1After upgrading, confirm the versions:
npm ls next react react-domYou should see versions at or above the patched releases listed in the table above.
Check your framework's documentation for specific upgrade instructions. The underlying fix is in React itself, so ensure you're on React 19.0.1, 19.1.2, or 19.2.1+.
React Server Components represent a significant architectural shift. They blur the line between client and server code, which creates new attack surfaces that didn't exist in traditional client-side React.
This vulnerability is a reminder that:
Server-side code needs server-side security thinking. RSC isn't "just React", it's React running in a privileged environment.
Framework-level protections matter. Vercel's ability to deploy WAF rules across their platform demonstrates the value of managed infrastructure.
The disclosure process is evolving. Coordinated disclosure with platform providers can protect users faster than traditional CVE→Dependabot→CI workflows.
After reviewing PR #87, we merged Dependabot's upgrade from Next.js 16.0.6 to 16.0.7. The process was straightforward:
This incident demonstrated effective defense in depth:
| Layer | Role | Response Time |
|---|---|---|
| Vercel WAF | Block exploit attempts | Pre-disclosure |
| Dependabot | Deliver patch PR | Same day |
| CI/CD | Validate upgrade | Automated |
| Developer | Review and merge | Hours |
We weren't scrambling. Vercel's WAF bought us time, Dependabot did the heavy lifting, and we just needed to approve the change.
If you're not using Dependabot or Renovate, here's how to upgrade manually:
# Upgrade to the latest patched version
npm install next@latest react@latest react-dom@latest
# Or specify exact versions
npm install next@16.0.7 react@19.2.1 react-dom@19.2.1Verify your upgrade:
npm ls next react react-domCredit: This vulnerability was responsibly disclosed by Lachlan Davidson. Thanks to Jimour Lai, Luba Kravchenko, and Andy Riancho at Vercel for the coordinated response.