React Server Components Vulnerability: How to Fix the RCE

React Server Components Vulnerability: How to Fix the RCE

The React Server Components vulnerability from October 14, 2026 (GHSA-xqc2-xf4c-x3h3) lets an attacker run code on your server without logging in. The fix is an update. On Next.js 16, run npm install next@16.4.5. On Next.js 15 or older, run npm install next@15.5.29. On any other React Server Components setup, update react-server-dom-webpack (or -turbopack, or -parcel) to 19.3.1, together with react and react-dom. Then rebuild and redeploy.

I know, I know. Another one. React2Shell was last December, and React Server Components have had a new advisory every few months since. This one is critical again: a CVSS score of 9.5 out of 10, and it’s unauthenticated remote code execution. Someone on the internet sends your server a request, and your server runs their code.

The good news: the exact condition to exploit it is rare. The bad news: you can’t easily tell if your app hits it, and proof-of-concept code is already public on GitHub. So don’t think about it for too long. Patch.

This guide is for beginners. If you’ve never read a security advisory before, that’s fine. I’ll walk you through what it means, how to check if you’re affected, and how to fix it with npm, pnpm, Yarn or Bun.

Table of Contents

The Short Version

  1. Check if you use React Server Components. If you use the Next.js App Router, you do.
  2. Find your version with npm ls next (Next.js) or npm ls react-server-dom-webpack (everything else).
  3. Update to a fixed version:
You use Update to
Next.js 16 next@16.4.5
Next.js 15 next@15.5.29
Next.js 14 or older next@15.5.29 (a major upgrade, see below)
Waku, React Router RSC, RedwoodSDK, Parcel, Vite RSC plugin react-server-dom-*@19.3.1 plus react and react-dom 19.3.1
  1. Commit the lockfile, rebuild and redeploy.
  2. Check that production actually runs the new version.

What is the React Server Components vulnerability?

React Server Components are components that run on your server instead of in the browser. The server renders them and sends the result to the browser in a special format. React calls it the Flight protocol. The code that writes and reads that format lives in three npm packages:

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

The bug is in those packages. With a crafted payload, an attacker can get the server to execute code. According to the React team, it only works in “extremely rare cases”: when a response carries multiple typed arrays together with a value the attacker controls.

Typed arrays, in case you haven’t met them: they’re JavaScript’s way of holding raw binary data. Uint8Array, Float32Array and Node’s Buffer are all typed arrays. If your server code returns image bytes, file chunks or anything binary, you probably have some.

Here are the facts from the advisory in one place:

Advisory GHSA-xqc2-xf4c-x3h3
Published October 14, 2026
Severity Critical, CVSS 4.0 score 9.5
CVE None assigned at the time of writing
Attack Over the network, no login, no user interaction
Found by evolutionstorm
Workaround None. You have to update.

Vulnerable and fixed versions

Version line Vulnerable Fixed
19.0 19.0.0 to 19.0.8 19.0.9
19.1 19.1.0 to 19.1.9 19.1.10
19.2 19.2.0 to 19.2.8 19.2.9
19.3 19.3.0 19.3.1

These ranges apply to all three react-server-dom-* packages.

What it means for Next.js

Next.js published its own advisory for the same bug the same day: GHSA-673q-mjm6-r5xr. In Next.js, it affects 16.0.0 through 16.4.0, and it hits apps that use the App Router with Cache Components and have a use cache function that returns multiple typed arrays. Something like this:

tsts
'use cache'

export async function getAssets(id: string) {
  const original = await loadImage(id)   // Uint8Array
  const preview = await loadPreview(id)  // Uint8Array
  return { id, original, preview }
}

The fix landed in 16.4.1. And the Next.js team says to upgrade even if your app has no function like that. I agree. Don’t spend an afternoon grepping your codebase to prove you’re safe. Updating takes five minutes.

Same day, more fixes you want too

October 14 was a busy day. These went out together:

  • React: a high severity denial of service in Server Functions (GHSA-h3gv-c5rc-p453). Same fixed versions as above.
  • Next.js: a second critical RCE, this time in the Image Optimization API when SVG files are used (GHSA-2464-fhr4-w9xw). It affects Next.js 10 through 15.5.27 and 16.x up to 16.4.0. It isn’t limited to the App Router.
  • Next.js: a high severity denial of service in App Router Server Actions (GHSA-p3m5-59mp-jv5r).

Then on November 3, Next.js shipped seven more medium severity fixes, mostly around caching and cookies, in 16.4.5 and 15.5.29. That’s why I tell you to go straight to 16.4.5 or 15.5.29 instead of the minimum version that fixes the RCE. Same effort, more holes closed.

Am I affected?

You’re not affected by the React Server Components vulnerability if your React code never runs on a server. A Vite single-page app, an old Create React App project or a React Native app doesn’t use these packages.

You’re probably affected if you use any of these:

  • Next.js with the App Router
  • React Router in RSC mode
  • Waku
  • RedwoodSDK
  • Parcel with React Server Components
  • The Vite RSC plugin (@vitejs/plugin-rsc)

And if you use Next.js at all, update anyway. The SVG image RCE from the same day doesn’t care which router you use.

Check your Next.js version

Open a terminal in your project folder and run:

Terminalbash
npm ls next

With other package managers:

Terminalbash
pnpm why next
Terminalbash
yarn why next
Terminalbash
bun pm ls | grep next

If the version is 16.4.4 or lower, or 15.5.28 or lower, you need to update.

One thing that confuses a lot of people: Next.js ships its own copy of React’s server packages inside the next package. So npm ls react-server-dom-webpack shows nothing on a Next.js app. That’s normal. For Next.js, the next version is the only one that counts.

Check other React Server Components setups

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

You’ll see something like this:

Snippettext
my-app@1.0.0 /home/you/my-app
└─┬ waku@1.0.0-rc.3
  └── react-server-dom-webpack@19.3.0

Compare the version with the table above. 19.3.0 is vulnerable, 19.3.1 is fixed.

npm audit may flag it as well, but don’t rely on that alone. Check the versions yourself.

How to fix the React Server Components vulnerability in Next.js

Start on a clean branch, so you can roll back if something breaks:

Terminalbash
git switch -c fix/next-security-update

Next.js 16

Terminalbash
npm install next@16.4.5
Terminalbash
pnpm add next@16.4.5
Terminalbash
yarn add next@16.4.5
Terminalbash
bun add next@16.4.5

Next.js 15

Same commands, different version:

Terminalbash
npm install next@15.5.29

Next.js 14 or older

There’s no patched Next.js 14 release for the SVG image RCE. Your options are to upgrade to 15.5.29 (or straight to 16.4.5), or stay vulnerable. That’s a major version jump, not a patch, so follow the official Next.js upgrade guide and give it a proper test. It’s worth it. Next.js 14 isn’t getting these fixes.

Build and test

Terminalbash
npm run build

The first line of the build output shows the version, for example ▲ Next.js 16.4.5. Then start it and click through your app:

Terminalbash
npm run start

If everything works, commit both package.json and your lockfile. Without the lockfile, your server might install the old version again.

Terminalbash
git add package.json package-lock.json
git commit -m "fix: update next to 16.4.5 for security advisories"

On pnpm the lockfile is pnpm-lock.yaml, on Yarn it’s yarn.lock, and on Bun it’s bun.lock.

How to fix it in Waku, React Router and other setups

Here you update the React server package directly. Version 19.3.1 of react-server-dom-webpack requires react and react-dom 19.3.1, so update all three together:

Terminalbash
npm install react@19.3.1 react-dom@19.3.1 react-server-dom-webpack@19.3.1

Swap react-server-dom-webpack for react-server-dom-turbopack or react-server-dom-parcel if that’s what npm ls showed you. If you can’t move to 19.3 yet, use the fixed version of your line from the table (for example 19.2.9), and keep react and react-dom on that same version.

Update your framework to its latest release too. Waku, RedwoodSDK and the Vite RSC plugin pull in these packages themselves, so a framework update is often what brings in the fix.

When the old version is a dependency of a dependency

Sometimes you update everything and npm ls still shows 19.3.0, nested under your framework. That means the framework pins the old version. You can force the fixed one with an override.

npm and Bun, in package.json:

jsonjson
{
  "overrides": {
    "react-server-dom-webpack": "19.3.1"
  }
}

pnpm, in pnpm-workspace.yaml:

yamlyaml
overrides:
  react-server-dom-webpack: 19.3.1

Yarn, in package.json:

jsonjson
{
  "resolutions": {
    "react-server-dom-webpack": "19.3.1"
  }
}

Run npm install (or pnpm install, yarn, bun install) and check npm ls again. Treat the override as temporary. Once your framework ships a release with the fix, remove it.

Deploy the fix and check that it’s live

Your laptop being patched means nothing. Production is what gets attacked.

  • Vercel, Netlify and similar: push your branch, merge it, and the platform rebuilds. Check the build log for the new version.
  • CI pipelines: make sure your build runs npm ci (or pnpm install --frozen-lockfile), so it installs exactly what’s in your lockfile.
  • Docker: rebuild the image and restart the container. An old image keeps running the old code, no matter what your repo says.
  • A VPS with PM2 or systemd: pull, run npm ci, run npm run build, then restart the process.

Then look at the build log on the server or platform, not on your machine. For Next.js, it should say ▲ Next.js 16.4.5 or ▲ Next.js 15.5.29.

Don’t count on your hosting provider’s firewall to catch this one. I couldn’t find any platform-level mitigation announced for it. Patch and redeploy.

Was I hacked?

Probably not. The condition is rare. But “probably” isn’t great for a 9.5, so here’s how I’d think about it.

If your app ran a vulnerable version on the public internet and your code matches the pattern (on Next.js: a use cache function returning several typed arrays), assume the server could have been read. Then:

  1. Rotate every secret the server had access to: environment variables, database passwords, API keys, tokens.
  2. Look at your server for things you didn’t put there: new files, unknown processes, unexpected outbound connections, CPU spikes.
  3. Check your logs for crashes or weird requests to your server endpoints between October 14 and the day you patched.

If your code doesn’t match the pattern, patching is enough for most people. Rotating secrets after any critical RCE is still a good habit, though.

FAQ

What is GHSA-xqc2-xf4c-x3h3?

It’s the GitHub security advisory ID for the React Server Components vulnerability published on October 14, 2026. It’s a critical, unauthenticated remote code execution bug in react-server-dom-webpack, react-server-dom-turbopack and react-server-dom-parcel. Fixed versions are 19.0.9, 19.1.10, 19.2.9 and 19.3.1.

Does the React Server Components vulnerability have a CVE?

Not at the time of writing (November 9, 2026). Both the React advisory and the Next.js advisory list no CVE. Search for the GHSA IDs instead: GHSA-xqc2-xf4c-x3h3 for React and GHSA-673q-mjm6-r5xr for Next.js.

Am I affected if I only use React in the browser?

No. If your React code never runs on a server, and you don’t use a framework or bundler plugin with React Server Components, you’re not affected.

Does updating react and react-dom fix Next.js?

No. Next.js ships its own copy of the React server packages inside next. You have to update next itself, to 16.4.5 or 15.5.29.

Is there a workaround if I can’t update right now?

No. Neither React nor Next.js lists a workaround. Updating is the only fix.

Which Next.js version fixes the React Server Components vulnerability?

Next.js 16.4.1 is the first version with the fix. I recommend 16.4.5 on Next.js 16 and 15.5.29 on Next.js 15, because they also include the fixes from November 3.

Conclusion

The fix for the React Server Components vulnerability is boring, which is the best kind of fix. Check your version, update next or the react-server-dom-* package, commit the lockfile, redeploy and confirm the version in production. Five minutes if you’re on a supported version, an afternoon if you’re stuck on Next.js 14.

React Server Components have had a lot of advisories this year. So set up Dependabot or Renovate, or at least watch the React and Next.js repositories for security releases. You’ll want to hear about the next one before it’s on the news.

Your turn

Got stuck on the upgrade, or found something weird in your logs? Tell me on X @StefanRows.