React2Shell exposes unauthenticated RCE across React server apps

At a glance

What this is: This is an analysis of React2Shell, a critical RCE flaw in React Server Components and framework integrations that can be triggered by crafted HTTP requests.

Why it matters: It matters because modern applications often inherit React server features by default, so identity and access assumptions around workload trust, API exposure, and runtime privilege can collapse without any custom application logic.

By the numbers:

• Security researchers confirm nearly 100% exploitation reliability for React2Shell, and report that 39% of cloud environments run vulnerable instances.
• Researchers also found that 44% of all environments run publicly exposed Next.js applications affected by React2Shell.

👉 Read Xygeni's analysis of React2Shell exposure across React Server Components and Next.js

Context

React2Shell is a server-side execution flaw, not just a dependency issue. It matters because frameworks can expose dangerous behaviour through default runtime paths, even when developers never intended to create custom server actions. In identity terms, that kind of inherited trust creates a workload and application boundary problem, not simply a patching problem.

The key governance gap is that application stacks often treat framework inputs as trusted once they pass through serialization layers. When that assumption breaks, attackers can move from unauthenticated request traffic to code execution on the server. For teams managing IAM, PAM, and non-human identity controls, this is a reminder that runtime trust boundaries and service privileges need the same scrutiny as human access.

The exposure pattern is typical of modern framework-driven estates: widespread, default-on, and easy to miss until scanning or exploitation reveals the gap. That makes React2Shell a useful case study in how software supply chain issues become identity-adjacent runtime risks.

Key questions

Q: What breaks when a framework trusts serialized request data too much?

A: When a framework trusts serialized request data too much, an unauthenticated HTTP request can become server-side execution. The failure is not only input validation. It is a trust boundary collapse inside the runtime, where attacker-controlled structure reaches code paths that were meant to remain internal. That can expose the application host, its service account, and any attached secrets.

Q: Why do server-side framework flaws create identity risk as well as application risk?

A: Server-side framework flaws create identity risk because the application runtime usually runs with a workload identity, service account, or token set that already has real permissions. Once code execution is achieved, the attacker inherits that identity context. The result is often broader access than the original application issue suggests, especially in cloud environments with over-privileged workloads.

Q: How do security teams know whether React2Shell-style exposure is actually contained?

A: They need three signals: all deployed builds reference fixed versions, no vulnerable RSC packages appear in compiled artefacts or dependency trees, and logs show no suspicious requests or abnormal outbound activity after disclosure. If any exposed service remains unpatched, containment is incomplete, even if a WAF is in place.

Q: What should teams do when a public framework vulnerability affects default deployments?

A: Teams should prioritise containment before everything else: patch the affected packages, restrict public access where possible, and reduce the runtime privileges of the impacted workload. Then validate the full SBOM and monitor for exploitation traffic. Default-deployment exposure means the blast radius may be wider than expected, so remediation needs both code and identity controls.

Technical breakdown

How React Server Components turn HTTP payloads into server execution

React Server Components use a serialization and deserialization pipeline to move structured data between client and server. In vulnerable implementations, the React Flight protocol accepted crafted payloads that caused unsafe object traversal during deserialization. That is why an external HTTP request could influence server-side behaviour without requiring application-specific code. The weakness is not ordinary input validation failure at the page layer, but a trust failure inside the framework runtime itself. When deserializers resolve object paths unsafely, attacker-controlled structure can reach execution primitives on the server.

Practical implication: Validate every framework path that deserializes external payloads, not just application endpoints.

Why default Next.js configurations increased exposure

Next.js exposed the vulnerable React server paths through HTTP by default, which made many standard deployments reachable without custom logic. Applications built with create-next-app inherited the RSC pathway even when teams did not explicitly design around Server Actions. This matters because a framework default can create a hidden attack surface across many estates at once. The issue is broader than one package version. Any stack bundling React server packages, bundlers, or plugins that include RSC support can inherit the same runtime risk if the vulnerable versions remain present.

Practical implication: Inventory framework defaults and transitive packages before relying on application-level hardening.

Why detection needs runtime signals, not just dependency checks

Dependency scanning alone may show that React server packages exist, but it does not confirm whether the vulnerable execution path is reachable in production. Researchers described detectable error patterns, unusual multipart payloads, and repeated requests to RSC endpoints as useful indicators. That means defenders need both software composition analysis and runtime telemetry. The useful signal is not merely that React is present, but that exposed endpoints are receiving malformed RSC traffic and returning characteristic failures. In other words, exposure and exploitability are separate questions.

Practical implication: Pair SCA with logging, alerting, and endpoint-specific anomaly detection for RSC traffic.

Threat narrative

Attacker objective: The attacker wants unauthenticated remote code execution on publicly reachable application servers.

1. Entry occurs when an attacker sends a crafted HTTP request containing a malicious React Flight payload to an exposed React Server Components endpoint.
2. Escalation happens when the vulnerable deserializer follows unsafe object paths and converts attacker-controlled structure into server-side code execution.
3. Impact is remote execution with the privileges of the Node.js process, enabling takeover, data access, or further lateral movement from the compromised application host.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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 defaults are now an identity and privilege problem, not just an application bug. React2Shell shows that modern web stacks can embed executable trust assumptions deep inside default server behaviour. When an unauthenticated request can reach code execution, workload identity and runtime privilege become the real control plane. Practitioners should treat framework defaults as security policy, because those defaults define who or what can act inside the server boundary.

Runtime deserialization trust gap is the named failure mode this incident exposes. The vulnerable path existed because the framework trusted serialized structure more than it trusted external origin. That trust gap is especially dangerous in cloud estates where application workloads already carry broad service permissions. The lesson for IAM and PAM teams is that application runtimes can create privilege without an access review ever seeing it.

React2Shell validates the need for SBOM plus reachability analysis. Many teams can enumerate dependencies but still miss whether the vulnerable code path is enabled, exposed, and externally reachable. Security programmes need to correlate software composition data with live endpoint exposure and runtime telemetry. That is how you distinguish dormant risk from active attack surface.

NHI governance is relevant here because application servers are non-human identities in practice. The Node.js process, its service account, and any attached tokens can become the blast radius once execution is obtained. If those credentials are long-lived or over-privileged, an application flaw becomes an identity compromise multiplier. Practitioners should align framework patching with workload identity containment.

Attack surface control must move closer to the deserializer. WAF rules and alerting help during emergency response, but they do not fix the architectural mistake of treating external RSC payloads as inherently safe. The longer-term control objective is to reduce trust at the serialization boundary, limit runtime privilege, and ensure exposed framework endpoints are continuously verified. Teams should use this incident to harden how framework trust is granted, not just how fast patches are applied.

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.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• A separate analysis of NHI compromise shows attackers can attempt access within 17 minutes of public AWS credential exposure, which is why runtime exposure and secret governance must be treated as one problem.

What this signals

RSC runtime exposure is a useful reminder that workload identity and application security now overlap. When an unauthenticated request can trigger server execution, the workload identity attached to that process becomes part of the incident path. Teams should review where application runtimes hold tokens, service credentials, or broad cloud permissions, then align those privileges with NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0.

Runtime deserialization trust gap: this is the control failure to watch as more frameworks embed server-side features by default. If your programme can inventory packages but cannot verify whether exposed endpoints are reachable and executable, you do not yet have enough governance over the application boundary. That gap will keep showing up wherever build-time trust assumptions become runtime privilege.

Exposure will likely keep outpacing manual review unless teams connect SBOM data, endpoint telemetry, and identity scoping in the same operating model. The practical shift is toward continuous verification of framework behaviour, especially for services that can invoke code from remote input. For identity-led programmes, that means treating service accounts, workload permissions, and secrets as part of application attack surface management, not as separate exercises.

For practitioners

• Patch vulnerable React server packages immediately Upgrade affected React and Next.js versions to the patched releases and verify that transitive framework packages no longer pull in vulnerable RSC implementations.
• Scan for exposed RSC endpoints and default framework paths Identify public Next.js and other RSC-enabled deployments, then confirm which endpoints accept React Flight payloads over HTTP.
• Correlate SCA results with runtime telemetry Use software composition analysis alongside logs for malformed multipart payloads, repeated 500 responses, and suspicious Next-Action headers.
• Limit workload privilege before exploitation can spread Reduce the service account privileges attached to application runtimes so a server-side execution flaw cannot immediately expose broader cloud access.
• Verify the full SBOM across build and container layers Check direct dependencies, transitive packages, and base images for embedded React server components that may keep the vulnerable code path alive.

Key takeaways

• React2Shell shows how a framework-level trust failure can turn ordinary HTTP traffic into unauthenticated server execution.
• The exposure is broad because default RSC-enabled deployments, especially in Next.js, inherit the risky path without custom application logic.
• Patch management, runtime telemetry, and workload privilege reduction need to move together if teams want 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.
• React Flight Protocol: The transport and serialization format used by React Server Components to move structured component data between client and server. In security terms, it becomes a trust boundary. If the parser or deserializer mishandles attacker-controlled structure, the framework can turn a request into unintended server-side execution.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.

What's in the full article

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

• Package-version mapping for the affected React server components and Next.js releases
• Detection logic for malformed React Flight traffic and characteristic error responses
• Patch sequencing guidance for large JavaScript estates with transitive framework dependencies
• Temporary WAF and cloud-provider response options while remediation is rolling out

👉 The full Xygeni post covers the vulnerable versions, detection behaviour, and immediate response steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle control. It helps security practitioners connect workload privilege to broader identity governance decisions.