React Server Components CVE-2026-126187 Explained: 9.5 RCE Flaw, Public PoC and the Versions to Patch

The React logo. Image: React / Facebook — official logo (via Wikimedia Commons)

TL;DR: React Server Components CVE-2026-126187 explained: it is an unauthenticated remote code execution flaw in React's server-side Flight protocol, rated 9.5 out of 10. The fix has existed since 14 October 2026, the CVE was published on 10 November, and proof-of-concept exploit code appeared on GitHub on 11 November — yet about 75% of weekly downloads of the main affected package were still on vulnerable versions.

Key Highlights

• The flaw: CVE-2026-126187 (GHSA-xqc2-xf4c-x3h3) — unauthenticated remote code execution in React Server Components, CVSS 4.0 score 9.5, classed as deserialization of untrusted data (CWE-502).
• What is affected: react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack, versions 19.0.0–19.0.8, 19.1.0–19.1.9, 19.2.0–19.2.8 and 19.3.0 — but only in the "extremely rare" case React describes, where a response transports multiple typed arrays plus an attacker-controlled value.
• The fix: upgrade to 19.0.9, 19.1.10, 19.2.9 or 19.3.1 — published to npm on 14 October 2026. Next.js apps should also be on 16.4.1 or later.
• The catch: public proof-of-concept code has been on GitHub since 11 November, and a 13 November read of npm downloads found 75% of react-server-dom-webpack downloads (3.1M of 4.2M) still on affected versions.
• What is NOT true: no confirmed exploitation in the wild has been reported, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Most React apps — anything without a server — are not affected at all.

What happened?

On 14 October 2026, the React team quietly published a security fix and a repository advisory for a remote code execution flaw in React Server Components. The advisory carried no CVE number at the time, so scanners and dependency tools that key off CVE identifiers largely missed it. On 10 November, GitHub's advisory database assigned the flaw its CVE identifier — CVE-2026-126187 — and rated it 9.5, Critical, on CVSS 4.0. Within a day, working proof-of-concept code appeared on GitHub, and security researchers reproduced the exploit chain in a lab against React 19.2.8. The Hacker News flagged the public exploit code on 11 November, and coverage through 12–13 November has focused on the same uncomfortable fact: the patch is a month old, yet most installs have not taken it.

The researcher credited with finding the flaw is the GitHub user evolutionstorm. The same disclosure window also covered two related Next.js issues fixed on the same day — a use cache remote code execution flaw in Next.js 16 and an image-optimisation flaw — which is why Next.js users hear about this bug from two directions at once. The React flaw is the underlying one: it lives in React's own server-side packages, so any framework built on React Server Components can carry it, not just Next.js. It was a busy patch week overall: Citrix patched 31 NetScaler flaws, and Microsoft's November Patch Tuesday fixed 1,094 flaws, including an actively exploited Outlook zero-day.

React Server Components CVE-2026-126187 explained — how the flaw works

React Server Components move rendering to the server and stream the result to the browser through Flight, a wire protocol that carries far more than JSON: promises, module references, server-function references, binary blobs and typed arrays. The vulnerability sits in how the server-side Flight packages deserialise that stream. When a response transports multiple typed-array views over one shared ArrayBuffer together with an attacker-controlled value, a crafted payload can confuse the deserialiser into executing code the server was never meant to run. GitHub's advisory database classifies the weakness as CWE-502, deserialization of untrusted data.

React's own advisory stresses the narrowness of the trigger: it affects "extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value". In practice, the realistic path is Next.js 16's Cache Components feature, where a function marked use cache returns a value that is serialised through Flight, stored as a cache entry and deserialised back inside the Node.js server process on later requests. That is the configuration the public proof of concept targets, using a Next.js 16.4.0 app on React 19.3.0. Ordinary server-rendered pages, client-side React apps and apps that never return typed arrays from cached functions do not meet the precondition.

The fix, in React pull request #37846 and related changes, tightens the Flight transport: it rejects promise-like values in the wrong places, requires bound arguments to be genuine arrays, hides the internal response object, clones views that span shared buffers and throws on detached buffers. The patched releases — 19.0.9, 19.1.10, 19.2.9 and 19.3.1 — have been on npm since 14 October, so for most teams this is a version bump, not a code change.

Illustrative image: a data centre building exterior. Image: Ana Las Heras, CC BY-SA 4.0 (via Wikimedia Commons)

Affected and fixed versions

Check your lockfile, not just package.json — lockfiles and node_modules can keep a vulnerable version installed after the manifest is edited. The command npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack --all lists every copy in your dependency tree.

Package	Affected versions	Fixed version
react-server-dom-webpack	19.0.0–19.0.8, 19.1.0–19.1.9, 19.2.0–19.2.8, 19.3.0	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1
react-server-dom-parcel	19.0.0–19.0.8, 19.1.0–19.1.9, 19.2.0–19.2.8, 19.3.0	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1
react-server-dom-turbopack	19.0.0–19.0.8, 19.1.0–19.1.9, 19.2.0–19.2.8, 19.3.0	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1

Next.js users: the framework shipped its side of the fix in Next.js 16.4.1 (and 15.5.28 for the 15 line) on 14 October; later security releases 16.4.5 and 15.5.29 were current as of 11 November. Because frameworks can pin an older react-server-dom version, verify the React package version directly rather than trusting the Next.js version alone — and use npm overrides or yarn/pnpm resolutions to force the fixed release until your framework ships an update. There is no workaround for this flaw: React's advisory says to update immediately.

Why it matters for Indian developers and teams

India has one of the world's largest React and Next.js developer bases, and React Server Components are now the default architecture for new Next.js apps — which means the affected packages sit inside countless Indian startups, agencies and enterprise front-ends, including the preview deployments, internal tools and serverless functions that rarely get patched on schedule. The 75% figure is a download share, not an install count — it includes CI runs and mirrors — but it is still a fair warning that the ecosystem has been slow to move on a fix that has existed for a month. No India-specific victim or attack has been reported, and none is claimed here; the risk for Indian teams is the same as everywhere else: an unpatched server component endpoint, a public exploit, and a narrow-but-real trigger condition.

The timing also matters for how teams triage. A 9.5 score usually means "drop everything", but the score describes an affected endpoint that meets the typed-array precondition — not every React install. The honest priority is: check whether your apps use a server with React Server Components and cached functions returning typed arrays. If they do, patch today; if they do not, the upgrade is still worth scheduling, but it is not an emergency. That distinction is exactly what React's "extremely rare" wording is for, and it is why this flaw, unlike last year's React2Shell bug, has not produced a wave of mass-scanning reports so far.

Should you care?

✅ Verdict: If you run React Server Components on a server — especially Next.js 16 with Cache Components — yes, patch today: the fix is a month old, the exploit is public, and the upgrade is a version bump. If your React code has no server, you are not affected; upgrade on your normal schedule. Do not panic about the 9.5 on its own — check the precondition first, then act on what you find.

Do this today: (1) run the npm ls command above on every service that uses React Server Components, including preview and internal deployments; (2) upgrade the three react-server-dom packages to the fixed release for your line and redeploy — a lockfile edit alone is not enough until new builds are live; (3) as a stopgap, restrict RSC endpoints to trusted networks or put a WAF rule in front of malformed Flight payloads — a temporary layer, not a substitute for patching; (4) run RSC servers with least privilege and keep long-lived cloud credentials out of their environment variables, rotating secrets if you find signs of tampering.

FAQs

What is CVE-2026-126187?
CVE-2026-126187 is an unauthenticated remote code execution flaw in React Server Components, rated 9.5 Critical on CVSS 4.0. It affects the react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack packages in React 19.0.0–19.3.0, through unsafe deserialization in the Flight protocol. The fix was published on 14 October 2026 and the CVE was assigned on 10 November.

Is my React app affected by CVE-2026-126187?
Only if your React code runs on a server and uses a framework, bundler or bundler plugin that supports React Server Components — and, in practice, only where responses transport multiple typed arrays with an attacker-controlled value. Client-only React apps are not affected, and neither are apps without an RSC-supporting framework. Check your lockfile for the three named packages to know for sure.

How do I fix CVE-2026-126187?
Upgrade react-server-dom-webpack, react-server-dom-parcel or react-server-dom-turbopack to 19.0.9, 19.1.10, 19.2.9 or 19.3.1, matching the line you already track, then redeploy so the new build goes live. Next.js apps should also move to 16.4.1 or later (16.4.5 and 15.5.29 were the current security releases on 11 November). There is no workaround — React recommends updating immediately.

Is CVE-2026-126187 being exploited?
No confirmed in-the-wild exploitation has been reported, and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalog as of 13 November 2026. Public proof-of-concept code has existed on GitHub since 11 November, so the window between disclosure and possible exploitation is open — which is why patching the affected configuration promptly matters even without confirmed attacks.

Takeaway

CVE-2026-126187 is a genuinely critical React flaw with a public exploit — but only for a narrow server-side configuration, and the fix has been available for a month. Check your lockfile, patch the affected configuration today, and let the 75% still on old versions be someone else's problem.

Check your lockfile today, and read our Apache HTTP/2 critical RCE flaw patched in 2.4.71 — another server-side patch from the same week that deserves the same treatment.

Sources

Unauthenticated Remote Code Execution in React Server Components — React GitHub Security Advisory GHSA-xqc2-xf4c-x3h3 (primary source)
NVD — CVE-2026-126187
Rapid7 Vulnerability Database — CVE-2026-126187
Brandefense — CVE-2026-126187: React Server Components RCE (CVSS 9.5), Fix (updated 11 Nov 2026)
cve.now — CVE-2026-126187: React remote code execution in RSC (npm download share, 13 Nov 2026)