React2Shell exploitation shows how framework RCE breaks server trust

At a glance

What this is: This is Aqua Security’s analysis of CVE-2025-55182, a React Server Components flaw that enables unauthenticated remote code execution in affected React and Next.js deployments.

Why it matters: It matters because framework-layer compromise can expose secrets, alter server behaviour, and turn application runtimes into launch points for broader identity and cloud attacks.

By the numbers:

• The flaw received a CVSS score of 10.0, reflecting its ease of exploitation, massive ecosystem footprint, and the threat of complete server takeover.

👉 Read Aqua Security's analysis of CVE-2025-55182 and React2Shell exploitation

Context

React2Shell is a server-side remote code execution flaw, not a front-end coding mistake. The issue sits in React Server Components, where vulnerable versions trust attacker-controlled metadata during deserialisation. In identity terms, the problem is not just code execution but the collapse of runtime trust around the application layer that guards secrets, tokens, and downstream service access.

For IAM, NHI, and cloud teams, that matters because a server takeover often becomes an identity event next. Once an attacker can execute code in a web application, environment variables, service credentials, API tokens, and internal routes become reachable. That turns a framework vulnerability into a governance problem for workload identity, secrets handling, and privilege containment.

Key questions

Q: What breaks when a web framework can be exploited for remote code execution?

A: The main break is trust. A public request can become server-side code execution, which means secrets, environment variables, internal routes, and service identities are suddenly reachable from outside the application boundary. In practice, that turns patching into only one part of the response. Teams also need secret revocation, runtime containment, and privilege review for any workload touched by the flaw.

Q: Why do server-side rendering frameworks increase the impact of application vulnerabilities?

A: They increase impact because the same runtime often handles rendering, data access, and credential-bearing backend functions. When that runtime is compromised, attackers can move from application logic into secrets, internal APIs, and persistence. The risk is not just broken pages. It is that the web server becomes a trusted execution point for further identity and cloud abuse.

Q: How do security teams reduce the blast radius of internet-facing RCE flaws?

A: They reduce blast radius by removing long-lived credentials from the runtime, restricting service-account privilege, segmenting workload access, and monitoring for suspicious process and file activity. If the application can be compromised, the goal is to ensure the compromised host cannot reach high-value systems or reusable secrets. Containment must be designed before exploitation happens.

Q: Who is accountable when a framework vulnerability exposes workload secrets?

A: Accountability usually spans application owners, platform teams, and identity teams because the failure crosses code, runtime, and credential governance. The patch belongs to the software owner, but the exposure of secrets and service identities belongs to the security programme as well. Teams should assign a clear owner for secret rotation, workload review, and emergency containment whenever a framework RCE appears.

Technical breakdown

Insecure deserialisation in React Server Components

React Server Components expect structured metadata from the client, but vulnerable versions accept attacker-controlled input without sufficient validation. In practice, deserialisation is the point where encoded data becomes executable object structure inside the server runtime. If that boundary is weak, a single request can introduce malicious object types that the framework then processes as legitimate server-side state. Because the flaw sits deep in the RSC pipeline, the attack is not limited to one route or component tree. It can affect the server’s core execution path and any feature that depends on it.

Practical implication: Treat RSC deserialisation as a high-risk trust boundary and block vulnerable versions before they reach internet-facing workloads.

Why Next.js expands the blast radius

Next.js integrates React Server Components deeply into server-side rendering, data fetching APIs, route handlers, and related core functions. That means a weakness in RSC can propagate beyond a single component into broader application behaviour. In cloud-native deployments, this matters because the application server often carries workload credentials, internal connectivity, and deployment privileges. A framework RCE is therefore rarely isolated to one application function. It becomes a path from public HTTP traffic to server control, secret exposure, and internal system reach.

Practical implication: Inventory all React and Next.js entry points together, not as separate stacks, because the shared runtime is where compromise concentrates.

Post-exploitation behaviour in web-layer RCE

Once attackers gain code execution, the common next steps are remote shells, cryptominer deployment, credential harvesting from environment variables, filesystem changes, and persistence. Those actions mirror how modern web-layer RCEs are turned into broader cloud and supply chain incidents. The important technical point is that the exploit does not need authentication or prior foothold. It converts application-layer trust into operational control, which is why exposed secrets and over-privileged runtime identities become the real downstream risk.

Practical implication: Assume exposed secrets and runtime privilege will be targeted immediately after exploitation, and scope containment accordingly.

Threat narrative

Attacker objective: The attacker wants to convert a public web application into a controlled execution environment with access to secrets, internal services, and persistence.

1. Entry occurs through a single malicious HTTP request that targets the vulnerable React Server Components deserialiser in an affected application.
2. Escalation follows when attacker-controlled object data is interpreted inside the React server runtime, allowing arbitrary server-side code execution without authentication.
3. Impact comes from full application takeover, including secret theft, filesystem manipulation, persistence, and use of the compromised server as a launch point for further attacks.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 RCE becomes an identity event the moment the server holds secrets. A web application that can execute attacker-controlled code is no longer just an application security problem. It becomes an identity governance problem because workload credentials, API tokens, and environment variables now sit inside the attacker’s blast radius. Practitioners should treat runtime compromise as a secret exposure and service-account abuse scenario, not only as a patching issue.

Runtime trust for server-side metadata is the named concept this breach sharpens. React Server Components rely on the assumption that structured input can be safely rehydrated into trusted server state. That assumption fails when the actor can supply malicious payloads that the runtime accepts as legitimate objects. The implication is that framework-layer trust must be treated as a control boundary in its own right, not as a developer convenience.

Secret exposure after exploitation is the predictable second breach. The article’s post-exploitation pattern includes credential harvesting from environment variables and further movement through the compromised host. That is the standard failure mode for applications that couple execution with long-lived credentials. The practitioner lesson is that runtime compromise and secret containment are inseparable in modern web stacks.

Cloud-native RCE exposure now spans application, workload, and identity layers. The same flaw can reach route handlers, server-side rendering, internal APIs, and the credentials that service those functions. That makes isolated ownership models obsolete, because app teams, platform teams, and identity teams are all carrying pieces of the same risk. Practitioners should align patching, secret handling, and privilege review as one response path.

Supply chain speed matters as much as vulnerability severity. The article shows active exploitation by multiple attacker classes soon after disclosure, which means remediation windows shrink to hours rather than days in internet-facing environments. The field should read this as another example of framework vulnerabilities outrunning conventional change-control cycles. Practitioners need release governance that can respond at the pace of exploitation.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For lifecycle context, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for rotation and offboarding implications.

What this signals

Runtime compromise must now be treated as an identity containment event. When application servers hold tokens, certificates, and deployment credentials, framework RCE becomes a governance trigger for the wider workload estate. The organisations that recover fastest are the ones that can rotate secrets, revoke access, and prove which identities were resident in the affected runtime before the exploit was contained.

Identity blast radius is the right named concept for this class of incident. It describes how far a single compromised server can reach once its credentials, internal network paths, and service permissions are exposed. That blast radius is often larger than the vulnerability itself because the server is already trusted by other systems. The practical signal is simple: if compromise cannot be bounded to one workload, your identity design is too permissive.

The NIST Cybersecurity Framework 2.0 is useful here because response and recovery only work when asset, identity, and containment ownership are already mapped. Security teams should use framework RCE events to test whether their patch, secrets, and privilege processes can move together under pressure.

For practitioners

• Block vulnerable React and Next.js versions in production Inventory all applications using React 19 and RSC-dependent Next.js releases, then remove affected versions from deployable build paths until patched packages are verified in staging and production.
• Rescan workloads for exposed secrets after any suspected exposure Check environment variables, mounted config, CI/CD variables, and runtime files for credentials that may have been readable during compromise, then revoke and rotate anything that could have left the host boundary.
• Tighten runtime controls around code injection behaviours Use runtime policy to detect unexpected process spawning, shell execution, suspicious file writes, and outbound connections from web workloads so a successful exploit does not become persistent foothold activity.
• Align application patching with secret and identity review When a framework RCE appears, treat it as an identity review trigger for service accounts, API tokens, and deployment credentials attached to the affected workloads, not as a patch-only event.

Key takeaways

• CVE-2025-55182 shows that a framework RCE can become a full identity and secrets incident, not just an application bug.
• The scale of risk is amplified by internet exposure, deep framework integration, and the speed at which attackers weaponise new flaws.
• Teams should pair patching with secret rotation, runtime containment, and workload identity review because one without the others leaves the same compromise path open.

Key terms

• Server-Side Deserialisation: The process of turning incoming structured data into objects that a server can use. In security terms, it becomes dangerous when the input is not fully trusted, because maliciously shaped data can alter execution flow, trigger unintended logic, or create code execution paths inside the runtime.
• Runtime Trust Boundary: The point where an application assumes incoming data or actions are safe enough to process inside the server environment. When that boundary is weak, attacker-controlled input can influence internal state, access secrets, and move from application behaviour into operational compromise.
• Identity Blast Radius: The amount of access and downstream reach available once a workload, account, or token is compromised. It is measured by how many systems, secrets, and services can be touched before containment occurs, and it is often larger than teams expect when credentials live inside application runtimes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: Critical CVE in React Server Components Actively Exploited. Read the original.