React2Shell shows how deserialization flaws become instant RCE

At a glance

What this is: React2Shell is a critical React Server Components vulnerability that turns unsafe deserialization in the Flight protocol into unauthenticated remote code execution.

Why it matters: It matters because teams running modern JavaScript frameworks need to treat framework internals as part of their attack surface, especially when exposed services and automation depend on them.

By the numbers:

• React2Shell was categorized as Critical with a CVSS score of 10.
• All current versions of React Server Components, including React 19.2.0, are vulnerable.

👉 Read StackHawk's analysis of the React2Shell critical RCE vulnerability

Context

React2Shell is a framework-level remote code execution issue, which means the risk sits in how server components trust and process incoming data rather than in application business logic. For teams shipping React Server Components or Next.js App Router applications, the primary issue is not just whether a package is outdated, but whether the server can be reached and coerced into executing attacker-controlled payloads.

The identity angle is indirect but real: code execution in the application tier often becomes the starting point for credential theft, token harvesting, or abuse of service accounts and automation secrets. That makes React2Shell relevant to IAM and NHI programmes as well as application security teams, because a framework flaw can quickly become an identity compromise path.

Key questions

Q: What breaks when React Server Components are exposed to crafted Flight payloads?

A: The server can deserialize attacker-controlled data as if it were legitimate framework state, which can redirect execution flow and trigger remote code execution. In practice, the break is not just a parsing error. It is a collapse of the trust boundary between client-supplied payloads and internal server logic, which can lead to file access, process spawning, or full compromise.

Q: Why do framework RCE flaws quickly become identity risks?

A: Because once an attacker can execute code on an application server, the fastest route to persistence is often through secrets, tokens, and service account credentials. Those identities can unlock cloud resources, APIs, or internal systems. Application security and identity governance therefore need to treat server compromise as a potential credential compromise event.

Q: How do security teams know whether a vulnerable React package is actually exploitable?

A: They need runtime validation, not just dependency inventory. A package report shows presence, but exploitability depends on whether the vulnerable endpoint is reachable, whether payload processing is exposed, and whether compensating controls block exploitation. Active testing, log review, and patch verification together provide the operational answer.

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

Unsafe deserialization in the Flight protocol

React Server Components use the Flight protocol to move component data between client and server. In vulnerable builds, the server trusts incoming payload structure too much and deserializes user-supplied data before fully validating provenance. That matters because deserialization is not just parsing. It is a trust boundary where attacker-controlled object shapes can influence server behaviour if the runtime assumes the payload came from legitimate framework code. In React2Shell, that unsafe trust is what makes a crafted payload potentially executable.

Practical implication: validate exposure of every RSC endpoint and treat payload parsing as a high-risk trust boundary.

Promise resolution abuse and server-side state manipulation

The exploit chain described in the article uses a fake object that mimics an internal Chunk, then abuses Promise resolution through a custom then method. When React attempts to resolve the object, the attacker gains access to internal parsing state, including the _response object, and can manipulate later server function calls. This is a classic deserialization abuse pattern. The attacker does not need credentials if the endpoint is reachable, because the bug lives in how the runtime interprets crafted data, not in authorization logic.

Practical implication: scan for reachable endpoints that accept Flight payloads and verify whether server-side deserialization is actually exploitable.

Why patching alone is not enough

The article makes a useful distinction between having a vulnerable dependency and having a reachable exploit path. A package version check tells you exposure in the tree, but not whether the deployed application can be triggered in practice. Runtime testing, WAF rules, and log review give evidence about exploitability and compromise indicators. That difference matters because many organisations overestimate safety when a patch is available but have not yet confirmed whether the vulnerable path is exposed in production.

Practical implication: pair dependency patching with exploit validation, log review, and containment checks before declaring the issue closed.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution on the application server and the ability to pivot into data theft or broader compromise.

1. Entry occurs when an attacker sends a crafted Flight payload to an exposed React Server Components endpoint.
2. Credential access is not required because the flaw allows unauthenticated interaction with the vulnerable deserialization path.
3. Escalation happens when Promise resolution and internal state manipulation redirect execution toward attacker-chosen server functions.
4. Impact is remote code execution that can lead to file access, process spawning, and full server compromise.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

React2Shell is a reminder that framework trust boundaries are identity-adjacent attack surfaces. Once server-side code execution is possible, the next question is rarely just application integrity. Attackers commonly move toward secrets, tokens, and service credentials because those assets unlock persistence and lateral movement. For IAM and NHI teams, that means a framework flaw can become a control failure for secrets governance and service account containment. The practitioner conclusion is simple: runtime application risk now belongs in identity risk discussions.

Exploitability matters more than package awareness. The article separates an outdated dependency from a reachable, weaponisable path, and that distinction is operationally important. Many programmes stop at inventory and patch status, but exploitable exposure depends on whether the vulnerable endpoint is internet-facing, how requests are routed, and whether compensating controls exist. This is where CIS Controls and NIST CSF thinking converges with application security. The practitioner conclusion is to measure reachability, not just version drift.

React2Shell exposes a server-trust collapse in deserialization-heavy architectures. The named concept here is deserialization trust collapse: a condition where runtime code treats attacker-shaped data as framework-internal state. Once that happens, one bad payload can bypass normal application intent and influence execution flow directly. That pattern is especially dangerous in modern JavaScript stacks that mix client and server responsibilities. The practitioner conclusion is to treat deserialization paths as privileged execution surfaces.

Active exploitation changes prioritisation, not just patch urgency. When threat groups move within hours, response teams should assume scanning, exploitation attempts, and follow-on compromise may already exist. That affects logging, containment, and incident review priorities. For identity programmes, this is the point where service account exposure, secret rotation, and token revocation become part of the response plan. The practitioner conclusion is to align patching with compromise checks and identity containment.

Runtime security testing is becoming a governance control, not only a developer control. A scanner that confirms actual exploitability gives risk teams a different signal from a dependency report. That matters for boards, audit, and security leadership because it answers whether a vulnerable framework is merely present or actively reachable. In governance terms, this is evidence for risk-based remediation, not just backlog hygiene. The practitioner conclusion is to make exploit validation a standard gate for internet-facing application changes.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Forward look: Review the 52 NHI Breaches Report for the recurring failure patterns that follow application compromise and secret exposure.

What this signals

Deserialization trust collapse is becoming a practical programme issue, not an abstract code-quality issue. When a framework flaw can turn into server execution, the next governance question is whether secrets, tokens, and service accounts are isolated enough to survive a compromise. That is where application security, IAM, and NHI governance meet, and it is why runtime exposure evidence matters more than version checklists. Teams should link patch priority to credential containment and exposure blast radius, not just library age.

Internet-facing frameworks now behave like privileged execution infrastructure, which changes how organisations should plan monitoring and containment. A finding such as React2Shell should trigger cross-team playbooks that combine application patching, log hunting, and identity review for the affected workloads. Where relevant, align remediation reporting to the NIST Cybersecurity Framework 2.0 so detection, response, and recovery responsibilities are explicit.

For practitioners

• Patch exposed React and Next.js instances immediately Upgrade React Server Components and Next.js App Router deployments to the fixed versions listed in the security advisory, then verify all production and pre-production environments are on the same baseline.
• Map every reachable Flight endpoint Inventory applications that support React Server Components, identify which endpoints accept Flight payloads, and confirm whether they are internet-facing or exposed through shared ingress paths.
• Validate exploitability with runtime testing Run active checks against deployed applications to confirm whether the vulnerable path is reachable, then retest after patching to ensure the exploit no longer succeeds.
• Review logs for exploit indicators Search for headers such as next-action or rsc-action-id, request bodies containing $@ patterns, unusual process creation, and evidence of file access attempts like /etc/passwd reads.

Key takeaways

• React2Shell shows how a deserialization flaw in a popular framework can become unauthenticated remote code execution in exposed applications.
• The practical risk is broader than code execution alone, because server compromise often becomes a gateway to secrets, tokens, and service account abuse.
• Teams should pair patching with exploit validation, log review, and identity containment so they can prove the issue is closed rather than assume it is.

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.
• Flight protocol: The Flight protocol is the data transport React uses to move component information between client and server in React Server Components. It is security-sensitive because the server must parse structured input that can influence execution flow if validation is weak or assumptions about origin are wrong.
• Deserialization Trust Boundary: A deserialization trust boundary is the point where data stops being inert text and starts becoming an object the runtime can act on. In agentic systems, that boundary is high risk because replayed state may carry secrets, executable templates, or privileged metadata.
• Continuous exploitability validation: The practice of checking, on an ongoing basis, whether a discovered weakness can actually be used by an attacker in the current environment. It goes beyond scanning because it proves reachability and impact, which is essential when attack timelines are short and exposure can change quickly.

What's in the full article

StackHawk's full post covers the operational detail this post intentionally leaves for the source:

• Exact patch guidance for React and Next.js version families affected by CVE-2025-55182
• Command-line checks for identifying vulnerable react-server-dom-* dependencies in npm and yarn projects
• Network and host indicators that help confirm whether exploitation attempts already occurred
• StackHawk plugin details for runtime validation of exploitability after remediation

👉 StackHawk's full post covers the exploit chain, detection indicators, and remediation steps

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to real operational risk across modern security programmes.