Critical React and Next.js RCE exposes runtime deserialization risk

At a glance

What this is: This is a security research post on a critical React and Next.js remote code execution flaw that turns attacker-controlled RSC deserialization into server-side code execution.

Why it matters: It matters because application and identity teams must verify which runtime components are actually exposed, not just which ones exist in source or build metadata, across modern NHI and platform estates.

By the numbers:

• A critical 10.0 CVSS remote code execution (RCE) vulnerability was disclosed on December 3, 2025 in React Server Components (RSC) and Next.js.
• Next.js 15.x and 16.x are affected, while patched releases include 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.

👉 Read Oligo Security's analysis of the React and Next.js RCE vulnerability

Context

React Server Components move structured data and server function calls between client and server, which means deserialization becomes a security boundary rather than a pure parsing step. In this case, a flaw in handling attacker-controlled RSC payloads allows code execution before authentication checks, so the primary keyword here is React and Next.js RCE vulnerability.

That matters for application teams because framework-level execution paths now behave like privileged infrastructure, even when the underlying app looks ordinary. For IAM and security architects, the issue is less about a single bug and more about whether runtime exposure, not repository presence, governs response priority.

Next.js inherits the same weakness through its App Router and server-side transformations, so teams using bundled RSC implementations need to treat framework defaults as production attack surface. The article’s starting position is typical of modern web estates, where dependency sprawl and runtime opacity make zero-day response slower than the exploit window.

Key questions

Q: How should security teams respond when a framework RCE affects production applications?

A: Start by identifying which deployed services actually execute the vulnerable code path, then patch only the runtime instances that are confirmed active. For high-severity framework RCE, runtime evidence should drive prioritisation because repository scans alone cannot prove exposure. If public endpoints are reachable, isolate them until the patched version is in place.

Q: Why do package inventories often miss the real risk in framework vulnerabilities?

A: Package inventories show presence, not execution. A dependency can exist in a repository or build output without being active in production, while a loaded runtime component can be exploitable even when the broader application looks compliant. Teams need runtime telemetry to decide whether a vulnerability is truly reachable.

Q: What should teams do when a vulnerability exists before authentication checks?

A: Treat the affected endpoint as a pre-authentication execution surface and reduce exposure immediately. That usually means tightening network reachability, verifying patched versions, and checking whether the deserialization path can be triggered remotely. The key is to assume any public endpoint with the vulnerable parser is part of the attack surface.

Q: How do you know if zero-day response is actually reducing exposure?

A: You know it is working when the set of running vulnerable components shrinks, exploit attempts are visible in runtime telemetry, and patched versions replace active instances in production. The goal is not just fewer findings in a scanner. It is a measurable reduction in live, reachable execution paths.

Technical breakdown

How RSC deserialization becomes server-side execution

React Server Components use the Flight transport format to move component data and server function calls between client and server. The flaw sits in deserializing attacker-supplied payloads into execution paths that reach server-side code, which means the parsing step itself becomes an execution primitive. Because this happens before authentication enforcement, the request does not need a valid session. In practical terms, the vulnerability collapses the normal separation between untrusted input handling and privileged server logic.

Practical implication: verify whether public-facing endpoints accept RSC payloads and block exposure where the vulnerable deserialization path is reachable.

Why Next.js inherits the same RCE condition

Next.js implements the same React Server Components protocol, so the weakness is not isolated to React libraries in the abstract. Its App Router architecture relies on server actions and server-side transformations that pass through the same deserialization logic, which is why patched framework versions matter as much as application code. The operational risk is that a standard deployment can be exposed without custom configuration, making framework defaults part of the security boundary.

Practical implication: map framework version and router mode together, then patch or downgrade any deployment that still loads the vulnerable runtime path.

Why static scanning misses exploitable runtime state

Traditional application security tools often report package presence, repository dependencies, or build artifacts, but those signals do not prove what is actually running in production. This is a runtime exposure problem: a component can exist in the codebase and still be harmless if it is not loaded, or conversely be exploitable only when the vulnerable execution path is active. For zero-days, the key question is not just whether the package exists, but whether the process is actually executing the vulnerable code path.

Practical implication: use runtime inspection to confirm active execution before prioritising remediation work across large dependency sets.

Threat narrative

Attacker objective: The attacker aims to achieve unauthenticated server compromise and use that foothold to move into backend and cloud systems.

1. Entry: The attacker sends a crafted HTTP request to a public Server Function endpoint that accepts a malicious RSC payload.
2. Credential_harvested: No credential is required because the flaw executes before authentication, so the request itself becomes the trigger for server-side code execution.
3. Escalation: The payload deserializes into arbitrary code execution on the server, enabling command execution and access to environment variables.
4. Impact: The attacker can pivot deeper into cloud and backend systems, turning a single request into broader application compromise.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

Runtime deserialization exposure is now an application identity problem, not just an AppSec bug. When framework internals can execute attacker-controlled input before authentication, the security boundary has shifted from login control to runtime trust. That means the control question is no longer only whether code is patched, but whether the live process is allowed to execute untrusted payloads at all. Practitioners should treat exposed RSC paths as privileged execution surfaces.

Static inventory does not define exploitable state in modern JavaScript estates. Dependency lists, SBOMs, and build metadata tell you what is present, not what is actually live. This vulnerability shows why runtime observability has to sit next to vulnerability management, especially when the same package can be bundled, loaded, or bypassed depending on deployment path. The implication is straightforward: exposure must be measured from execution, not assumption.

Framework defaults are now part of the zero-day blast radius. A standard create-next-app style deployment can inherit a server-side execution flaw without any bespoke misconfiguration, which means the attack surface scales with adoption. The broader lesson for the field is that framework reach and runtime privilege are increasingly intertwined, so governance teams need to understand where default architecture creates implicit trust. Practitioners should review framework defaults as if they were control decisions.

Identity blast radius: the effective security boundary is the set of runtime paths an attacker can convert into execution. In this case, the named concept is not secret leakage or package sprawl, but the gap between installed dependencies and executed code paths. That boundary defines how quickly a zero-day becomes a business incident, because exposure is only real when the vulnerable path is live in production. The implication is to govern runtime exposure as a first-class risk domain.

Application runtimes are becoming part of non-human identity governance by proxy. Server-side components, service tokens, and backend execution contexts all behave like non-human actors once they are reachable through attacker-controlled input. This widens the governance lens beyond code review and patching to include runtime attestation, execution visibility, and operational containment. Practitioners should align AppSec and identity teams on who can execute, not just who can authenticate.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
• For a broader control baseline, The 52 NHI breaches Report shows how recurring identity failures map to real-world attack chains.

What this signals

Identity blast radius: framework RCEs now behave like identity events because they create privileged execution contexts that attackers can reach without credentials. For programme owners, the practical shift is to measure exposure by active runtime paths, not by package presence or repo inventory. That is a stronger fit with zero trust than static vulnerability counts.

The near-term signal for security teams is that runtime inspection will become a standard control expectation around modern JavaScript frameworks. When a vulnerability executes before authentication, the programme question is not only whether the code is patched, but whether the running process can be observed well enough to prove exposure has been removed.

Teams that already align application security with identity governance will move faster here because they can separate installed risk from live risk. The same discipline used to govern non-human identities applies to framework-driven execution paths: know what is active, know what is privileged, and know what can be reached from the outside.

For practitioners

• Patch every affected React and Next.js runtime Move React Server Components packages to 19.0.1, 19.1.2, or 19.2.1, and upgrade Next.js to the patched release that matches your branch. Confirm the patched version is the one actually deployed, not just the one merged in source.
• Verify active execution paths in production Check whether vulnerable components are loaded and running in production, then rank remediation only for paths that are truly executed. Use runtime inspection to distinguish installed packages from executed components before allocating patch windows.
• Block or isolate exposed Server Function endpoints Reduce immediate exposure by restricting public access to endpoints that accept RSC payloads, especially where authentication is not yet enforced. Treat those endpoints as server-side execution surfaces until version status is confirmed.
• Use runtime evidence to triage zero-day response Correlate exploit attempts, deserialization traces, and live process behaviour instead of relying on build scans alone. This shortens decision time and helps prevent over-remediating components that are present but not executing.

Key takeaways

• A React Server Components deserialization flaw can turn an unauthenticated HTTP request into server-side code execution before authentication checks run.
• The practical exposure is broader than the CVE line item because Next.js inherits the same runtime weakness through its App Router and server-side transformations.
• The most effective response is runtime-based exposure validation, because static scans cannot prove what is actually executing in production.

Key terms

• Runtime exposure: Runtime exposure is the set of application paths that are actually live and reachable in production, not just present in code or build artifacts. It matters because exploitability depends on execution, and a dormant dependency may be harmless while an active component can be immediately dangerous.
• Pre-authentication execution surface: A pre-authentication execution surface is any endpoint or parser that can be triggered before a user proves identity. In practice, it means the attacker can reach privileged logic without credentials, so authentication controls no longer serve as the first security boundary.
• Deserialization vulnerability: A deserialization vulnerability occurs when untrusted data is converted into structured objects or commands in a way that changes program behaviour. In security terms, the parser becomes part of the attack surface, especially when attacker-controlled input can reach server-side execution paths.
• Identity blast radius: Identity blast radius is the amount of privileged execution an attacker can reach once they compromise or trigger a trust boundary. For modern application runtimes, it describes how far a single exploit can move through server processes, tokens, and backend access before containment catches up.

Deepen your knowledge

React and Next.js runtime exposure is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for modern application runtimes and privileged execution paths, it is worth exploring.

This post draws on content published by Oligo Security: Critical React and Next.js RCE Vulnerability (CVE-2025-55182 & CVE-2025-66478): What You Need To Know. Read the original.