React and Next.js RCE shows how fragile app dependency trust is

At a glance

What this is: This is an analysis of critical unauthenticated RCE vulnerabilities in React Server Components and Next.js App Router, with a key finding that the flaw can be exploited reliably through crafted HTTP requests.

Why it matters: It matters because application dependency exposure can become an identity and access problem when trusted server-side components accept attacker-controlled input and turn it into execution.

By the numbers:

• 39% of cloud environments contain instances of Next.js or React in vulnerable versions, according to Wiz research.
• 44% of all cloud environments have publicly exposed Next.js instances, according to Wiz research.
• The vulnerability is present in React 19.0, 19.1, and 19.2, according to StepSecurity's analysis.

👉 Read StepSecurity's analysis of critical React and Next.js RCE vulnerabilities

Context

React Server Components and Next.js App Router sit in the application delivery path, so a flaw in their request handling can become a direct execution path on the server. In this case, the risk is not just code quality, but the trust boundary between untrusted HTTP input and privileged runtime behaviour in modern JavaScript application stacks.

For identity and access teams, the relevance is indirect but real: application compromise often becomes credential exposure, token abuse, and lateral movement once server-side execution is achieved. This is a software supply chain and runtime trust problem, and the starting position of many organisations with internet-facing frameworks is often weaker than they assume.

StepSecurity's guidance is operationally focused, but the broader lesson is that exposed frameworks with embedded dependencies need continuous inventory and patch validation. That is typical of modern cloud-native estates, not an edge case.

Key questions

Q: How should security teams respond when React or Next.js RCE vulnerabilities are disclosed?

A: Treat it as an exposure and containment problem, not only a patching task. Prioritise internet-facing applications, deploy the vendor-patched versions, verify direct and transitive dependencies, and watch logs for exploit activity. If compromise is plausible, rotate secrets and invalidate sessions linked to the affected application tier.

Q: Why do framework vulnerabilities create identity risk in cloud workloads?

A: Framework flaws create identity risk because cloud runtimes often have standing access to tokens, certificates, metadata services, and internal APIs. If an attacker gains code execution, they do not need to break identity first. They can reuse whatever the workload already trusts, which makes entitlement scope and secret placement part of the threat model.

Q: What do organisations get wrong when they treat patching as the primary defence?

A: They assume remediation happens before exposure becomes operationally dangerous. In an AI-accelerated environment, that assumption weakens because attackers can find and use flaws faster than change cycles complete. Patch management still matters, but it must be paired with containment, isolation, and access reduction.

Q: Who is accountable when a vulnerable application framework is exposed to the internet?

A: Accountability usually spans engineering, platform, and security operations. Engineering owns patching and release validation, platform teams manage exposure and deployment controls, and security teams verify risk acceptance only after reachability, version state, and monitoring are all confirmed.

Technical breakdown

Why insecure deserialization in React Server Components becomes RCE

React Server Components use the Flight protocol to move structured data between client and server. When that data is not validated tightly enough, attacker-controlled content can influence how the server reconstructs objects and execution flow. In practical terms, insecure deserialization means untrusted input is being treated as if it were trusted program state, which is a classic path from parsing to code execution. The problem is amplified when the server component boundary is deeply embedded in popular frameworks, because the same flaw can exist across many downstream applications and package versions.

Practical implication: map every server component dependency and patch the exact package versions that carry the vulnerable parsing path.

Why public exposure turns a framework flaw into an urgent enterprise risk

A vulnerability only becomes a widespread incident when reachable systems are easy to find. Publicly exposed Next.js instances reduce attacker effort because internet scanning can identify targets before defenders finish internal validation or patch planning. The same pattern appears across cloud-native incidents: availability of a reliable exploit matters less than the number of reachable systems already on the internet. Once a framework runs in an exposed application tier, the issue moves from code defect to operational exposure management, which requires both asset inventory and attack surface reduction.

Practical implication: identify externally reachable Next.js services first, then patch and restrict access before broader remediation work begins.

Why dependency monitoring matters after patched releases

Framework patches do not automatically remove risk if teams cannot verify where the affected packages are embedded indirectly. Modern JavaScript supply chains often pull in nested versions through multiple frameworks, bundlers, and plugins, which means a simple top-level upgrade may miss hidden exposure. That is why inventory, version verification, and monitoring for newly disclosed vulnerabilities must sit alongside patching. In governance terms, the control gap is incomplete dependency visibility, not just slow remediation.

Practical implication: verify both direct and transitive package versions across repositories, images, and build artefacts before declaring remediation complete.

Threat narrative

Attacker objective: The attacker aims to gain server-side code execution on internet-facing applications without authentication, then leverage that access for deeper compromise.

1. Entry occurs when an attacker sends a specially crafted HTTP request to a vulnerable React Server Components or Next.js App Router endpoint.
2. Escalation follows when insecure deserialization in the Flight protocol converts attacker-controlled input into server-side execution logic.
3. Impact is unauthenticated remote code execution on the application server, creating a foothold for credential theft, persistence, or further compromise.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Dependency trust has become an access-control problem. When a framework accepts untrusted input and turns it into server execution, the security boundary has already failed before any downstream control can help. For IAM and PAM teams, the lesson is that compromise at the application layer often becomes token theft, session hijacking, and privilege escalation almost immediately. Practitioners should treat framework trust as part of the access model, not just the software build pipeline.

Public exposure is what turns a latent defect into a mass-risk condition. The combination of vulnerable versions and internet-facing instances creates the kind of high-probability target set attackers prefer. This is why application inventory, external attack surface monitoring, and patch validation belong in the same operational conversation. Teams that only count patched packages but not reachable services will underestimate real exposure.

Dynamic dependency governance is now a core control, not a release task. Many organisations still treat framework updates as engineering maintenance, but the security consequence is closer to emergency control remediation. The control gap here is not only the presence of vulnerable code, but the inability to prove where it exists across direct and transitive dependencies. That makes software inventory and version attestation part of modern governance.

Runtime exploitability creates downstream identity risk even when the bug is not an identity bug. Once an application server is compromised, attackers often pivot to secrets, service credentials, and privileged APIs. That means NHI governance, secret storage, and workload identity controls must be prepared for application-layer compromise scenarios. A mature programme assumes code execution can become identity abuse very quickly.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• That same visibility gap should push teams to review NHI Lifecycle Management Guide alongside application dependency controls, because exposed code paths and exposed identities fail in similar ways.

What this signals

The practical signal for security programmes is that application vulnerability management and identity governance are converging at the point of compromise. When an internet-facing framework flaw leads to server execution, the next questions are about secrets, service credentials, and the blast radius of workload access, not just the patch ticket.

Dependency reachability debt: this is the gap between knowing a vulnerable package exists and knowing whether it is actually exposed in production. Teams need to connect software inventory, attack surface management, and secret hygiene so that a framework flaw does not become a credential event.

The most mature response will blend patch cadence with runtime monitoring and identity containment. That means teams should pair framework patching with secret rotation, service account review, and tighter trust around application-to-cloud authentication paths.

For practitioners

• Patch exposed React and Next.js instances first Prioritise externally reachable applications running vulnerable React Server Components or Next.js App Router versions, then move inward to less exposed environments. Use the exact patched versions listed by the vendor guidance and verify deployment parity across all tiers.
• Verify direct and transitive package versions Run repository, image, and build-time checks for react-server-dom and Next.js dependencies, including nested bundles from frameworks and plugins. Confirm that indirect dependencies are not reintroducing the vulnerable code path after upgrade.
• Monitor logs for exploitation patterns Review application logs for unusual HTTP requests, malformed payloads, and unexpected server-side execution behaviour. Tie those signals to incident response triggers that also include secret rotation and session invalidation where compromise is suspected.
• Reduce public reachability during remediation Temporarily restrict internet access to vulnerable application tiers where business requirements allow it, and segment exposed services from privileged backends. This limits attacker scanning opportunities while patching and validation are in progress.

Key takeaways

• This disclosure shows that a framework parsing flaw can become an unauthenticated server execution path before traditional perimeter controls have any chance to help.
• The scale matters because vulnerable versions and public exposure are already common across cloud environments, which raises the odds of opportunistic exploitation.
• The control that changes the outcome is not patching alone but verified dependency inventory, reachability reduction, and identity containment after compromise.

Key terms

• Unsafe Deserialization: Unsafe deserialization happens when software reconstructs objects from untrusted data in a way that can trigger code execution or state corruption. In practice, the risk is not the file or message itself, but the fact that the parser is allowed to invoke behaviour while rebuilding the object.
• Exposure Surface: The set of data, endpoints, and signals that can be observed or queried by an external party. For identity security, the exposure surface is broader than the access surface because publicly visible fields can still be abused for recon and profiling.
• Transitive Dependency: A transitive dependency is a package pulled in indirectly by another package rather than installed explicitly by a team. These nested components matter because a vulnerable library can enter production through frameworks, plugins, or build tools that engineers did not directly choose.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

What's in the full article

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

• Exact vulnerable package and framework version ranges across React, Next.js, and embedded toolchains.
• Step-by-step remediation guidance for verifying upgrades with npm list and checking indirect dependencies.
• Monitoring guidance for identifying exploit attempts in application logs and dependency alerts.
• StepSecurity's cooldown-check handling for newly patched versions, including approval workflow considerations.

👉 StepSecurity's full post covers affected versions, exposure checks, and immediate remediation 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 practitioners connect application compromise scenarios to identity risk and containment decisions.