React has published a critical security advisory warning that applications using React Server Components can be vulnerable to remote code execution triggered by nothing more than a specially crafted server response — no login, no user interaction, and no special privileges required. The advisory, tracked as GHSA-xqc2-xf4c-x3h3, carries a CVSS v4 score of 9.5, and the React team is urging affected projects to update immediately.

Which Packages Are Affected

The vulnerability touches three packages that support React Server Components across different build tooling: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. These packages are what let React Server Components function correctly depending on whether a project is built with Webpack, Parcel, or Turbopack.

Affected version ranges span 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, consistently across all three packages. The fixed releases are 19.0.9, 19.1.10, 19.2.9, and 19.3.1. Teams running any of the affected ranges should prioritize updating to the corresponding patched version.

How the Flaw Works — and Its Limits

According to React’s own advisory, exploitation requires a fairly specific and uncommon condition: a server response that includes multiple typed arrays — structures used to hold numeric data in defined binary formats — combined with a value that an attacker can control. The advisory is careful to note that simply using React, or even using React Server Components generally, doesn’t automatically make an application vulnerable; the exploitable pattern is described as an “extremely rare” response shape.

That said, React has not published a full technical breakdown or working exploit code, so the precise mechanics of how an attacker would engineer that response pattern in a production application remain undisclosed publicly. What is disclosed is the severity rating: the advisory rates the potential impact on data confidentiality, integrity, and system availability as high, and critically, notes that no account privileges or user interaction are needed to trigger it.

Don’t Confuse This With React2Shell

This advisory is separate from the earlier “React2Shell” exploitation activity tracked as CVE-2025-55182, which was previously covered in cybersecurity reporting. The October 2026 advisory discussed here carries no public CVE identifier at the time of writing. Evidence of real-world attacks against the older React2Shell flaw does not mean this newer vulnerability is being actively exploited — those are two distinct issues, and conflating them risks either overstating or understating the current risk.

What Affected Teams Should Do

• Identify whether your application uses React Server Components with any of the three affected packages, and check your exact version against the affected ranges.
• Upgrade to the patched releases (19.0.9, 19.1.10, 19.2.9, or 19.3.1) as soon as possible — this is a pre-authentication, no-interaction-required vulnerability with a near-maximum severity score.
• Review deployment logs for unusual response patterns involving multiple typed arrays if you suspect your application may already have been probed, though React has not published detection guidance specific to this issue.
• Treat the 9.5 CVSS score as the operative signal for urgency, even though the exploitation path requires an uncommon application pattern — “uncommon” is not the same as “absent” at scale.

Given the severity score and the fact that no authentication or user interaction is needed, organizations running React Server Components in production should treat this patch cycle as a priority rather than routine maintenance.

Why React Server Components Carry Unique Risk

React Server Components represent a meaningful architectural shift from traditional client-rendered React applications: logic that used to run entirely in the browser now executes on the server, and the protocol connecting server and client has to serialize and deserialize complex data structures — including, in this case, typed arrays — across that boundary. That serialization layer is exactly the kind of surface where memory-safety and type-confusion style bugs tend to surface, because it has to make assumptions about the shape and trustworthiness of data crossing between two different execution contexts.

This is also why the advisory spans three separate packages rather than a single one. Because react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack all implement the same underlying server/client communication protocol for their respective bundlers, a flaw in that shared protocol logic tends to show up consistently across all three, which is exactly what happened here — identical affected version ranges and identical fixes across all three packages.

The Patch Management Challenge

One complicating factor for defenders is that React Server Components adoption is still relatively recent compared to traditional client-side React, which means not every team tracking general React vulnerabilities is necessarily monitoring server-components-specific advisories closely. Organizations that adopted React Server Components early — often for performance reasons, to reduce client-side JavaScript payloads — may not have the same vulnerability-scanning coverage in place that they do for more mature, longer-established parts of their stack.

Framework maintainers building on top of React Server Components, such as Next.js and other meta-frameworks, will also need to confirm whether their own released versions pull in the patched underlying packages, since many applications depend on these packages transitively rather than directly. Security teams should check not just their direct dependencies but also whether their framework of choice has issued its own guidance or a point release pinning the fixed versions.