React Server Components RCE: Patch Now

React published a critical security advisory on October 14, 2026: GHSA-xqc2-xf4c-x3h3 describes unauthenticated remote code execution in React Server Components. The CVSS v4 score is 9.5. If your application runs React on the server through an RSC-capable framework, bundler, or plugin, treat the patch as urgent. If it ships only client-side React, the advisory says you are not affected.

The flaw is in the server-dom packages, not in every React renderer. The affected code is the transport layer that serializes RSC responses between the server and the client. That narrows the population of exposed applications, but it does not make the patch optional for the ones that qualify.

The React RSC short version

• Advisory: GHSA-xqc2-xf4c-x3h3, published October 14, 2026.
• Severity: Critical, CVSS v4 9.5.
• Impact: Remote code execution without authentication, privileges, or user interaction.
• Affected packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack.
• Fixed versions: 19.0.9, 19.1.10, 19.2.9, and 19.3.1.
• CVE: No known CVE in the advisory.
• Exploitation status: The public advisory does not claim active exploitation.

Which React RSC setups are affected

The advisory lists four affected release lines: 19.0.0 through 19.0.8, 19.1.0 through 19.1.9, 19.2.0 through 19.2.8, and 19.3.0. The same ranges apply to all three server-dom packages.

There is a small typo in the advisory text: the patch paragraph says “19.0.09,” while the package tables say “19.0.9.” The package tables and the published release line are the useful reference. Pin 19.0.9, not a two-digit patch version.

The React RSC trigger is rare; the impact is severe

The advisory is unusually specific about the condition: exploitation requires responses that transport multiple typed arrays and a value controlled by the attacker. Typed arrays are the binary buffers used to carry numeric data efficiently. A response that carries several of them, together with attacker-controlled data, is the pattern the advisory calls out.

That is why the CVSS vector is not a simple “every React app is on fire” score:

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N

Read the fields: network attack vector, low attack complexity, attack requirements present, no privileges required, no user interaction, and high confidentiality, integrity, and availability impact on the vulnerable system. The “attack requirements present” field is the rare multi-typed-array response pattern. The “no privileges” and “no user interaction” fields are why the score stays at 9.5 despite that condition.

The public advisory does not publish a complete technical breakdown or exploit instructions. It also does not establish how common the required response pattern is in production. That limits exposure assessment; patch anyway. If your application matches the affected architecture, the safe assumption is that it can reach the vulnerable code path.

Which React apps are not affected

The advisory is explicit about the negative cases. If your React code never runs on a server, the advisory excludes your application. It is also not affected if it does not use a framework, bundler, or bundler plugin that supports React Server Components.

That means a client-only React app, a static site with React islands and no RSC transport, and a plain React component library are outside this advisory. The check is about the server-side RSC stack, not about whether react appears in package.json.

How to check your React RSC dependency tree

Do not rely on the top-level React version. The vulnerable packages are separate server-dom packages, and they are often pulled in by a framework rather than installed directly.

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

# pnpm
pnpm why react-server-dom-webpack
pnpm why react-server-dom-parcel
pnpm why react-server-dom-turbopack

# yarn
yarn why react-server-dom-webpack
yarn why react-server-dom-parcel
yarn why react-server-dom-turbopack

Also inspect the lockfile and the framework’s dependency tree. A package can be several levels below the application, especially when a meta-framework or bundler plugin owns the RSC integration. If the lockfile shows one of the affected ranges, the application needs a patched build even if the top-level react version looks current.

Run npm audit as a second signal, but do not treat a clean audit as proof. The advisory may not be present in every audit database mirror yet, and a transitive package can be hidden from a shallow review. The explicit npm ls check is the direct answer.

How to patch React Server Components

1. Inventory the package and the owner. Identify which of the three server-dom packages is present, which version, and whether it is direct or brought in by a framework or bundler plugin.
2. Upgrade to the matching fixed line. The fixed versions are 19.0.9, 19.1.10, 19.2.9, and 19.3.1. Use the line that matches the rest of your React stack rather than mixing release trains.
3. If a framework pins the package, upgrade the framework. The React advisory does not list framework-specific patched versions. Follow the framework’s own security notice rather than forcing an override that its maintainers have not tested.
4. Commit the lockfile. A patched package.json with an old lockfile can still install the vulnerable tree.
5. Rebuild and redeploy. RSC code is often bundled at build time. Restarting the process without rebuilding may leave the old server bundle in place.
6. Verify the running artifact. Run npm ls again in the deployed environment, not only in the developer workspace. Confirm the resolved version, not just the range in the manifest.

A direct upgrade for an application that owns the dependency looks like this:

# Example: choose the fixed line that matches your stack.
npm install [email protected]
# or 19.0.9, 19.1.10, or 19.2.9

npm ls react-server-dom-webpack
npm run build
# redeploy the built artifact

Repeat with react-server-dom-parcel or react-server-dom-turbopack if that is the package your build uses. Do not install all three just to satisfy a checklist; patch the one that is actually in the tree.

How this React RSC flaw differs from React2Shell

Cyber Security News distinguishes this advisory from the earlier React2Shell issue, tracked as CVE-2025-55182. The two are separate. Evidence that an older detection rule or mitigation worked against React2Shell does not establish coverage for GHSA-xqc2-xf4c-x3h3.

The new advisory also has no known CVE and no public claim of active exploitation. Report it accurately and treat it as a critical patch. A critical unauthenticated RCE in a server-side rendering path deserves a patch window even when the trigger is narrow and the exploit is not public.

React RSC patch checklist

• Search for all three server-dom packages in the lockfile and the runtime tree.
• Compare every resolved version against the four affected ranges.
• Upgrade to 19.0.9, 19.1.10, 19.2.9, or 19.3.1.
• If a framework owns the dependency, update the framework and read its advisory.
• Rebuild the RSC bundle, redeploy, and re-check the resolved version in production.
• Keep the lockfile change with the code change; do not hot-patch only the deployed node_modules.
• Record the advisory ID and the fixed version in the change ticket so the next audit can trace the decision.

The public advisory recommends immediate updates. It does not publish a configuration workaround, and it does not give exploit details. For an affected application, the practical answer is the same one React gives: upgrade the server-dom package, rebuild, and verify the artifact that is actually running.

Sources and references

• React security advisory GHSA-xqc2-xf4c-x3h3
• Cyber Security News: Critical React Server Components Flaw Lets Hackers Execute Code Remotely Without Authentication