“There are only two types of companies: those that have been breached and know it, and those that have been breached and don’t know it yet.”
It’s a dramatic quote from John Chambers, but it fits the mood. React recently disclosed a high-severity vulnerability in React Server Components. No, it doesn’t allow remote code execution. Yes, it can still take your server down if left unpatched.
In this post, we’ll break down what CVE-2026-23864 actually is, what went wrong with React Server Components, which React and Next.js versions were affected, and what you need to upgrade right now, alongside what you should do in the future to stay safe.
What is CVE-2026-23864?
CVE-2026-23864 is a denial-of-service vulnerability in React Server Components. It does not allow remote code execution, but it can still take your server down.
The issue sits in how React Server Components handle and deserialize requests sent to Server Function endpoints. Specially crafted HTTP requests can trigger:
- Excessive CPU usage
- Out-of-memory errors
- Server crashes
This affects the React Server Components runtime itself, specifically the packages that power it:
react-server-dom-webpackreact-server-dom-parcelreact-server-dom-turbopack
If you’re using a framework that builds on top of these (spoiler: most modern ones do), you inherit the problem whether you asked for it or not. This vulnerability is cheap to exploit and expensive to recover from, as it does not require authentication or clever chaining. Just enough malformed requests to keep your servers busy doing absolutely nothing useful.
What went wrong with React Server Components?
React Server Components assume that incoming requests are well-formed. CVE-2026-23864 showed what happens when that assumption breaks.
Certain code paths in the Server Components implementation don’t defend well against malformed or deeply nested payloads. When those payloads are deserialized, the server ends up doing far more work than it should. This wasn’t a single bug. It was multiple incomplete safeguards around request handling that, together, made denial-of-service attacks possible. Earlier fixes didn’t fully close those gaps, which is why this resurfaced as a high-severity issue.
Nothing exotic failed here, like edge cases. Just normal servers being asked to process bad input and not knowing when to stop.
Which React and Next.js versions were affected?
As we said earlier, the vulnerability affects React Server Components, not React as a whole. Specifically, it impacts the packages that implement the Server Components runtime.
Affected React packages
All versions below are vulnerable:
react-server-dom-webpack: 19.0.0 → 19.2.3react-server-dom-parcel: 19.0.0 → 19.2.3react-server-dom-turbopack: 19.0.0 → 19.2.3
If your project pulls in any of these versions, it is affected.
Affected Next.js versions
Because Next.js embeds React Server Components, the impact rolls straight downhill:
- Next.js 13.x, 14.x, 15.x, and 16.x
- Specifically, any version:
< 15.0.8< 15.6.0-canary.61< 16.1.5
This applies to apps using the App Router.
If you’re running an older Next.js version and haven’t upgraded recently, assume you’re vulnerable and move on to patching.
Patching
Mitigations were rolled out quickly. Vercel deployed new WAF rules across its platform to reduce the blast radius. That helps, but it’s not the fix. The fix is upgrading.
The vulnerability is resolved in patched releases of React and downstream frameworks. If you’re running an affected version, you need to move to one of these.
Fixed React versions
- 19.0.4
- 19.1.5
- 19.2.4
Fixed Next.js versions
- 15.0.8
- 15.1.12
- 15.2.9
- 15.3.9
- 15.4.11
- 15.5.10
- 15.6.0-canary.61
- 16.0.11
- 16.1.5
- 16.2.0-canary.9
If you’re using another framework or bundler that embeds React Server Components, install the latest version provided by its maintainers. The vulnerability lives in the shared runtime, so downstream projects inherit both the bug and the fix.
One thing we need to clear up. The WAF is not a substitute for upgrading. It reduces risk, but it doesn’t eliminate it. Leaving vulnerable versions in production and hoping edge rules save you is how outages happen.
Our unsolicited advice is to patch, deploy, and verify. Then you can stop thinking about this.
How we make sure our websites don’t quietly fall apart.
We don’t do anything fancy here. We just audit dependencies regularly and take the results seriously.
Every so often (and always before shipping), we run an audit using the package manager we’re already on. For us, that’s usually pnpm audit. If you’re on npm, same idea with npm audit. Different tool, same pain.
What this gives you is a list of known vulnerabilities in your installed dependencies, not theoretical ones. If something shows up, the first step is boring and effective: update.
- Run
pnpm update - See what disappears
- Repeat until it doesn’t
If an update doesn’t fully fix things, we force it. Overrides exist for a reason. If a vulnerable version is being pulled in transitively, we pin a safe version and move on. You can also let pnpm do the work with pnpm audit --fix, which adds overrides automatically. It’s not magic, but it saves time.
Don’t wait for the next advisory.
Remember that most frameworks are built on a lot of shared assumptions, and when one of them breaks, the fallout spreads fast. The good news is this was caught, disclosed responsibly, and patched. The better news is that fixing it is straightforward. The only real mistake here is pretending it doesn’t apply to you.
React Server Components are still evolving, and incidents like this are part of that process. If you’re building on top of them, staying secure mostly comes down to doing the unglamorous work consistently. If you want help reviewing your setup, tightening your upgrade process, or just making sure you’re not missing something obvious, get in touch with us. We’re happy to take a look before the next CVE does.