React2Shell exploitation shows how framework RCE breaks server trust

At a glance

What this is: This is Aqua Security’s analysis of React2Shell, a critical React Server Components flaw that turns a single malicious request into unauthenticated server-side code execution.

Why it matters: It matters because framework-layer trust failures can expose application servers, secrets, and downstream cloud assets before teams have a chance to compensate at the network or runtime layer.

Context

React Server Components shift part of the rendering and data-handling trust boundary into server-side code paths that must safely process client-originated metadata. When that boundary is weak, attackers can convert normal application traffic into code execution without first stealing an account.

Aqua Security says CVE-2025-55182, also known as React2Shell, affects React 19 and frameworks that rely on RSC, especially Next.js. The issue is not just a vulnerable package version, but a server-side trust model that assumed deserialised input would remain well-formed and harmless.

Key questions

Q: What breaks when unsafe deserialization exists in a React Server Components implementation?

A: Unsafe deserialization lets attacker-controlled payloads influence server-side processing in ways the framework was not meant to allow. In practice, that can turn a malformed request into code execution on the server. The control failure is especially dangerous because it can be triggered remotely and without authentication, so trusted request assumptions no longer hold.

Q: Why does a framework RCE create broader risk than a single application bug?

A: A framework RCE affects every application path that depends on the shared runtime, including rendering, routing, and data access. That means one flaw can expose secrets, tokens, databases, and persistence mechanisms across many services, so the blast radius is far larger than a single code path.

Q: What are the signs that server-side framework trust is failing in practice?

A: Look for vulnerable package versions in deployed artefacts, unexpected command execution from web processes, and access to environment variables or file paths that the application should never need. Those signals usually indicate that the runtime boundary is already being used as an attack path.

Q: What should teams do when a public RCE in a framework is already being exploited?

A: Treat the issue as a potential incident, not a simple patch task. Patch affected systems, isolate exposed applications where needed, review authentication and secret exposure around those workloads, and search for compromise indicators before declaring recovery. If internet-facing systems were vulnerable, assume the attacker may already have attempted or achieved execution.

Technical breakdown

How insecure deserialization becomes remote code execution in RSC

React Server Components expect structured metadata from the client, but the flaw accepts attacker-controlled input without sufficient validation or type safety. That matters because deserialisation is not just parsing, it is reconstructing objects and execution state. If the parser can be influenced to instantiate unexpected types or feed unsafe data into internal control flow, the application can cross from data handling into code execution. In this case, the vulnerable path sits inside the server runtime itself, so the attacker does not need a second-stage foothold to reach the execution boundary.

Practical implication: Treat any server-side deserialisation path that consumes client-controlled objects as a code-execution boundary.

Why Next.js magnifies the blast radius of a framework RCE

Next.js integrates React Server Components deeply into server-side rendering, data fetching APIs, route handlers, and related core features. That tight coupling means a flaw in the RSC layer can propagate into multiple request-processing paths rather than staying isolated in one component. Once the attacker reaches that shared runtime, the compromise is not limited to a single route or page. It can extend to environment variables, file system access, database connectivity, and persistence mechanisms already available to the process.

Practical implication: Map framework dependencies to shared runtime paths so one vulnerable component does not become a full-application failure domain.

Why active exploitation changes the response timeline

Aqua Security describes exploitation by China-nexus groups, mass-scanning botnets, and opportunistic attackers soon after disclosure. That combination usually means the vulnerability has moved from theoretical risk to automated exploitation at internet scale. In practice, the most dangerous stage is often not the initial proof of concept but the rapid conversion of a framework flaw into repeatable attack tooling. Once that happens, exposure becomes a function of reachable attack surface and patch delay, not attacker sophistication.

Practical implication: Prioritise internet-facing RSC and Next.js assets for emergency validation, patching, and compensating runtime control.

Threat narrative

Attacker objective: The attacker aims to gain unauthenticated control of the server, then use that foothold to steal secrets, persist, and expand access.

1. Entry occurs through a single unauthenticated HTTP request sent to an internet-facing application built on vulnerable React Server Components.
2. The attacker abuses insecure deserialisation to inject malicious object types into the RSC execution pipeline and trigger server-side code execution.
3. After execution, the attacker can drop shells, harvest environment variables, manipulate files, and establish persistence on the compromised server.
4. The final objective is full application and server takeover that can be used for credential theft, lateral movement, and follow-on compromise.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

React2Shell is a server-trust failure, not just an application bug: The key problem is that server-side framework code accepted client-originated structure as trustworthy enough to reconstruct execution state. That assumption breaks the moment the input can shape object types or control flow inside the runtime. The implication is that deserialisation in modern web frameworks has to be treated as part of the identity and privilege boundary, not as a routine parsing layer.

Framework RCE collapses the difference between application compromise and identity compromise: Once the runtime is executing attacker code, secrets, tokens, and service credentials stored in the process become reachable without any separate login event. That turns a code defect into an identity exposure event because the attacker inherits whatever the server can already access. Practitioners need to think in terms of server trust radius, not just patch status.

Identity blast radius is the right concept for RSC-era compromise: In frameworks that combine rendering, routing, and data access in one server runtime, a single exploit can expose both application logic and the credentials that support it. That creates a larger blast radius than many teams assume when they treat framework patches as routine maintenance. The practical takeaway is to map which secrets and downstream systems are reachable from each server process before exploitation does it for you.

Active exploitation changes React2Shell from a code-quality issue into a governance issue: The speed of weaponisation means patch SLAs, exposure inventory, and runtime containment now matter at the same level as vulnerability disclosure. A framework flaw that is already being scanned in the wild should be governed as an access-risk event, because the attacker is effectively one request away from inheriting the server’s privileges. Teams should treat framework trust as a managed control surface, not a developer assumption.

Server-side framework trust has become a supply-chain dependency for identity security: Applications increasingly inherit security properties from the frameworks they embed, and one weak deserialiser can undermine downstream controls that were otherwise well designed. That means patching alone is necessary but insufficient if exposed servers continue to trust the same execution path. Practitioners should view framework runtime integrity as part of NHI and secrets governance, especially where server processes can reach production credentials.

What this signals

React2Shell shows that framework trust is now part of identity and access governance because the server process often holds the keys attackers want next. If a web runtime can reach production secrets, the compromise is no longer only about application code.

Identity blast radius: teams need to map which credentials, tokens, and downstream systems are reachable from each server runtime before an RCE makes that mapping for them. Runtime containment matters because patching alone does not erase the privileges already exposed.

For practitioners

• Inventory all React RSC and Next.js exposure Identify every internet-facing application that uses React Server Components or Next.js, including internally owned apps and externally hosted workloads. Prioritise systems that expose server-side rendering, route handlers, or data fetching APIs because those paths inherit the vulnerable runtime.
• Rescan dependencies and transitive packages Check current and transitive package versions against the affected React and Next.js release ranges, then verify that patched releases are present in deployed artefacts, not just source manifests.
• Reduce the secrets reachable from web runtimes Remove unnecessary environment variables, tokens, and service credentials from application processes that handle framework-level requests, and separate high-value credentials from the runtime where possible.
• Apply runtime controls to suspicious execution paths Use runtime policy, workload detection, and container guardrails to block anomalous command execution, shell spawning, and non-compliant code paths while patching is in progress.
• Reclassify framework patches as exposure events Update vulnerability triage so critical framework RCEs trigger inventory validation, secrets review, and compensating control checks rather than waiting for a normal maintenance cycle.

Key takeaways

• React2Shell is dangerous because a server-side deserialisation flaw can turn trusted framework traffic into arbitrary code execution.
• The impact extends beyond the vulnerable package because Next.js and similar stacks can expose secrets, files, and downstream services from the same runtime.
• Teams should treat this as an exposure problem as well as a patching problem, with runtime controls and secrets reduction used to shrink the blast radius.

Key terms

• React Server Components: A server-side rendering model that moves part of the React component tree to the server and streams rendered output to the client. Because it runs inside the application trust boundary, flaws in this layer can expose code, secrets, or processing logic rather than only visual behaviour.
• Insecure deserialisation: Insecure deserialisation is a flaw where software rebuilds objects from incoming data without tightly controlling what can be instantiated. In platform software, it can turn a management interface into a code execution path when hostile payloads are accepted from a trusted channel.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime containment: A control approach that limits harmful behaviour while an AI agent is still active rather than waiting for post-incident review. It depends on signals such as anomalous tool use, privilege expansion, or unusual data access so security teams can intervene before blast radius grows.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.