Patch Now: The React Server Components RCE (CVE-2025-55182) and the May 2026 13-CVE Release — A Version-by-Version Upgrade Map

CVE-2025-55182 is a CVSS 10.0 remote code execution vulnerability in the React Server Components (RSC) payload deserialization path, disclosed on 3 December 2025. If your application renders RSC, an attacker can send a crafted request that the server decodes into arbitrary code execution, and this works even if you never wrote a single Server Function. The fix is shipping across the react-server-dom- packages, and the coordinated Next.js security release on 7 May 2026 lands it in 16.2.6 with backports for older supported lines. Upgrade today if you can, and read on for the exact version map and a WAF rule to buy yourself a few hours if you cannot.

I am writing this as the engineer founders call when a critical CVE drops on a Friday and nobody on the team knows which transitive package version they actually ship. The job is the same every time: confirm exposure, find the patched version for the exact line you are on, and ship the upgrade without breaking production. Let me give you that map.

What exactly is CVE-2025-55182?

CVE-2025-55182 is a server-side deserialization flaw in how React Server Components decode the wire format that the client sends back to the server. It scores CVSS 10.0 because it is remotely exploitable, needs no authentication, and ends in full remote code execution on the rendering server.

Here is the mechanism in plain terms. RSC has a serialization protocol. The server sends the client a stream of "flight" data, and for interactivity the client sends structured payloads back. The decoder on the server reconstructs JavaScript values from that wire format. The vulnerability is that a malicious payload can steer that reconstruction into instantiating or invoking things the author never intended, which an attacker chains into code execution. Because the decoder runs before your application logic, your own input validation never gets a chance to fire.

The reason this one is scary is the blast radius. It is not a bug in some optional feature. It is in the core decode path that every RSC render touches.

Am I vulnerable if I do not use Server Functions?

Yes. This is the part that catches teams off guard. The flaw is in the RSC payload decoder, not in Server Functions or Server Actions, so any app that renders React Server Components is in scope.

A lot of engineers reason "we do not use Server Actions, so the attack surface that takes user input on the server does not exist for us." That mental model is wrong here. The decoder is exercised on the normal RSC request cycle. If you run the App Router with Server Components, or any framework that uses react-server-dom-webpack or react-server-dom-turbopack under the hood, you render RSC payloads on every navigation. That is the vulnerable path.

You are most likely affected if any of these are true:

• You run Next.js App Router (the app/ directory) on a server or serverless runtime.


• You use a framework or custom setup that depends on react-server-dom-webpack, react-server-dom-turbopack, or react-server-dom-parcel.


• You self-host an RSC-capable React build, even without Next.js.

The short version: move to Next.js 16.2.6 or the backported patch on your current major line, and make sure the resolved react-server-dom- package is on its corresponding fixed release. The table below maps each supported line to the version where the fix lands as part of the 7 May 2026 coordinated release.

A note on dates and exact numbers. CVE-2025-55182 was disclosed 3 December 2025 with a CVSS of 10.0. Next.js bundled the fix into its coordinated security release on 7 May 2026, with 16.2.6 as the headline fixed version. For the precise patch number on the 15.x and 14.x backport lines, check your registry rather than trusting any number you read in a blog, because backport patch versions increment independently and I would rather you verify than copy a stale digit.

How do I confirm which react-server-dom version I actually ship?

Do not trust package.json. Trust your lockfile resolution, because Next.js pins the react-server-dom- packages transitively and that resolved version is the one that runs.

Run the command for your package manager:

## npm
npm ls react-server-dom-webpack react-server-dom-turbopack

## pnpm
pnpm why react-server-dom-webpack
pnpm why react-server-dom-turbopack

## yarn
yarn why react-server-dom-webpack

If you see a version below the patched release for your line, you are exposed. After upgrading, run the same command again and confirm the resolved version moved. I have seen upgrades where someone bumps next in package.json but a stale lockfile or a resolutions/overrides pin holds the vulnerable react-server-dom- in place, so the verification step is not optional.

If you keep React pinned separately (custom RSC setup), bump React and the matching react-server-dom- together in the same change. Mismatched React and dom-package versions are their own class of bug.

How do I upgrade safely without breaking production?

The fastest safe path is: bump to the patched version on your current major line first, ship it, then schedule the larger major upgrade separately. Security and migration are two different projects, and conflating them is how teams turn a 20-minute patch into a two-day stall.

Here is the sequence I follow on a live app:

1. Pin the patched version explicitly. Edit package.json to the exact fixed version, do not use a caret range during an emergency patch.

{
  "dependencies": {
    "next": "16.2.6",
    "react": "19.x",
    "react-dom": "19.x"
  }
}

1. Refresh the lockfile and verify resolution.

npm install
npm ls react-server-dom-webpack react-server-dom-turbopack

1. Run the build and your test suite. A security patch release on the same major line should be low risk, but RSC-adjacent changes can surface latent issues, so run a full build, not just next dev.


2. Deploy to staging, smoke test the App Router paths, then promote. Hit the routes that render Server Components and confirm navigation, streaming, and any Server Actions still behave.


3. Only then plan the major upgrade if you were on 14.x or 15.x and want to land on 16. Do not couple it to the security fix.

How do I block CVE-2025-55182 at the edge before I can upgrade?

If you genuinely cannot deploy right now, a WAF rule that rejects malformed or oversized RSC payloads blocks the known exploit shape and buys you a few hours. This is a stopgap, not a fix, and you still ship the patched package as soon as the change window opens.

RSC requests carry a specific shape: a content type and headers that mark them as flight requests, with a serialized body. The exploit relies on sending a crafted serialized payload into the server decoder. Two practical filters help:

• Reject oversized RSC request bodies. Legitimate RSC action/return payloads are small. Cap the body size on requests that carry the RSC content type and reject anything past a sane threshold.


• Reject malformed or suspicious serialized markers in the RSC body that do not match what your app emits.

## Stopgap only. Replace with the patched package ASAP.
SecRule REQUEST_HEADERS:Content-Type "@contains text/x-component" \
  "id:1055182,phase:1,deny,status:413,\
   msg:'CVE-2025-55182 RSC payload size guard',\
   chain"
  SecRule REQUEST_HEADERS:Content-Length "@gt 65536" \
    "t:none"

On Cloudflare, Fastly, or AWS WAF you express the same intent: match the RSC request marker, then reject on body size or on a payload pattern that does not match your traffic. Tune the size threshold to your real payloads so you do not break legitimate Server Action submissions. And log every block, because a spike in blocked requests after disclosure tells you the scanners have found you.

Treat the WAF as a tourniquet. The actively scanned CVEs get hammered within hours of disclosure, so the only real fix is the patched version.

What should I do in the next hour?

The honest priority order, fastest to slowest: confirm whether you render RSC at all, check your resolved react-server-dom-* version, and if it is below the patched release, ship the in-line patch upgrade today. The major version migration can wait a week. The CVSS 10.0 RCE cannot.

If your app is on an old line, has no test coverage on the App Router paths, or you simply do not have time to do this carefully while keeping the lights on, that is the work I do. I take broken or behind-version Next.js apps, confirm the real exposure, ship the patch safely, and leave you with a build that is current and tested. Reach out through my contact page ↗ and tell me which version you are on, and I will tell you the shortest safe path to patched.

While you are hardening the stack, the same App Router that exposes the RSC decoder is also where AI agents now read your app, which I cover in building Next.js apps for AI agents ↗. Patch first, then optimize.