TL;DR: React2Shell exposes unauthenticated remote code execution in React Server Components and Next.js deployments through insecure deserialization in the RSC Flight protocol, with exploitation possible from a single crafted HTTP request, according to SentinelOne. The issue shows how default framework behaviour can become a server compromise path when runtime exposure is not continuously validated.
NHIMG editorial — based on content published by SentinelOne: React2Shell and unauthenticated remote code execution in React Server Components
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read SentinelOne's analysis of React2Shell and unauthenticated RCE in RSC →
React2Shell and RSC defaults: what security teams need to do now?
Explore further
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: React2Shell exposes unauthenticated RCE risk in default RSC builds