The PoC Is Public. 73% of Downloads Are Still Exposed.

React has disclosed a critical flaw in its Server Components — and the proof-of-concept code that exploits it is already public on GitHub. The vulnerability, CVE-2026-126187, scores 9.5 out of 10 and allows an unauthenticated attacker to run code on the server. The fix is a version upgrade. The problem is that nearly three-quarters of downloads are still on affected versions.

The flaw lives in the Flight protocol — the mechanism React Server Components use to send data from server to client. It is a deserialization weakness, tracked as CWE-502: when a response transports multiple typed arrays and includes an attacker-controlled value, a crafted payload can trick the server into executing code it was never meant to run. No login is needed. No special permissions. Just a request.

What is affected, and what is not

The vulnerability affects three packages — react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack — in versions 19.0.0 through 19.3.0. Fixes are already out: 19.0.9, 19.1.10, 19.2.9, and 19.3.1, one patched release for each affected line. React’s advisory is blunt about the remedy: “We recommend updating immediately.”

The scope is narrower than the headline suggests, and that matters. Your app is affected only if it uses a server and a framework, bundler, or bundler plugin that supports React Server Components. A React app with no server is not affected. An app that does not use Server Components is not affected. But the frameworks that do use them are the ones that matter most: Next.js 16, with its Cache Components feature, is the headline case, and React Server Components are exactly the kind of feature that quietly spreads through an organization as teams adopt the newest framework defaults.

That quiet spread is visible in the download numbers. About 73 percent of react-server-dom-webpack downloads are still on affected versions. The patched releases exist; most of the ecosystem has not picked them up yet. The gap between a fix being published and a fix being installed is the window attackers live in — and this time the window comes with a public map.

How the React flaw works: a crafted payload with typed arrays in the Flight protocol triggers a deserialization weakness, and code runs on the server with no login.
Crafted payload in. Code runs on the server.

Why the clock is running

There is no confirmed exploitation yet, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog. That is the good news, and it is worth stating plainly. The bad news is what usually follows a public proof of concept: the barrier to exploitation drops from “understand the flaw” to “download the code and run it.” The PoC repository is public. The affected versions are the majority of the ecosystem. The fix is a patch release away.

This is the same pattern this blog has covered before. When the OpenSSH flaw known as SSHole was disclosed, the first exploitation attempt hit a honeypot within nine hours — and confirmed break-ins followed within days. When the Linux kernel TCP flaw scored 9.8, the proof of concept took 48 minutes to leak kernel memory and five minutes to get root. Public proof of concept is not the same as exploitation in the wild. But it is the step that comes right before it.

The other reason to move quickly is how small the fix is. This is not a rewrite or a migration. It is a patch release in the same minor line you are already running — 19.0.9 if you are on 19.0, 19.1.10 if you are on 19.1, 19.2.9 for 19.2, 19.3.1 for 19.3. The cost of upgrading is an afternoon of testing. The cost of waiting is a server that runs whatever a stranger sends it.

Four things to do today

First, upgrade. Move to the patched release for your line — 19.0.9, 19.1.10, 19.2.9, or 19.3.1 — and do it on every service that uses React Server Components, not just the one you remember.

Second, check the lockfile. Search your package-lock or yarn.lock for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, and find every place the affected versions are pinned — including the services and side projects nobody has touched in months.

Third, confirm whether Server Components are actually in use. If your app has no server, or no framework that supports Server Components, you are not affected — but confirm that instead of assuming it. A dependency pulled in by a framework default counts.

Fourth, watch for scanning. A public PoC means automated probes follow quickly. Monitor for unusual requests carrying crafted payloads against your Server Component endpoints, and alert on deserialization errors or unexpected server-side process behavior.

What to do now: upgrade to a patched release, check the lockfile for affected packages, confirm whether Server Components are in use, and watch for scanning.
Upgrade. Check the lockfile. Watch the endpoints.

Patch releases exist for a reason

React did the hard part already: it found the flaw, built the fix, and shipped it on four separate lines so nobody has to upgrade across a major version to be safe. The proof of concept did the rest — it told the world exactly where the hole is. What remains is the part only the people running the servers can do: apply the patch before the PoC becomes a break-in. Seventy-three percent of downloads are still exposed. Make yours one of the ones that is not.

Comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.