React2Shell shows how deserialization flaws become instant RCE

At a glance

What this is: React2Shell is a critical React Server Components deserialization flaw that can turn exposed endpoints into unauthenticated remote code execution paths.

Why it matters: It matters because application teams can no longer treat dependency awareness as enough when exploitability depends on how a running app parses and processes untrusted payloads.

By the numbers:

• React2Shell was published as CVE-2025-55182 and rated Critical with a CVSS score of 10.

Context

React2Shell is a server-side deserialization flaw, which means the server trusts structured input too early and then uses that input to drive execution. In practice, that turns a parsing bug into code execution when the payload can influence internal state.

The governance problem is not only patch latency. Teams also need to know whether the vulnerable component is actually reachable in their deployed application, because framework transitivity and runtime behaviour can make exposure broader than a package manifest suggests. That is a software supply chain and runtime assurance problem, not just a version-control problem.

The article’s focus is typical of modern web application risk: a library issue becomes an operational security issue once it sits behind internet-facing endpoints and is processed in production.

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 do untrusted payloads in server-side frameworks create such a high risk?

A: Because the application is no longer just reading data. It is making control decisions from attacker-supplied structure, so a single parsing flaw can cross from input handling into code execution before normal business logic or authentication checks have a chance to intervene.

Q: How do security teams know if a framework exploit has already been attempted?

A: Look for unusual request patterns around the vulnerable protocol, repeated unauthenticated requests, malformed payloads, and errors that appear only on specific server routes. Then correlate those events with patch state and exposed internet-facing systems. Detection should focus on traffic to the framework path, not only on endpoint alerts after compromise.

Q: What should teams do first when a critical RCE affects an internet-facing web framework?

A: Contain the vulnerable service before assuming patching alone is enough. Isolate exposed workloads, block unnecessary egress, and rotate any secrets the runtime could access. If the application can reach internal APIs, metadata services, or secret stores, treat the host as a potential pivot point and verify whether the exploit was already used.

Technical breakdown

How Flight deserialization turns input into execution

React Server Components use the Flight protocol to send component data between client and server. In a vulnerable implementation, the server deserializes incoming payloads too trustingly and follows object behaviour embedded in attacker-controlled input. That means a crafted structure can influence promise resolution, internal parsing state, and later server-side function calls. The core failure is not that React parses data, but that it treats untrusted data as if it were already safe application state. Once parsing and execution become linked, the boundary that should separate input handling from code execution collapses.

Practical implication: review any component that deserializes remote data as a potential execution boundary, not just a parsing layer.

Why framework transitivity widens the attack surface

The affected surface is larger than teams often expect because application frameworks can inherit React Server Components logic indirectly. Next.js App Router deployments, for example, can inherit the vulnerable behaviour even when teams did not explicitly install the lowest-level package themselves. That creates a governance gap between declared dependencies and actual runtime exposure. The technical lesson is that exploitability depends on the deployed call path, not on whether a package appears directly in the project file. In modern JavaScript stacks, transitive framework behaviour is often the real attack surface.

Practical implication: inventory framework inheritance paths, not just direct dependencies, when assessing exposure.

Why unauthenticated RCE is a different severity class

This flaw requires no authentication and no user interaction, which is why exposed endpoints become immediate targets. Once an attacker can submit a malicious Flight payload, they can steer the server toward arbitrary JavaScript execution in the server process, then move from code execution to file access, process spawning, or broader compromise. That is a classic exploit chain with very little friction between discovery and impact. The severity comes from the combination of remote reachability, low barrier to exploitation, and the server-side trust model failing at the input boundary.

Practical implication: treat any internet-facing RSC endpoint as high priority until you can prove it is patched and not reachable by malicious payloads.

Threat narrative

Attacker objective: The attacker’s objective is to obtain arbitrary code execution on the vulnerable server and use that foothold for deeper 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 abuses unsafe deserialization to gain control inside the server process.
3. Escalation follows when the payload manipulates internal parsing state so React later invokes attacker-chosen server functions.
4. Impact is remote code execution on the application server, which can lead to file access, process spawning, and full 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.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

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

Deserialization trust is the real control gap here: React2Shell shows that server-side parsing is itself an enforcement boundary, not a neutral plumbing layer. When untrusted input can steer promise resolution and internal parser state, application security is no longer just about input validation at the edges. Practitioners should treat any protocol that deserializes remote objects as a policy-enforcement surface, especially when it can trigger server-side logic.

Reachability is more important than package ownership: The article reinforces a familiar governance failure mode in modern application estates, where a vulnerable component may be inherited through a framework rather than installed directly. That weakens any control model based only on dependency manifests or SBOM review. The practical conclusion is that exploitability must be tested in the running application, not inferred from source inventory alone.

Maximum-severity RCEs compress the response window: The combination of unauthenticated access, trivial weaponisation, and reported exploitation within hours means detection and rollback plans need to be pre-staged. This is the kind of issue that exposes whether patch governance, WAF coverage, and runtime verification are actually connected. Teams should assume that speed of exploitation, not disclosure date, defines their real exposure window.

Runtime exploitability testing has become a governance control: This is not just a security engineering convenience. When a patched package exists, the remaining question is whether the deployed application is still reachable and exploitable, which is a material risk decision for release managers and incident responders. Organisations that cannot answer that question quickly are operating with an inventory view of risk, not an operational one.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

What this signals

Runtime validation is now part of application governance: Dependency inventories show what is installed, but they do not show whether a malicious payload can still trigger code execution in production. Teams should move exploitability checks into release and incident workflows so patch decisions reflect real reachability, not just version drift.

React2Shell reinforces the difference between exposure and exploitability: In server-component architectures, transitive framework behaviour can create attack paths that a package list alone will miss. That makes runtime scanning, dependency tree review, and targeted WAF coverage complementary controls rather than interchangeable ones. The practical goal is to know whether the vulnerable path is both present and usable before attackers prove it for you.

For practitioners

• Patch exposed React Server Components immediately Move vulnerable React and Next.js versions to the patched releases as soon as they are available, starting with internet-facing applications and shared front-door services.
• Trace transitive framework dependencies Review the full dependency tree for react-server-dom packages and any framework paths that inherit the vulnerable Flight deserialization logic.
• Validate exploitability in the running app Use runtime scanning to test whether the deployed application is actually reachable through a malicious Flight payload, then rescan after patching to confirm the exposure is gone.
• Hunt for compromise indicators Check logs and host telemetry for next-action headers, $@ patterns, unexpected whoami or id commands, suspicious writes to /tmp, and new child processes from Node.js or React runtimes.
• Constrain exposure with WAF rules Deploy or update web application firewall rules that target known malicious Flight payload patterns while patching and validation are in progress.

Key takeaways

• React2Shell turned a server-side deserialization flaw into a critical unauthenticated RCE path, showing how quickly input handling can become code execution when the server trusts Flight payloads.
• Amazon’s threat intelligence observed active exploitation by multiple groups within hours of disclosure, which shows how compressed the response window is for internet-facing framework flaws.
• The control that matters most is not only patching, but proving exploitability in the running application so teams can separate theoretical exposure from live attack paths.

Key terms

• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• 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.
• Verified Exploitability: Verified exploitability means a finding has been reproduced in execution, not merely inferred from code. It is the practical threshold that separates a plausible defect from a security issue that should drive severity, remediation priority, and incident response.
• Transitive dependency exposure: Security exposure that arrives through an indirect software dependency rather than a package a team selected directly. It matters because the vulnerable code can exist in runtime paths that are easy to miss if governance only tracks top-level frameworks.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect identity control to broader security programmes. It helps security and identity teams build the governance habits needed to manage modern access and trust relationships.