Critical React and Next.js RCE exposes runtime deserialization risk

At a glance

What this is: This is a security analysis of a critical React Server Components and Next.js RCE that turns attacker-controlled deserialization into server-side execution.

Why it matters: It matters because teams need to verify what is actually executed in production, not just what appears in source, package, or build inventory.

Context

React Server Components add a server-side serialization layer that moves component data and server function calls between browser and backend. In this case, the security gap is not generic application code injection but unsafe deserialization of attacker-controlled payloads inside that framework boundary, which can convert a single request into server execution.

For IAM and platform teams, the important lesson is that exposure is determined by runtime behaviour, not package presence alone. A framework can be present in inventory and still be non-exploitable if it is not loaded, but the reverse is also true when a vulnerable path is actively executed in production.

Next.js inherits the same underlying RSC protocol logic, so the issue becomes a stack-level governance problem for modern JavaScript estates. The practical question is whether organisations can distinguish installed dependencies from the components actually handling requests in live environments.

Key questions

Q: What breaks when unsafe deserialization exists in a React Server Components implementation?

A: Unsafe deserialization lets attacker-controlled payloads influence server-side processing in ways the framework was not meant to allow. In practice, that can turn a malformed request into code execution on the server. The control failure is especially dangerous because it can be triggered remotely and without authentication, so trusted request assumptions no longer hold.

Q: Why do runtime checks matter more than package inventories for this flaw?

A: Because package inventories show presence, not execution. A vulnerable dependency may sit in a repository or build manifest without being loaded in production, while a different path may actively execute the vulnerable code. Runtime checks answer the only question that matters during a zero-day: is the exploitable path actually live right now?

Q: What signs suggest a framework deserialization flaw is being exploited?

A: Look for unexpected request patterns hitting Server Function endpoints, abnormal deserialization stack traces, and code paths that should not be reachable from public traffic. In practice, exploitation often shows up as unusual server-side behaviour immediately after a crafted request rather than as a traditional authentication event.

Q: What should teams do when a widely used JavaScript framework RCE appears?

A: Treat it as an exposure-verification problem as well as a patching problem. Upgrade to fixed versions, identify which services actually execute the vulnerable framework paths, and isolate public-facing applications first. The priority is to reduce blast radius where the vulnerability is both present and reachable.

Technical breakdown

How React Server Components deserialize attacker-controlled payloads

React Server Components use a serialized transport format called Flight to exchange component data and server function calls. The flaw sits in the deserialization step, where client-supplied data is converted into server-side objects and execution paths. If that conversion trusts the payload structure too much, the application can be made to invoke code paths that were never meant to be reachable from an external request. In this case, the attack does not require authentication because the malformed payload is processed before access control can stop it.

Practical implication: treat framework deserialization paths as execution surfaces and verify which ones are reachable from public endpoints.

Why Next.js inherits the same RSC risk

Next.js implements the same RSC protocol and uses server actions and server-side transformations that depend on the vulnerable React logic. That means the exposure is not limited to one library package in isolation. The real risk is architectural inheritance, where a framework wraps upstream behaviour and passes through the same unsafe parsing and execution sequence. For practitioners, the key issue is whether the application framework exposes any server function endpoint that accepts untrusted RSC payloads.

Practical implication: map framework versions and enabled runtime features together, not as separate inventory checks.

Why static scanning misses runtime deserialization exposure

Static scans can tell you that a vulnerable package exists, but they cannot show whether the vulnerable code path is actually executing in production. Runtime inspection is different because it observes live request handling, stack traces, and execution behaviour inside the process. That distinction matters for zero-days and framework flaws where the existence of a dependency does not equal exploitability. The governance problem is that teams often report installed components while the real security question is which components are operationally active.

Practical implication: confirm runtime execution of vulnerable components before deciding priority and remediation scope.

Threat narrative

Attacker objective: The attacker wants remote code execution on a server running vulnerable React Server Components or Next.js.

1. Entry occurs when an unauthenticated attacker sends a crafted HTTP request to a public Server Function endpoint exposed by RSC or Next.js.
2. Credential access is not the primary mechanism here, because the attack uses unsafe deserialization rather than stolen secrets or authenticated access.
3. Escalation happens when attacker-controlled payloads are translated into server-side execution paths, resulting in arbitrary code execution on the host.
4. Impact is achieved when the attacker runs code on the server and can access environment variables, execute commands, or move deeper into backend systems.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime evidence is the new control plane for framework risk. Static inventory tells teams what is present, but not what is actually executing in production. This vulnerability shows why package presence, build metadata, and repository scans can all overstate or understate exposure. Practitioners need a governance model that privileges live execution evidence when deserialization flaws can be reached through ordinary request paths.

Unsafe deserialization is an application-layer trust failure, not just a patching issue. The control gap is the assumption that serialized input from a client can be turned back into server objects safely once it passes through framework code. That assumption fails when the payload itself becomes the vehicle for server-side execution. The implication is that identity and access controls cannot compensate for an application boundary that treats untrusted data as trusted instructions.

Framework inheritance creates shared blast radius across modern JavaScript estates. When Next.js adopts upstream React Server Components logic, the risk propagates across multiple layers of the same application stack. That means teams should assess exposure by runtime path and framework composition, not by package labels alone. The practical conclusion is that application governance must understand inheritance chains, not just component lists.

Deserialization risk should be treated as a governable runtime condition. A CVSS 10.0 score is useful, but the more important signal is that a single request can reach execution before authentication gates or compensating controls intervene. This is where NIST CSF and secure runtime monitoring matter: they need to show whether the vulnerable path is live, not just whether the dependency exists. The practitioner takeaway is to make runtime reachability part of the security decision, not an afterthought.

Blast-radius control depends on knowing what the framework can reach in production. If the running application can invoke server functions from unauthenticated traffic, the issue is no longer only vulnerability management. It becomes a question of how quickly teams can prove exposure, isolate affected services, and prevent a deserialization flaw from becoming a broader compromise. The operational priority is to reduce uncertainty before the attacker does.

What this signals

Runtime deserialization risk is now a governance issue, not just an AppSec bug. Teams that rely on repository-level inventory will keep misjudging exposure whenever a framework flaw depends on live execution paths. The practical shift is toward runtime reachability as a control objective, because the question is no longer only what was deployed but what can actually be invoked in production.

Framework inheritance multiplies blast radius across modern JavaScript stacks. When upstream logic is reused by a popular application framework, exposure can span many applications at once even if their codebases look different. Practitioners should therefore assess framework composition and request handling paths together, especially where public endpoints can reach server-side deserialization.

For practitioners

• Patch vulnerable React and Next.js versions first Move affected React packages and Next.js deployments to the fixed releases named in the advisory, and prioritise public-facing services that expose Server Components or server actions.
• Verify runtime execution paths before triage Confirm whether vulnerable components are actually loaded and executed in production, because static scans alone cannot prove exploitability for framework deserialization flaws.
• Search for public Server Function endpoints Inventory exposed endpoints that accept RSC payloads, especially where unauthenticated HTTP requests can reach server-side deserialization logic.
• Monitor for deserialization-to-execution behaviour Use runtime telemetry to spot unusual stack traces, payload handling, and server-side execution patterns that indicate active exploitation attempts.

Key takeaways

• This vulnerability shows how unsafe deserialization in framework internals can turn a single request into server-side code execution.
• The important evidence is not just the CVSS 10.0 rating, but the fact that unauthenticated public endpoints may be reachable in production.
• Teams need to verify runtime execution, patch the affected versions, and narrow exposure where framework paths are actually live.

Key terms

• Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.
• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Server Components: Server components are application parts that execute on the backend and can process special payloads sent from client-facing code. If their deserialisation path is weak, a crafted request can trigger unsafe behaviour on the server, turning input parsing into a remote code execution risk.
• Runtime Vulnerability Management: Runtime Vulnerability Management prioritises flaws based on what software actually does in production, not only on static scan results or catalogue entries. It combines execution telemetry, reachability, and exploit signals to determine whether a finding is genuinely actionable in the current environment.

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.