React Server Components CVE-2026-23864 What you need...

If you woke up this morning to a Slack message from your security team, you're not alone. CVE-2026-23864 just dropped, and it's affecting pretty much every Next.js project running Server Components.

Before you panic: no, attackers can't run code on your server. But they can crash it. Let's break down what's happening and how to fix it.

What's the vulnerability?

The CVE addresses multiple denial of service vulnerabilities in React Server Components. A malicious actor can send specially crafted HTTP requests to your Server Function endpoints that cause:

Server crashes
Out-of-memory exceptions
Excessive CPU consumption

What makes this particularly nasty is the attack profile. According to the GitHub security advisory:

Attack Vector: Network (remotely exploitable)
Attack Complexity: Low
Privileges Required: None
User Interaction: None

Translation: anyone on the internet can crash your server without authentication, without tricking a user into clicking anything, and without much effort. The CVSS score is 7.5 (High), which is the security equivalent of "fix this before lunch."

This isn't the first RSC vulnerability

Here's the uncomfortable truth: this CVE is part of a pattern.

Back in December 2025, CVE-2025-55182 dropped with a CVSS 10.0 - a full-blown Remote Code Execution vulnerability in React Server Functions. That one let attackers run arbitrary code on your server. The React team patched it, but security researchers kept digging.

CVE-2026-23864 is the result of that continued scrutiny. The initial DoS fixes were incomplete, and multiple denial of service vectors still existed. When a critical vulnerability gets disclosed, researchers probe adjacent code paths looking for variant exploits. This is standard practice across the industry, and it's why we're seeing follow-up CVEs.

The takeaway? RSC security is still maturing. If you're running Server Components in production, you need to stay on top of patches.

Get security alerts before they hit the news

We monitor CVEs affecting Next.js and Sanity so you don't have to. When something drops, you'll know.

Am I affected?

You're affected if your project uses any of these packages:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

Quick way to check:

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

# pnpm
pnpm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

# yarn
yarn why react-server-dom-webpack

If you see any of these packages in versions 19.0.0 through 19.2.3, you're vulnerable.

Not affected? If your app doesn't use React Server Components or Server Functions, you're in the clear. Traditional client-side React apps without SSR aren't impacted.

What's affected?

React packages

| Package | Vulnerable | Patched | | --- | --- | --- | | react-server-dom-webpack | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 | | react-server-dom-parcel | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 | | react-server-dom-turbopack | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 |

Frameworks

Next.js: 13.x, 14.x, 15.x, and 16.x
React Router (with RSC)
Waku
RedwoodSDK
Vite (with @vite/rsc-plugin)
Parcel (with @parcel/rsc)

If you're running React Server Components on any of these, assume you're affected until you verify otherwise.

The fastest fix

Stop reading and run this:

# For Next.js projects
npx @next/codemod@canary upgrade latest

That's it. One command. Coffee's still hot.

If you can't upgrade immediately

Vercel and Akamai have both deployed WAF rules to protect hosted projects. If you're on either platform, you've got some breathing room while you schedule the upgrade.

But here's the thing: WAF rules are a temporary mitigation, not a fix. The React team and framework maintainers are clear on this - you still need to update. Don't let the safety net become an excuse to delay.

If you're self-hosting without a WAF... well, you're on your own. Prioritise the upgrade.

Patched versions

| Framework | Patched versions | | --- | --- | | React | 19.0.4, 19.1.5, 19.2.4 | | Next.js 15.x | 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10 | | Next.js 16.x | 16.0.11, 16.1.5 |

Pick the one that matches your current minor version and upgrade.

What if you're stuck on an older version?

We get it. Not everyone can upgrade on a whim. Legacy codebases, pending migrations, that one feature flag nobody wants to touch because "it works."

Here are your options:

Upgrade to the nearest patched version - This is the path of least resistance. A patch version bump shouldn't break anything. (Famous last words, but still.)
Hide behind a WAF - Vercel and Akamai have automatic protection. If you're on either platform, you're covered temporarily.
Rate limit your Server Functions - Add aggressive rate limiting to your Server Action endpoints. Won't stop a determined attacker, but raises the bar.
Actually, just upgrade - We've helped clients upgrade hundreds of Next.js projects. It's usually less painful than you think. We can do it for you if you're short on time.

Why this matters for agencies

If you're an agency or consultancy, now's a good time to audit your client projects. A quick npm ls next or pnpm ls next will tell you where you stand.

For each affected project:

Check the current Next.js version
Identify the nearest patched version
Test locally, then deploy

If you've got dozens of projects to update, this could take a while. Or you could reach out and let us handle the heavy lifting.

TL;DR

| What | Details | | --- | --- | | CVE | 2026-23864 | | Severity | High (7.5) | | Impact | DoS via memory exhaustion - server crashes, not RCE | | Attack profile | Network, low complexity, no auth required | | Fix | Upgrade to patched React/Next.js | | Fastest command | npx @next/codemod@canary upgrade latest |

React Server Components CVE-2026-23864: What you need to know