CVE-2026-23864: the React Server Components DoS, affected versions and fix

What CVE-2026-23864 is, in plain words

React Server Components (RSC) run part of a React app on the server. Server Functions, called Server Actions in Next.js, are functions on the server that the browser calls with an HTTP POST request, and React decodes the body of that request on the server before your code sees it. CVE-2026-23864 covers several bugs in that decoding: a specially crafted request can crash the server, cause out-of-memory exceptions or burn CPU, depending on the code path it reaches, the app's configuration and its own code. The bugs live in three npm packages, react-server-dom-webpack, react-server-dom-turbopack and react-server-dom-parcel, and in every framework that ships them.

The React team published it on January 26, 2026, after security researchers found more denial of service cases in code it had already patched twice in December 2025. Its blog post is blunt about it: the earlier fixes were incomplete, and anyone who had updated to 19.0.3, 19.1.4 or 19.2.3 had to update again. Vercel's summary credits Mufeed VH of Winfunc Research, Joachim Viide, RyotaK of GMO Flatt Security and Xiangwei Zhang of Tencent Security YUNDING LAB.

What it does not do matters as much. It runs no code on your server and reads no data: Vercel states that these bugs do not allow remote code execution, and the CVSS vector rates confidentiality and integrity as untouched. The cost is downtime. A self-hosted next start server is a single Node.js process by default, so while that process is stuck on CPU or restarting after a crash, the whole site stops answering.

Affected and fixed versions

Two advisories carry the ranges: GHSA-83fc-fqcc-2hmg for the React packages and GHSA-h25m-26qc-wcjf for Next.js. In a Next.js app, the next rows are the ones to read.

Severity and exploitation status

The line to weigh is automatable: no login and no user action means a script can send these requests on its own.

Who is affected

Your app is affected if a server runs React Server Components with one of the vulnerable package versions. In practice:

• Next.js 13.x to 16.x with the App Router (an app directory), below the fixed release of its line. The Next.js advisory names the App Router, so a project that only uses the pages directory is outside its scope.
• Other RSC frameworks and plugins. Vercel's summary lists Vite, Parcel, React Router, RedwoodSDK and Waku setups that embed React Server Components. There, the react-server-dom-* version in your lockfile decides.
• Not affected: React code that only runs in the browser. The React advisory says an app whose React code does not use a server, or that uses no framework, bundler or plugin with React Server Components support, is not affected. A single page app or a Next.js static export (output: 'export') fits that description.

Server Actions are not the dividing line. The advisories describe the trigger as a request to a Server Function endpoint, but neither says that an App Router app without Server Actions is safe. If you run the App Router on an affected version, treat the app as affected.

Vercel, Netlify, Cloudflare or your own server

How to check if your app is affected

Read the version that is installed, not the range in package.json: "next": "^15.1.0" installs whatever your lockfile pinned, which can be years old. Run these at the root of the project:

# npm
npm ls next

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

# yarn
yarn why next

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

# other RSC frameworks: the React server packages
npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel

Read it from the lockfile

# package-lock.json
grep -A2 '"node_modules/next": {' package-lock.json

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

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

Check what production runs

A fixed lockfile proves nothing about a build that never shipped. Load a page of your live app and type next.version in the browser console: Vercel's React2Shell bulletin gives it as the way to read the running version. To see whether production answers React Server Components requests at all, send your own app the header the App Router uses:

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

How to fix CVE-2026-23864

Upgrade, rebuild and redeploy. Neither advisory offers a setting that turns the flaw off. Aim above the fixed versions in the table: React has shipped new server package releases on every line since January, the latest being 19.0.9, 19.1.10, 19.2.9 and 19.3.1 on October 14, 2026, and Cloudflare's May 2026 changelog covers newly disclosed denial of service bugs in the same code. The current Next.js patches, from the November 2026 security release, are 16.4.5 on the Active LTS line and 15.5.29 on the Maintenance LTS line.

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

# Next.js 15, Maintenance LTS, if 16 is out of reach for now
npm install [email protected]

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

# React Router, Waku, RedwoodSDK, Vite or Parcel RSC setups:
# keep react, react-dom and the server package on the same version
npm install react@latest react-dom@latest react-server-dom-webpack@latest

On Next.js 13 or 14, there is no patch to install. The advisory's first range runs from 13.0.0 up to 15.0.8, and the last 14.x release, 14.2.35, came out on December 11, 2025, before this CVE existed. Moving to 15.5 or 16 is a major upgrade: plan it with the Next.js upgrade guides, and keep a WAF in front of the app until it ships.

If you cannot upgrade today

• Put a WAF in front. On Vercel the rules are already there. With Cloudflare, proxy the app's DNS record and check that the CVE-2026-23864 rules in the Managed Ruleset are set to Block.
• Run more than one instance, behind a health check that restarts a process that stops answering. A stuck process then costs one instance, not the whole site.
• Rate limit POST requests to your pages at the proxy. It caps how much a stranger can send, though one expensive request can still get through.
• Learn the symptom: a Node.js process pinned at full CPU, memory that climbs until the process dies, or restarts that follow bursts of POST requests.

What to do after upgrading

1. 1

   Confirm production runs the fix

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

2. 2

   Rebuild every environment

   Preview and staging deployments built before the upgrade keep running the old code. Rebuild or delete them, and check every app in a monorepo.

3. 3

   Skip the key rotation, unless another CVE applies

   This bug reads nothing, so it is no reason by itself to rotate secrets. If your next version was also below the React2Shell fix, follow the CVE-2025-55182 page: that one allowed remote code execution.

4. 4

   Turn on advisory alerts

   Dependabot alerts on GitHub, or npm audit in your build, flag new advisories on next and the React server packages once they reach the GitHub Advisory Database.

Related CVEs in the same family

CVE-2026-23864 is the fifth CVE in React Server Components in eight weeks. A release that fixes a later row also contains the fixes above it on the same line.

Timeline

What Keybrum checks on a live app

Keybrum never sends a denial of service payload: crashing a server to prove a point is downtime for the person who asked for the test. So for this CVE it proves the surface, not the bug. With one ordinary request carrying the RSC header, it checks whether your production domain answers the React Server Components protocol and counts the Server Action ids your JavaScript ships. The report then lists the React2Shell family, its denial of service CVEs included, as not tested. The version checks above tell you whether that surface is patched.

For the rest of the framework, read the Next.js security guide. For what AI-built apps leak most often, see vibe coding security risks.