React2Shell exposes unauthenticated RCE risk in default RSC builds

At a glance

What this is: React2Shell is a critical unauthenticated RCE flaw in React Server Components that can compromise a Node.js process through a crafted HTTP request.

Why it matters: It matters to IAM and platform teams because exposed application endpoints and framework defaults can create a privilege boundary bypass that turns runtime code execution into data and identity impact.

By the numbers:

• Exploitation can succeed with near 100% reliability.
• The React and Next.js teams disclosed two related vulnerabilities in the React Server Components Flight protocol on December 3, 2025.

👉 Read SentinelOne's analysis of React2Shell and unauthenticated RCE in RSC

Context

React2Shell is a framework-level remote code execution issue in React Server Components, which means the danger sits in the application runtime path rather than in a single misconfigured server. The primary concern is that default builds can expose attack surface even when teams believe they have not enabled risky server-side behaviour. For identity and access practitioners, this is another reminder that application runtime exposure can become a control-bypass route that sits outside traditional IAM review cycles.

The security problem is not limited to patching a package. When server functions or deserialization paths are reachable, an unauthenticated request can cross from web traffic into code execution, which then threatens application secrets, service credentials, and downstream access to cloud resources. That makes the issue relevant to NHI governance as well as broader application security, because a compromised runtime often becomes a launching point for secret theft and privileged access abuse.

Key questions

Q: What should teams do first when a framework RCE flaw exposes server-side application code?

A: Start by identifying which workloads expose the vulnerable endpoint, then patch the affected framework versions and isolate any public assets that may already have been touched. If the vulnerable process held secrets or service credentials, rotate them as part of containment. The priority is to remove the reachable attack path before assuming the application is clean.

Q: Why do default framework settings create hidden attack surface for application teams?

A: Default settings can enable server-side paths that developers never explicitly configured, so the risk sits in the framework runtime rather than in custom code. That means a standard deployment can still be reachable from the internet and may expose a code execution path. Security teams need to assess framework defaults as production exposure, not just design choices.

Q: How do security teams know whether an RCE issue has become an identity problem?

A: It becomes an identity problem when the compromised process holds tokens, API keys, certificates, or service account credentials that can be replayed or abused. At that point the attacker is not only executing code but also inheriting workload authority. That is why secret rotation and credential review must follow exploit confirmation, not wait for later cleanup.

Q: What frameworks should teams use to govern exploitable application runtime flaws?

A: Use MITRE ATT&CK to map the attack path, NIST CSF to structure detection and response, and NIST SP 800-53 controls for access control, authentication, logging, and system integrity. If exposed workloads rely on long-lived secrets, add NHI governance so runtime credentials are treated as part of the attack surface.

Technical breakdown

Insecure deserialization in React Server Components Flight payloads

React Server Components use the Flight protocol to move data between client and server in a structured format. The flaw exists because attacker-controlled payloads are deserialized without sufficient validation, so the server can be induced to interpret malicious input as executable state. In practice, that converts a data parsing step into a code execution path. Because the issue sits in framework handling rather than in custom application code, teams may be exposed even when their own codebase appears minimal or well-reviewed.

Practical implication: validate whether any deployed build exposes RSC endpoints and remove the assumption that custom server code is required for risk.

Why default Next.js and RSC deployments become attackable

Default framework behaviour can activate RSC-related server paths without developers explicitly designing them. That matters because many security reviews focus on the application’s own logic and overlook the framework runtime that the build system enables underneath it. If the endpoint is publicly reachable, an attacker does not need credentials, interactive phishing, or prior foothold. The browser-facing request becomes the entry point, and the Node.js process becomes the target.

Practical implication: inventory framework-generated endpoints as part of application attack surface review, not just routes that developers intentionally created.

From code execution to process compromise and follow-on abuse

A successful exploit against the RSC deserialization path can compromise the full Node.js process, which often holds runtime secrets, access tokens, and backend connectivity. At that point the issue is no longer just code execution. It becomes a trust problem for secrets, service identities, and any workload permissions attached to the compromised process. That is why detection of reverse shells and suspicious downloaders matters immediately after patching, not only before it.

Practical implication: treat the affected process as a potential identity compromise event and rotate exposed secrets, tokens, and service credentials if exploitation is suspected.

Threat narrative

Attacker objective: The attacker aims to gain unauthenticated control of the server-side application runtime and then leverage that foothold to steal secrets and expand access.

1. Entry occurs through a crafted HTTP request sent to an exposed React Server Components endpoint that accepts unsafe Flight payloads.
2. Escalation follows when the malicious payload is deserialized and executed inside the Node.js process without authentication.
3. Impact is full process compromise, enabling secret theft, reverse shell execution, and downstream abuse of connected cloud or application privileges.

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

Framework-default exposure is becoming the new application blind spot: this flaw shows that security teams can no longer assume unconfigured means unexposed. When a framework enables server-side behaviour by default, the attack surface exists even if development teams never intended to publish it. That changes how application security, cloud security, and identity teams should scope reviews. The practitioner conclusion is that build-time defaults must be treated as production risk, not implementation detail.

Unauthenticated RCE is also an identity event once the runtime holds secrets: the compromise of a Node.js process often collapses into service account theft, token replay, or access to backend APIs. In that sense, a web framework exploit becomes a non-human identity governance problem because the first useful asset is frequently a credential, not the shell itself. The practitioner conclusion is to treat runtime secret exposure as part of the blast radius, not a secondary issue.

Blast-radius control is the named concept this incident sharpens: when a single request can own the process, the real question is how much downstream privilege the workload carries at runtime. This is a control gap, not just a patching issue, because the application may be over-entitled long before the exploit lands. The practitioner conclusion is to reduce the privilege held by exposed workloads before the next framework flaw appears.

Detection must shift from static vulnerability lists to exploitability evidence: the article’s emphasis on validation reflects a broader market problem where teams drown in theoretical findings and miss the paths that are actually reachable. Runtime validation, suspicious process behaviour, and exposed-endpoint discovery need to be linked so that remediation is based on confirmed attack paths. The practitioner conclusion is to prioritise verified exploitability over inventory alone.

Managed secrets and workload identity become critical once the process boundary is lost: if the server process can be compromised from the edge, any embedded secret or long-lived token inside that process becomes part of the attacker’s options. This is where NHI governance intersects directly with application security. The practitioner conclusion is to shorten credential lifetime and separate sensitive workloads from externally reachable code paths.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 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.
• Forward pivot: If exposed runtime secrets are part of the compromise path, review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that shrink the blast radius.

What this signals

Runtime exploitability is now an identity governance signal as much as a vulnerability signal: once a framework flaw can expose service credentials, the affected workload should be treated as an NHI security event, not just an appsec ticket. The programme implication is that secrets inventory, workload identity, and endpoint exposure need to be reviewed together so that a code flaw does not become a credential incident.

Blast-radius control will matter more than simple patch velocity: the practical question is not only how fast a team can upgrade React or Next.js, but how much authority the exposed workload carried before the upgrade. If the runtime had access to cloud APIs, backend databases, or signing keys, those privileges should be narrowed before the next externally reachable code path appears.

Attacker dwell time against exposed secrets is extremely short, which makes validation and rotation the decisive pair: according to our research, public AWS credentials can attract access attempts within 17 minutes. For teams running internet-facing Node.js workloads, that means exposure review and secret rotation need to be operationally tied together rather than treated as separate workstreams.

For practitioners

• Map all RSC-exposed workloads Identify every React and Next.js deployment that may expose React Server Components endpoints, including default builds and generated routes. Confirm whether the workload is publicly reachable and whether server-side RSC logic is active even when developers did not add custom server functions.
• Patch framework versions immediately Move affected React and Next.js packages to the vendor-published fixed releases and verify that dependent bundler versions ship patched server bundles. Do not wait for full code refactoring before closing the vulnerability window.
• Validate exploitability on exposed assets Use safe, defanged request testing to confirm which public workloads are truly exploitable rather than relying on a generic vulnerability list. Validate only from approved environments and capture evidence of actual endpoint reachability.
• Rotate runtime secrets after suspected exposure If you have signs of exploitation, assume the Node.js process may have revealed tokens, API keys, certificates, or backend credentials. Rotate those secrets, reissue affected credentials, and review any service account permissions attached to the workload.
• Hunt for process and shell activity Enable and review detections for reverse shells, downloaders, and suspicious Node.js child processes. Correlate those signals with public RSC endpoint access so you can separate scanning noise from a confirmed exploitation attempt.

Key takeaways

• React2Shell shows that default framework behaviour can create unauthenticated RCE paths even when developers did not intentionally expose server-side functionality.
• The operational impact is larger than code execution because compromised Node.js processes can reveal service credentials, API keys, and backend access.
• Teams should combine rapid patching with endpoint discovery, exploitability validation, and runtime secret rotation to limit the blast radius.

Key terms

• React Server Components: React Server Components are a framework feature that shifts part of the rendering and data handling work to the server. They reduce client-side load, but they also introduce server-side request paths that must be validated, monitored, and governed like any other application attack surface.
• Insecure Deserialization: Insecure deserialization occurs when untrusted data is converted into objects or execution state without sufficient validation. In application frameworks, that can allow attacker-controlled input to influence control flow, making a parsing step into a direct route to code execution.
• Node.js Process Compromise: Node.js process compromise means an attacker has execution inside the running application process and can use its memory, files, and connected permissions. In modern cloud deployments, that often includes access to secrets, backend systems, and service identities attached to the workload.

What's in the full article

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

• The exact vulnerable package and version matrix across React and Next.js deployments.
• Step-by-step validation guidance for identifying publicly exposed RSC endpoints in live environments.
• The published detection rules and reverse shell behaviours SentinelOne recommends enabling.
• The defanged exploit simulation approach used to confirm exploitability without causing harm.

👉 The full SentinelOne post covers exploit validation, detection rules, and immediate containment steps for affected workloads.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps teams connect runtime exposure to access control decisions. It is designed for practitioners who need to align identity controls with operational security in modern application environments.