React2Shell shows how pre-auth RCE becomes full-stack compromise

At a glance

What this is: React2Shell is a pre-auth remote code execution flaw in React Server Components and Next.js App Router that turns a crafted HTTP request into server-side code execution.

Why it matters: It matters because a front-end framework flaw can become an identity and infrastructure breach path, forcing IAM, cloud, and application teams to treat exposed web workloads as high-risk attack surfaces.

By the numbers:

• Wiz research indicates roughly 39% of cloud environments they analysed contain React or Next.js versions vulnerable to React2Shell-class issues.
• Recent surveys show over 80% of surveyed developers use React in some form.
• CISA has added CVE-2025-55182 to the Known Exploited Vulnerabilities catalog, setting a remediation deadline of 26 December 2025 for US federal agencies.

👉 Read FireCompass' analysis of the React2Shell pre-auth RCE and exposure paths

Context

React2Shell is a server-side code execution issue in the React Server Components pipeline, not a client-side rendering bug. The governance gap is that teams often treat modern front-end frameworks as presentation layers, even when they execute trusted logic on the server and inherit access to secrets, identities, and internal systems.

For IAM and cloud security teams, the important question is how quickly a web application foothold can reach credentials, metadata services, service accounts, and internal dependencies. That makes the issue relevant beyond AppSec, because a vulnerable React or Next.js workload can become an entry point into privilege, identity, and data domains rather than a standalone application problem.

The starting assumption that a browser-facing app is isolated from core systems is now typical, and React2Shell shows why that assumption fails in server-rendered stacks.

Key questions

Q: What breaks when React Server Components are exposed to unauthenticated traffic?

A: The trust boundary breaks at the server parser. If a vulnerable React Server Components endpoint accepts crafted Flight protocol payloads, an attacker can reach server-side execution before authentication, then use that foothold to inspect local secrets, call internal services, or pivot into cloud identities. The first failure is not user login, it is unauthorised code execution on the application runtime.

Q: Why does a pre-auth RCE in a web framework become an identity risk?

A: Because the application runtime often runs with service-account permissions, metadata access, or deployment secrets that function as non-human identity credentials. Once code execution is achieved, the attacker can abuse those credentials to move into cloud APIs, internal applications, or directory services. In practice, the web tier becomes an identity boundary with too much standing privilege.

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 first after finding a vulnerable React or Next.js app?

A: Patch the exposed workload, then immediately validate whether the application runtime can reach sensitive identities, metadata, or internal services. That sequencing matters because a fixed package does not remove already-issued credentials or hidden lateral paths. Containment should follow the attack path, not just the CVE ticket.

Technical breakdown

How Flight protocol deserialization creates pre-auth RCE

React Server Components use the Flight protocol to exchange structured component data between client and server. In vulnerable versions, server-side deserialization of crafted HTTP payloads lets attacker-controlled input influence object lookup and execution paths before application authentication or business logic runs. That matters because the trust boundary is not the browser UI, it is the server parser handling serialized component state. Once that parser accepts malformed structures, the attacker can drive code paths that were never meant to be reachable from the network.

Practical implication: inventory every RSC-enabled endpoint and validate whether server-side deserialization is exposed to unauthenticated traffic.

Why App Router deployments inherit the same attack surface

Next.js App Router embeds React Server Components, so the vulnerability is not limited to teams that explicitly build custom server-function logic. Any deployment that enables the RSC pipeline can inherit the same unsafe deserialization risk, including applications that appear conventional from a code-review perspective. This is a packaging and runtime issue as much as an application bug, which is why version checks alone are insufficient if build artefacts, canary releases, or framework wrappers still ship the vulnerable path.

Practical implication: verify runtime behaviour, not just package inventory, before assuming an App Router deployment is safe.

How pre-auth RCE becomes identity and infrastructure exposure

Once an attacker reaches arbitrary code execution in a Node.js process, the next step is usually local discovery. That process can read environment variables, configuration files, deployment scripts, and sometimes instance metadata or mounted credentials, then use those identities to pivot into cloud control planes, internal services, or CI/CD systems. The security problem therefore extends far beyond the original CVE. The real architecture issue is that application runtime identity often has more reach than teams realise.

Practical implication: treat application runtime identities as privileged assets and restrict what web-tier processes can query or reach.

Threat narrative

Attacker objective: The attacker wants to turn one exposed web application into durable access to cloud, identity, and internal enterprise resources.

1. Entry occurs when an attacker sends a single crafted HTTP request to a vulnerable React Server Components endpoint and triggers unauthenticated server-side code execution.
2. Escalation follows when the attacker uses the compromised Node.js process to enumerate local secrets, environment variables, instance metadata, and reachable internal services.
3. Impact occurs when the attacker pivots into cloud APIs, internal applications, CI/CD systems, or directory services to expand access, exfiltrate data, or establish persistence.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

React2Shell is not just an AppSec flaw, it is a runtime identity problem. Once server-side rendering code can be reached anonymously, the application process itself becomes the attacker’s entry point into secrets, cloud metadata, and downstream systems. That shifts the control question from front-end patching to runtime privilege containment and service-account governance. Practitioners should treat web workloads as identities with blast radius, not just code to patch.

Server-rendered front ends create a hidden trust boundary that many governance models still miss. Teams often assume the browser is the attack surface, but React Server Components move execution into the server tier and expand the consequences of a single parsing bug. This is a named server-side rendering trust gap, where presentation-layer tooling silently inherits backend authority. Security teams should re-map those workloads into their IAM, PAM, and cloud risk inventories.

KEV inclusion changes the operational posture from vulnerability awareness to exposure management. Once a flaw is publicly exploited and catalogued, the deciding factor becomes not whether the CVE exists in a dependency tree, but which internet-facing services can actually reach exploitable code paths. That makes external attack surface visibility, segmentation, and compensating controls part of the remediation plan. Practitioners should prioritise exposed RSC workloads with access to secrets, metadata, or internal control planes.

React2Shell reinforces that application identities deserve the same scrutiny as human identities in privileged workflows. A Node.js process that can query metadata services, read deployment secrets, or call cloud APIs is operating as a non-human identity with material reach. If that identity is over-scoped, compromise of the app becomes compromise of the authorisation boundary itself. Practitioners should align application runtime access with the same least-privilege expectations used for high-value service accounts.

Attack paths matter more than package names. The article shows how a vulnerable framework can be the first step in a much larger compromise chain involving cloud control planes, Active Directory, DMZ networks, and CI/CD systems. That means remediation should be prioritised by reachable impact, not by whether a package appears in a bill of materials. Practitioners should rank exposure by exploitability plus downstream privilege.

From our research:

• The ratio of non-human to human identities now exceeds 100:1 in enterprise environments, according to Ultimate Guide to NHIs , Why NHI Security Matters Now.
• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• React2Shell reinforces why runtime identity governance and secrets containment must be treated as a forward control, not a cleanup exercise.

What this signals

React2Shell widens the scope of external attack surface management. Teams cannot rely on dependency lists alone when a framework can execute server-side logic through an exposed application path. The operational question becomes whether internet-facing workloads with RSC enabled are also carrying secrets, metadata reach, or privileged service identities. That is a programme-level exposure issue, not just a patching issue.

Server-side rendering now needs identity-aware segmentation. A web runtime that can touch cloud APIs or internal services should be segmented like any other privileged workload, with tightly scoped egress and monitored identity use. That reduces the chance that a single framework flaw becomes a cloud or directory compromise. Where this aligns with policy, practitioners should map the control set to NIST SP 800-53 Rev 5 Security and Privacy Controls and CISA cyber threat advisories.

Server-side rendering trust gap: this is the governance blind spot that will keep recurring until teams treat framework execution as privileged infrastructure. The next step is to tie exposed web applications to the identities, secrets, and network paths they can actually reach, then reduce that reach before exploitation does it for them.

For practitioners

• Map all RSC-enabled web workloads Identify every React 19 and Next.js App Router deployment, including wrappers and canary builds, then confirm whether React Server Components are actually enabled in production.
• Validate real exploitable paths Use attack-centric testing to determine whether unauthenticated requests can reach the vulnerable Flight protocol handling path, rather than relying on dependency scans alone.
• Restrict runtime identity reach Review what the Node.js process can access, including environment variables, metadata services, mounted secrets, cloud APIs, and internal service endpoints.
• Prioritise internet-facing exposed apps Patch exposed RSC workloads first, especially those connected to cloud control planes, directory services, or CI/CD systems where compromise has a large blast radius.
• Instrument post-exploitation detection Monitor for unusual metadata service access, new cloud API calls, suspicious child processes, and unexpected outbound traffic from React or Next.js hosts.

Key takeaways

• React2Shell shows that a single unauthenticated request can turn a modern JavaScript framework into a server-side compromise path.
• The impact is amplified when the application runtime can reach secrets, metadata services, cloud APIs, or internal identity systems.
• Teams should prioritise exposed RSC workloads by reachable blast radius, not by CVE count alone.

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.
• Flight protocol: The Flight protocol is the data transport React uses to move component information between client and server in React Server Components. It is security-sensitive because the server must parse structured input that can influence execution flow if validation is weak or assumptions about origin are wrong.
• Unauthenticated Remote Code Execution: A flaw that lets an attacker run code on a target system without first proving who they are. In enterprise applications, this is especially dangerous because the code executes inside a trusted workload context, which can expose data, internal services, and downstream privileges.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.

What's in the full article

FireCompass' full blog covers the operational detail this post intentionally leaves for the source:

• Version-specific affected and fixed builds for React Server Components and Next.js App Router.
• Attack-path examples showing how a compromised web tier can reach cloud control planes, Active Directory, and CI/CD systems.
• Detection guidance for identifying exposed React and Next.js assets across the external attack surface.
• Playbook details for validating whether a vulnerable endpoint is actually exploitable in your environment.

👉 FireCompass' full post covers exploitation stages, affected versions, and validation guidance.

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. It helps security practitioners translate identity controls into operational decisions across modern application and cloud environments.