ax0
← All posts
Security5 min read

CVE-2025-55184 — pre-auth DoS in React Server Components

How a single unauthenticated request could hang a Next.js App Router server through unsafe deserialization in the RSC Flight protocol, which versions are affected, why the first patch was incomplete (CVE-2025-67779), and what to do about it.

December 2025 was a rough month for anyone running React Server Components in production. On 3 December the React team disclosed CVE-2025-55182 ("React2Shell"), a critical pre-authentication remote code execution bug in the RSC "Flight" protocol. A week later, while teams were still rolling out that patch, follow-up research produced two more advisories on 11 December:

  • CVE-2025-55184 — pre-authentication denial of service (CWE-502, CVSS 7.5)
  • CVE-2025-55183 — source code exposure of Server Functions (CVSS 5.3)

This post focuses on CVE-2025-55184: what it is, who is affected, and why "I already patched React2Shell" was not enough. I build Next.js apps as well as test them, so I'll cover both the attacker's and the maintainer's view.

Background: what the Flight protocol does

React Server Components let the server render parts of the UI and stream them to the browser using a serialisation format React calls Flight. The reverse direction matters too: when the browser calls a Server Function (a 'use server' action), it sends arguments that the server must deserialise before running any of your code.

That deserialiser lives in the react-server-dom-* packages (webpack, parcel and turbopack variants) and is bundled into frameworks such as the Next.js App Router. Because it runs before authentication or any application logic, every bug in it is pre-auth by definition.

The vulnerability

CVE-2025-55184 is an unsafe deserialisation issue (CWE-502). A specially crafted HTTP request to a Server Function endpoint is processed by the Flight deserialiser in a way that sends it into an infinite loop. The request never completes, the worker spins on the CPU, and the server process stops serving everyone else.

Three properties make this serious despite "only" being a DoS:

  1. No authentication. The deserialiser runs before your middleware or auth checks have a say.
  2. Highly asymmetric. One small request can tie up a whole server process. A handful of requests can take down an instance that would comfortably survive a traditional volumetric flood.
  3. Default exposure. You don't have to write anything unusual. If your app uses the App Router with Server Functions on a vulnerable version, the endpoint exists.

I'm deliberately not publishing a payload. The patch is public and the fix is simply to upgrade, so a working exploit would add risk without helping defenders.

Affected versions and the incomplete fix

The advisories list the vulnerable react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack releases as 19.0.0 – 19.2.1.

The first patched releases (19.0.2, 19.1.3 and 19.2.2) turned out to be incomplete: they didn't stop every payload variant. That gap was tracked as CVE-2025-67779, and the React team shipped a second round of fixes.

Release line Vulnerable First (incomplete) fix Fully patched
19.0.x 19.0.0 – 19.0.1 19.0.2 19.0.3+
19.1.x 19.1.0 – 19.1.2 19.1.3 19.1.4+
19.2.x 19.2.0 – 19.2.1 19.2.2 19.2.3+

If you upgraded once in December, check again. Next.js published matching patched releases for each supported line; use the versions in the official Vercel security bulletin rather than guessing.

Am I affected?

Check what's actually resolved in your lockfile, not just what's in package.json. Frameworks vendor these packages, so a direct dependency check can miss them:

npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel next
# or
pnpm why react-server-dom-webpack

Then ask:

  • Do you use the App Router with Server Functions or Server Actions?
  • Is the app reachable from the internet, directly or through a CDN?
  • Are you running self-hosted Node servers, where one hung process is a real outage, or a platform that isolates and recycles workers?

Remediation

  1. Upgrade React's RSC packages to 19.0.3 / 19.1.4 / 19.2.3 or later, and Next.js to the patched release for your line. Redeploy, then confirm with the lockfile check above.
  2. Rotate nothing, but re-check React2Shell. CVE-2025-55184 doesn't leak secrets. CVE-2025-55182 was RCE, though, so if you were exposed before patching that one, treat the server as potentially compromised and rotate its secrets.
  3. Bound the blast radius with good hygiene that helps against any asymmetric DoS: - request timeouts and body-size limits at the proxy or load balancer - rate limiting on Server Function endpoints - multiple instances behind a load balancer with health checks that restart hung workers
  4. Use WAF rules as a stop-gap only. Several CDN and WAF vendors shipped temporary signatures for the RSC issues. They buy time; they don't replace the upgrade.

Detection

A hung event loop looks different from a normal traffic spike:

  • a sustained 100% CPU on a single Node process while request throughput drops
  • POST requests to App Router paths with Next-Action headers that never complete
  • health checks failing on one instance at a time, with a small number of unusual requests in the access log just before

Alert on request duration, as well as on error rate and volume.

Lessons for framework users

  • Your attack surface includes framework internals. Server Functions are an RPC endpoint, even if you never wrote a route handler.
  • Patch, then re-verify. Incomplete first fixes are common for parser and deserialiser bugs. Subscribe to framework security advisories, and keep dependency automation (Dependabot or Renovate) running so the second patch reaches you quickly.
  • Defence in depth still matters for DoS. Timeouts, limits and worker recycling turned this from an outage into a blip for teams that already had them.

References