CVE-2025-55184: the React Server Components denial of service, and how to fix it

What CVE-2025-55184 is, in plain words

React Server Components (RSC) run part of a React app on the server. When a page calls a Server Function (a Server Action, in Next.js), the browser sends the arguments in React's Flight format and the server decodes them back into values. CVE-2025-55184 is a bug in that decoding step: the affected versions unsafely deserialize the request, and a crafted payload sends the server into an infinite loop. The process hangs, keeps burning CPU and stops answering other requests.

No account is needed: it happens before any login. No Server Function of your own is needed either: the React team warns that an app can be vulnerable as soon as it supports React Server Components. And one request is enough, because Node.js runs your server's JavaScript on a single thread per process. The Node.js documentation describes the general case: input that blocks that thread keeps the server from working for other clients, which is a denial of service.

What a stranger can and cannot do

• Take your app offline. A crafted request hangs the server process that receives it. If your app runs as one next start process on a VPS, that is the whole site.
• Keep it offline. The request is cheap to repeat and CISA rates the attack as automatable, so a restart only lasts until the next one arrives.
• Nothing more. This CVE gives no access to your data, your secrets or your code. Remote code execution in the same code was React2Shell, CVE-2025-55182, and the source code leak disclosed the same day is CVE-2025-55183.

Severity and exploitation status

Meta, the CVE numbering authority (CNA) for React, rates it 7.5, high, with the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H: reachable over the network, low complexity, no privileges, no user interaction, no impact on confidentiality or integrity, high impact on availability. NVD displays Meta's score and has not published a different one. The weakness classes are CWE-502, deserialization of untrusted data, and CWE-400, uncontrolled resource consumption.

Who is affected

Look at the first row twice. Teams on Next.js 14 sat out the React2Shell rush in December 2025 because it did not apply to them. This CVE does, and so do the 2026 follow-ups, which have no fix on Next.js 14 at all.

Hosted on Vercel, behind Cloudflare, or self-hosted

Your version decides. Hosting only changes how exposed you are until you patch. Vercel deployed WAF rules (a web application firewall filters requests before they reach your app) for this CVE to every project at no cost, and blocks new deployments of vulnerable versions. It also states that WAF rules cannot cover every variant of an attack and that upgrading is required.

Cloudflare added a managed rule on December 11, 2025, named React - DoS - CVE-2025-55184. The rule tables in its December 2025 and May 2026 changelogs give its default action as Disabled, while the rule for CVE-2026-23864 blocks, even though the May post's text says both block by default. If you count on Cloudflare in front of a self-hosted app, open the Managed Ruleset in your dashboard and check what that rule does. On a server you run yourself with next start, in a container or on a VPS, you only have the filters you set up, and a single process is a single point of failure.

How to check if your app is affected

Check the version that is installed, not the range in package.json: "next": "^14.1.0" can still resolve to 14.1.0 in your lockfile. Run these at the root of your project:

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

# pnpm (add -r in a monorepo)
pnpm why next

# yarn
yarn why next

# the version Next.js reports for itself
npx next --version

Read it from the lockfile

# package-lock.json
grep -A1 '"node_modules/next"' package-lock.json

# pnpm-lock.yaml
grep -E '^  /?next@' pnpm-lock.yaml

# yarn.lock (Yarn 1 and Yarn Berry)
grep -A1 -E '^"?next@' yarn.lock

Check what production runs

A patched repository says nothing about a build that was never redeployed. Open your live site, open the browser console and type next.version: Vercel's bulletin lists it as a way to read the running version. To see whether production serves React Server Components at all, send your own app the header the App Router uses for RSC requests:

curl -s -o /dev/null -D - -H "RSC: 1" https://your-app.example/ | grep -i content-type

How to fix CVE-2025-55184

There is no workaround: the Next.js team says upgrading is required. The fixes came in two steps on December 11, 2025, because the first one missed some payloads:

Those floors are history. In January 2026 the React team found more denial of service cases (CVE-2026-23864) and declared 19.0.3, 19.1.4 and 19.2.3 incomplete too. Three more CVEs followed in April, May and July 2026, and another React advisory in October 2026 (CVE-2026-94482 on the Next.js side). Next.js 13 and 14 got no fix for any of them: the January Next.js advisory already lists every version from 13.0.0 up to 15.0.8 as affected, and from April on the fixes ship only on the 15.5 and 16 lines. So the target is the current patch of a supported line:

# Next.js 16 (Active LTS), current patch on November 6, 2026
npm install [email protected]

# Next.js 15 (Maintenance LTS), if 16 is not possible yet
npm install [email protected]

# the same with pnpm or yarn
pnpm add [email protected]
yarn add [email protected]

# React Router, Waku, Parcel, the Vite RSC plugin, RedwoodSDK:
# update React and the server package your bundler uses (webpack, parcel or turbopack)
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Outside Next.js, the React server packages need at least 19.0.9, 19.1.10, 19.2.9 or 19.3.1, the versions that fix the October 2026 advisory GHSA-h3gv-c5rc-p453; the latest release is 19.3.1. Stuck on Next.js 13 or 14 for now? 14.2.35 closes this CVE but none of the 2026 ones, so treat it as a stopgap while you plan the move.

What to do after upgrading

1. 1

   Confirm production runs the fix

   Redeploy, then type next.version in the console of your live site. A build cache or an old container image can keep the vulnerable version online.

2. 2

   Protect old deployments

   Preview deployments built before the fix still run the old code. Vercel recommends Standard Protection on every deployment except your production domain, and a review of the shareable links that point to previews.

3. 3

   Rotate secrets only if another CVE applies

   This bug reads nothing, so it is no reason on its own to rotate keys. If your next version was also below the React2Shell fix, follow the React2Shell page. If secrets are written in plain text inside Server Functions, CVE-2025-55183 could expose them, and those need rotating.

4. 4

   Make a hung process cost less

   Learn the symptom: a Node.js process pinned on CPU that stops answering while timeouts climb. More than one instance, behind a health check that restarts a process that stops responding, limits the damage of this whole class of bug. It does not replace the upgrade.

Related CVEs in the same family

CVE-2025-55184 was found by researchers studying the React2Shell patch, and more bugs followed in the same decoding code. Each row below needs a newer version than the one before it.

Next.js has also fixed two denial of service bugs of its own in App Router apps with Server Actions, CVE-2026-64641 (July 2026) and CVE-2026-94482 (October 2026). 16.4.5 and 15.5.29 include both.

Timeline

What Keybrum checks on a live app

Keybrum never sends a denial of service payload: hanging a server to prove a point is downtime for its owner. So for this CVE, a Keybrum attack proves the surface, not the bug. With one ordinary request carrying the RSC header, it confirms that your production domain answers the React Server Components protocol, counts the Server Action ids your JavaScript ships, and reports the version floor for the whole family, CVE-2025-55184 and CVE-2025-67779 included. The version check above tells you whether that surface runs a patched release.

The Next.js security guide covers the rest of the framework, and vibe coding security risks covers what AI-built apps leak most often.