React2Shell And Next.js RCE: How A Flight Protocol Flaw Put Modern Web Apps At Risk

A critical remote code execution vulnerability in React Server Components and the Next.js framework has sent a shockwave through the modern web ecosystem. At the heart of the issue is a flaw in how the React Flight protocol deserializes data sent to server endpoints, giving attackers a path to execute code on application servers without authentication. For organizations that have embraced React and Next.js for high performance, cloud native applications, this incident is a stark reminder that convenience and speed can mask deep architectural risk.

How React And Next.js Became Exposed

React Server Components (RSC) were introduced to bridge the gap between client side interactivity and server side rendering. Instead of sending fully rendered HTML or raw JSON, the React Flight protocol ships a structured stream that tells the client how to reconstruct the component tree. Next.js, which has become the dominant server framework in the React ecosystem, adopted this approach through its App Router and associated tooling.

The current vulnerability arises from how these Flight payloads are decoded on the server. In vulnerable versions, the server side deserialization logic treats incoming data as implicitly trustworthy and reconstructs objects and execution paths without sufficient validation. An attacker who understands the Flight format can craft a malicious payload that causes the server to instantiate unexpected objects, pollute internal state and ultimately reach code paths that execute arbitrary commands.

Crucially, exploitation happens before any user level authentication takes place. A public facing endpoint that supports React Server Components can be probed directly from the internet, turning what seems like a developer convenience feature into an unauthenticated entry point for full server compromise.

Who Is Affected

The impact is broad because the vulnerability does not require a bespoke configuration or unusual coding pattern. In many cases, a freshly generated project created with standard tooling is exposed as soon as it is deployed.

At highest risk are:

• React applications that use React Server Components and rely on the affected versions of the react-server-dom libraries.
• Next.js applications using the App Router in the impacted version ranges, particularly those that expose server actions or other RSC based endpoints to the public internet.
• Other frameworks and tools that embed the React Server Components Flight implementation, such as routing libraries or meta frameworks that integrate React 19 features.

Cloud native deployment patterns amplify the problem. Organizations often run large fleets of containerized React and Next.js services in Kubernetes clusters, behind load balancers and API gateways. A single vulnerable base image or shared framework layer can result in hundreds or thousands of identical, exploitable instances across production, staging and development environments.

What Remote Code Execution Looks Like In Practice

In a real world attack, an adversary would scan for internet facing HTTP endpoints that respond in ways consistent with React Server Components or Next.js App Router behavior. Once a candidate target is identified, the attacker sends specially crafted Flight protocol payloads designed to push the server into unsafe code paths.

Successful exploitation gives the attacker the ability to run arbitrary code with the privileges of the application process. In practical terms, that can allow an attacker to:

• Drop web shells or backdoors on the host.
• Exfiltrate environment variables and configuration secrets such as database passwords, cloud keys and API tokens.
• Move laterally to connected databases, message queues and microservices.
• Deploy ransomware, cryptomining tools or persistence mechanisms in the surrounding infrastructure.

Because the attack vector is the framework itself, not a specific business feature, the usual front end code reviews and QA processes are unlikely to spot the risk. Even minimal proof of concept payloads can have serious consequences if they reach back end components with broad access to critical data stores.

Why This Vulnerability Is So Serious

Several factors combine to push this issue into the highest severity category.

1. Unauthenticated access: The vulnerable deserialization occurs before authentication, so public routes are enough to trigger it.
2. Default exposure: Many applications inherit support for React Server Components through framework defaults, even if developers are not consciously using server actions or advanced patterns.
3. High adoption: React is one of the most widely used JavaScript frameworks, and Next.js is the de facto choice for production React deployments. That scale translates directly into a massive potential attack surface.
4. Server side blast radius: Remote code execution on the server quickly turns into full application compromise, with impact on data, identity, availability and supply chain trust.

The combination of unauthenticated access, default exposure and server side execution power is why security teams are treating this incident as a top tier priority alongside previous landmark vulnerabilities in widely used platforms.

How Vendors Responded

Once the underlying flaw in the Flight protocol was confirmed, the React and Next.js teams issued coordinated security advisories, shipped patched versions and urged users to upgrade immediately. The fixed releases harden the deserialization logic, introduce stricter validation of incoming payloads and close off the execution paths that allowed arbitrary code to run.

At the same time, cloud providers, content delivery networks and web application firewall vendors released detection signatures and managed rules aimed at blocking known exploit attempts. These controls focus on the shape and semantics of malicious Flight payloads rather than on specific application paths, which allows them to provide a degree of protection even for unpatched services.

Despite these efforts, framework teams and vendors have been clear that network based mitigations are not a substitute for patching. As attackers refine their payloads and learn how different stacks implement the protocol, generic filters will become easier to bypass.

Immediate Actions For Security And DevOps Teams

Organizations that use React and Next.js should treat this as an emergency patch event. The following steps provide a structured way to respond.

1. Inventory And Scope

Start by building a complete inventory of services that might be vulnerable. This should include:

• All React applications that rely on React 19 or React Server Components.
• All Next.js deployments that use the App Router or RSC features.
• Shared libraries, starter kits and internal frameworks that bundle React 19 components.

Where possible, enrich this inventory with version data from package manifests, lock files and container images. Security tools that integrate with software composition analysis or cloud workload scanning can accelerate this step.

2. Patch, Upgrade Or Temporarily Disable RSC Features

Once affected services have been identified, the priority is to move them to fixed framework versions. In practice this means:

• Upgrading the React Server Components packages to patched releases.
• Updating Next.js projects to the latest stable version in their branch that carries the fix.
• Rebuilding container images and redeploying workloads to ensure that patched versions are actually running in production.

In environments where immediate upgrades are not feasible, development and platform teams should consider temporarily disabling features that rely on React Server Components or removing public exposure for endpoints that use the Flight protocol, for example by placing them behind internal authentication or VPN access.

3. Enhance Detection And Logging

Remote code execution attempts against RSC endpoints will often leave distinctive traces in logs and telemetry. Security teams should:

• Enable detailed logging for HTTP traffic hitting Next.js and React server endpoints, including request bodies where privacy and regulation allow it.
• Look for unusual or malformed Flight payloads, especially those that include unexpected keys, nested structures or binary segments that do not match legitimate application behavior.
• Correlate application logs with host and container telemetry to identify suspicious process launches, file modifications or network connections that occur shortly after inbound RSC requests.

Where available, integrate detection content from security vendors that specifically target the React and Next.js Flight protocol vulnerabilities, and push alerts into existing incident response workflows.

Longer Term Lessons For Framework And Platform Security

Beyond the immediate patching cycle, this incident raises deeper questions about how modern web frameworks handle code that crosses the boundary between client and server.

React Server Components promise a more efficient model for rendering complex interfaces, but they also increase the complexity of serialization, transport and execution layers. Each additional layer is a potential location for logic mistakes that are hard to reason about and even harder to test exhaustively in real world deployments.

For framework authors, the lesson is that protocol design and deserialization logic must be treated as security critical code from the outset, with formal threat modeling and fuzz testing on par with the attention given to public APIs. For platform teams, the message is that adopting cutting edge framework features should always be accompanied by clear plans for patch management, observability and emergency response.

What Organizations Should Do Next

In the coming weeks, exploit payloads for the React and Next.js Flight protocol flaws are likely to become more polished and widespread. Opportunistic scanning for vulnerable endpoints will follow, targeting organizations that lag behind on upgrades.

To stay ahead of that curve, organizations should:

• Complete patching across all identified React and Next.js services.
• Introduce routine dependency hygiene checks into CI pipelines, with automated alerts for future security advisories affecting core frameworks.
• Review architectural patterns that expose server side frameworks directly to the public internet and consider layered defenses such as API gateways and security proxies.
• Invest in security training for front end and full stack development teams so that features like React Server Components are adopted with a clear understanding of their risk profile.

React and Next.js will remain central pillars of the modern web, and their ecosystems will continue to evolve. This incident does not change that trajectory, but it does highlight the importance of building security into every layer of that stack. Organizations that respond quickly and use this moment to strengthen their application security posture will not only weather the current storm but also be better prepared for the next framework level vulnerability that emerges.