React RSC deserialization flaws expose a critical pre-auth RCE path

At a glance

What this is: A critical unsafe-deserialization flaw in React Server Components and Next.js can turn exposed RSC endpoints into pre-auth remote code execution paths.

Why it matters: It matters because teams running React 19 and Next.js App Router must treat dependency exposure, internet-facing endpoints, and temporary compensating controls as urgent governance issues, not just patch-management tasks.

Context

React Server Components move part of rendering and data loading onto the server, using serialized payloads over the RSC Flight protocol. That design creates a governance problem when deserialization trusts attacker-controlled input before routing or authentication has a chance to intervene, because exposed application endpoints become execution surfaces.

For IAM and application security teams, the important boundary is not just who logs in, but what server-side code accepts before identity checks occur. In this case, the security issue is not traditional user authentication failure; it is pre-auth execution through framework internals, which expands the blast radius of an otherwise ordinary web stack.

The article's starting position is typical for modern framework exposure: a convenience feature becomes critical once it is reachable from the internet and embedded across multiple products and deployment patterns.

Key questions

Q: What fails when React Server Components are exposed before authentication?

A: The failure is at the framework trust boundary, not the login layer. If the RSC deserialization step accepts attacker-controlled Flight payloads before routing or authentication, a single crafted request can reach privileged execution paths. Security teams should treat that boundary as part of their attack surface and validate every exposed endpoint that processes it.

Q: Why does pre-auth RCE in a framework like RSC matter so much?

A: Because the attacker does not need credentials, session theft, or a second-stage payload to get value from the exploit. Once deserialization reaches code execution before authentication, the blast radius extends to the application runtime and any connected resources. That changes the priority from user-account compromise to internet-facing service containment.

Q: What signals show that an RSC endpoint may be under active probing?

A: Look for malformed or unusually high-entropy serialized frames, repeated requests to RSC routes, and spikes in server function invocation errors. Those indicators suggest an attacker is testing the deserialization path rather than normal application behaviour. Teams should correlate them with deployment inventory so they can focus on reachable services first.

Q: How should security teams coordinate response when a framework vulnerability hits production?

A: They need a clear ownership model for inventory, emergency patching, WAF mitigation and validation of closure across all affected applications. Without that assignment, teams can assume someone else has remediated the issue, which leaves exposed frameworks active long after disclosure.

Technical breakdown

How RSC Flight deserialization becomes an execution path

React Server Components serialize component boundaries, server function references, and data into the Flight protocol so the server can reconstruct the UI tree. The vulnerability arises when that reconstruction trusts attacker-controlled structure too much. If the parser accepts malformed but still syntactically valid payloads, it can influence internal object shapes and identifiers and push execution into privileged code paths. Because this happens before application routing and authentication, the attack surface is not the login layer but the framework transport itself.

Practical implication: Treat the RSC transport as a security boundary and validate every exposed endpoint that consumes Flight payloads.

Why App Router exposure changes the risk profile

Next.js App Router embeds RSC handling into common production architectures, which means the vulnerable deserialization logic may be present wherever RSC features are enabled. That matters because the same flaw can surface across stable releases, canary builds, and other frameworks that bundle react-server-dom implementations. In practice, the exposure question is no longer whether a framework version is listed as affected, but whether a given service exposes an endpoint that accepts RSC traffic from outside trusted boundaries.

Practical implication: Map framework versions to deployed services so you can separate theoretical vulnerability from reachable attack surface.

Defence-in-depth while patches are rolling out

When patching cannot happen immediately, compensating controls have to sit at the endpoint layer. Web application firewall rules can look for malformed or unusually high-entropy serialized frames, while network restrictions can reduce access to high-risk applications. Monitoring should focus on request patterns that hit RSC routes and on server function invocation errors, because those are the most likely early signals that exploit attempts are being tested against exposed endpoints.

Practical implication: Use temporary endpoint controls and monitoring to narrow the window between public exposure and patched deployment.

Threat narrative

Attacker objective: The attacker wants server-side code execution against an internet-facing React or Next.js deployment without needing valid credentials.

1. Entry occurs when an attacker sends a single crafted HTTP request to an exposed RSC or Server Function endpoint.
2. Credential access is bypassed because the vulnerable deserialization logic runs before routing and authentication, so no valid login is required.
3. Impact is pre-auth arbitrary code execution on the server under default configurations, with the potential to compromise the affected application and its runtime.

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

Framework deserialization is now a trust boundary problem, not just a code-quality problem. The core failure here is that the server accepted attacker-shaped payloads before it had established trust. That is a governance issue because application frameworks increasingly hide privileged logic behind transport abstractions that security teams do not review as directly as auth flows. The practical conclusion is that exposure mapping must include framework internals, not just application routes.

RSC creates a new class of pre-auth execution risk for modern web stacks. When server component orchestration and routing are separated, the earliest parse step can become the most dangerous one. That means conventional perimeter thinking is too late if the endpoint itself is already a deserialization sink. Practitioners should treat RSC endpoints as high-value assets requiring explicit inventory, hardening, and rapid patch governance.

Exposure visibility is the control gap that determines blast radius. An organisation may know it uses React or Next.js, but still fail to know where vulnerable react-server-dom packages are deployed and which services are internet-facing. That gap turns a critical CVE into an enterprise-wide remediation race. The named concept here is framework execution exposure: the point where application framework internals become externally reachable execution paths.

Temporary compensating controls matter when the patch window is not zero. A WAF rule, access restriction, or network segmentation layer is not a substitute for remediation, but it can reduce exploitability while teams sort out version scope and rollout sequencing. This is especially important when a single HTTP request can reach the vulnerable path. The practitioner takeaway is to pair patching with containment, not to wait for one before doing the other.

Dependency intelligence now has governance value at application runtime. Vulnerability management is not enough if the organisation cannot map a package version to the services that actually expose it. This incident reinforces that modern software risk is about deployment context, not just library pedigree. Teams need to know where vulnerable components are live, reachable, and business critical before they can prioritise remediation with confidence.

What this signals

Framework execution exposure: the real problem is not just that a library is vulnerable, but that its internal deserialization path is reachable from the internet before normal access controls can intervene. That shifts application security from patch tracking to exposure governance, because the same package version can be benign in one service and critical in another.

For practitioners, the next control question is whether dependency inventories are mapped to deployed entry points, not just repositories. Without that linkage, patch priority is easy to misjudge and temporary containment is hard to target. The immediate programme implication is to treat framework internals as part of asset inventory, especially where routing and server execution are tightly coupled.

For practitioners

• Inventory exposed RSC and App Router endpoints Identify every service that uses react-server-dom-* or Next.js App Router features, then tag the internet-facing ones first so exposure is visible before remediation starts.
• Patch to the known safe versions Move React RSC packages to 19.0.1, 19.1.2, or 19.2.1 and upgrade Next.js to the patched 15.x or 16.0.7 branches as soon as release testing allows.
• Add temporary endpoint protections Use WAF rules, access restrictions, and network controls to block malformed Flight payloads and limit reach to high-risk applications until patched versions are in place.
• Monitor for exploitation signals Watch for unexpected or high-entropy serialized frames and for sudden spikes in server function invocation errors, because those patterns can indicate probing or exploit attempts.

Key takeaways

• The flaw turns RSC deserialization into a pre-auth execution path, which means the trust boundary sits earlier than many teams expect.
• The practical risk depends on where vulnerable packages are deployed and whether those services are reachable from the internet.
• Patching is necessary, but containment and exposure mapping are what shrink the window while fixes roll out.

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.
• 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.
• 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.
• 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.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.