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
- What is the React Server Components vulnerability?
- Vulnerable and fixed versions
- What it means for Next.js
- Same day, more fixes you want too
- Am I affected?
- Check your Next.js version
- Check other React Server Components setups
- How to fix the React Server Components vulnerability in Next.js
- Next.js 16
- Next.js 15
- Next.js 14 or older
- Build and test
- How to fix it in Waku, React Router and other setups
- When the old version is a dependency of a dependency
- Deploy the fix and check that it's live
- Was I hacked?
- FAQ
- What is GHSA-xqc2-xf4c-x3h3?
- Does the React Server Components vulnerability have a CVE?
- Am I affected if I only use React in the browser?
- Does updating react and react-dom fix Next.js?
- Is there a workaround if I can't update right now?
- Which Next.js version fixes the React Server Components vulnerability?
- Conclusion
- Related guides
- Your turn
The Short Version
- Check if you use React Server Components. If you use the Next.js App Router, you do.
- Find your version with
npm ls next(Next.js) ornpm ls react-server-dom-webpack(everything else). - 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 |
- Commit the lockfile, rebuild and redeploy.
- 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-webpackreact-server-dom-turbopackreact-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:
'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:
npm ls nextWith other package managers:
pnpm why nextyarn why nextbun pm ls | grep nextIf 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
npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcelYou’ll see something like this:
my-app@1.0.0 /home/you/my-app
└─┬ waku@1.0.0-rc.3
└── react-server-dom-webpack@19.3.0Compare 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:
git switch -c fix/next-security-updateNext.js 16
npm install next@16.4.5pnpm add next@16.4.5yarn add next@16.4.5bun add next@16.4.5Next.js 15
Same commands, different version:
npm install next@15.5.29Next.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
npm run buildThe first line of the build output shows the version, for example ▲ Next.js 16.4.5. Then start it and click through your app:
npm run startIf everything works, commit both package.json and your lockfile. Without the lockfile, your server might install the old version again.
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:
npm install react@19.3.1 react-dom@19.3.1 react-server-dom-webpack@19.3.1Swap 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:
{
"overrides": {
"react-server-dom-webpack": "19.3.1"
}
}pnpm, in pnpm-workspace.yaml:
overrides:
react-server-dom-webpack: 19.3.1Yarn, in package.json:
{
"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(orpnpm 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, runnpm 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:
- Rotate every secret the server had access to: environment variables, database passwords, API keys, tokens.
- Look at your server for things you didn’t put there: new files, unknown processes, unexpected outbound connections, CPU spikes.
- 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.
Related guides
- Add Google AdSense to Next.js
- Getting Started in Cybersecurity, if this made you curious about the other side
- Official: React advisory GHSA-xqc2-xf4c-x3h3
- Official: Next.js advisory GHSA-673q-mjm6-r5xr
Your turn
Got stuck on the upgrade, or found something weird in your logs? Tell me on X @StefanRows.
More posts
All Web Development

