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

At a glance

What this is: This is a critical RCE analysis showing that unsafe deserialization in the React Server Components Flight protocol can let one crafted request reach pre-auth code execution on exposed server function endpoints.

Why it matters: It matters because IAM and platform teams need to treat framework-level request handling as an access boundary, especially where app dependencies sit in front of authentication and authorisation controls.

By the numbers:

• 10.0, issue has been rated CVSS 10.0, indicating critical severity.
• React RSC packages 19.0.0, 19.1.0, 19.1.1, and 19.2.0 are affected in the reported flaw.
• Next.js stable 15.x and 16.x are affected when App Router and RSC features are enabled.

👉 Read Apiiro's analysis of the React RSC and Next.js pre-auth RCE flaw

Context

Unsafe deserialization in modern web application frameworks is a governance problem as much as a software defect. When server-side request handling trusts attacker-controlled payload structure, the application framework itself can become an access boundary failure that sits outside ordinary authentication and authorisation assumptions.

This article sits squarely in application security, but it has an identity angle where exposed endpoints can bypass the controls that normally separate unauthenticated traffic from privileged execution. For IAM and PAM teams, the takeaway is that dependency exposure, runtime request parsing, and authentication boundaries now intersect more tightly than many programme models assume.

Key questions

Q: What breaks when an application framework deserialises attacker-controlled payloads before authentication?

A: The main failure is that untrusted input can reach privileged server logic before access controls do their job. That creates a pre-auth execution path, which means attackers may trigger code execution without valid credentials. Teams should treat framework parsing as part of the trust boundary, then patch affected components and reduce exposure until the unsafe path is removed.

Q: Why do framework-level RCE flaws matter more when apps are internet-facing?

A: Internet exposure turns a code-level flaw into an immediate entry point for attackers. If the vulnerable endpoint is reachable from the public internet, a single request can be enough to test or exploit the issue at scale. Prioritise public services first, then map the same dependency across internal environments that may share the vulnerable build.

Q: How can security teams tell whether an application dependency is actually reachable?

A: They need service-level inventory, not just a package scan. The useful signal is which deployed applications, routes, and environments embed the vulnerable dependency and whether those services accept traffic from outside the trusted network. That view lets teams separate dormant risk from exploitable exposure and focus response where it matters most.

Q: Who is accountable when a critical framework flaw is exposed in production?

A: Accountability usually spans application owners, platform engineering, and security operations. The application team owns patching and code changes, platform teams manage deployment and exposure, and security teams coordinate triage and containment. Clear ownership matters because critical RCEs require rapid decisions on upgrades, temporary restrictions, and recovery validation.

Technical breakdown

Why unsafe deserialization in RSC creates an execution boundary failure

React Server Components split rendering between client and server by serialising component trees and server function calls over the Flight protocol. The risk appears when server code deserialises attacker-controlled data before authentication or routing has fully constrained the request. If the parser accepts malformed but valid-looking payloads, the attacker can influence internal object shapes and execution paths that were meant to stay private to the server runtime. That is why deserialization bugs in framework infrastructure are often more dangerous than ordinary input validation failures.

Practical implication: treat RSC deserialisation as a security boundary and patch affected frameworks before relying on perimeter controls.

How App Router exposure expands the blast radius in Next.js

Next.js integrates RSC into App Router deployments, which means the vulnerable parsing path may be embedded across many services, not just one codebase. The real exposure question is therefore not only versioning but deployment context: which internet-facing apps use affected packages, which environments still run canary builds, and which services process sensitive data. In practice, dependency risk becomes an application inventory problem, because the same vulnerable library may sit inside multiple build artefacts and delivery pipelines.

Practical implication: map vulnerable package versions to running services and prioritise internet-facing workloads first.

Why temporary protections matter when patching lags

When a critical framework flaw cannot be patched immediately, compensating controls need to focus on request content and endpoint exposure. Web application firewall rules can sometimes block malformed or high-entropy payloads, while network restrictions reduce who can reach risky services. Monitoring for spikes in server function errors also matters because exploit attempts often produce distinctive failure patterns before successful execution. These measures do not fix the defect, but they can narrow the attack window while upgrades are being deployed across environments.

Practical implication: pair emergency upgrades with WAF rules, endpoint monitoring, and temporary access restriction where business constraints allow.

Threat narrative

Attacker objective: The attacker aims to run arbitrary code on internet-facing application servers without valid credentials, then use that foothold for compromise or data theft.

1. Entry occurs through a single crafted HTTP request sent to an exposed RSC or server function endpoint.
2. Escalation happens when unsafe deserialization lets attacker-controlled payloads reach privileged server execution paths before normal authentication checks.
3. Impact is pre-auth arbitrary code execution on the server, which can lead to application compromise and downstream data exposure.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

This is an application boundary failure, not just a vulnerability count. The important issue is that framework internals accepted attacker-controlled structure before normal trust checks could intervene. That means inventory, exposure mapping, and patch governance matter as much as code-level remediation. Practitioners should treat framework parsing paths as part of the control plane for application access.

Pre-auth RCE collapses the assumption that authentication sits before execution. In this flaw, the request reaches privileged server logic without needing valid credentials, which breaks a common governance model used by both application security and identity teams. The lesson for IAM programmes is that access control is only meaningful if framework execution paths preserve the order of controls. Practitioners should verify where authentication actually begins in the request lifecycle.

Dependency-to-exposure mapping is now a core security control. The article shows that knowing a library version is not enough if teams cannot identify which services, routes, and environments embed it. This is where application security intersects with identity governance: the same discipline used to track human and non-human access should also track which workloads can execute sensitive code paths. Practitioners should prioritise runtime visibility over static package lists.

Emergency controls need to be operational, not theoretical. WAF rules, network restriction, and error monitoring can reduce exposure while patches roll out, but only if teams can deploy them quickly across the right services. This is a strong case for pre-approved containment playbooks in platform and SOC operations. Practitioners should rehearse those controls before the next critical framework flaw lands.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That same guide shows 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which is why runtime exposure and secret hygiene need to move together.

What this signals

Framework vulnerabilities now sit on the same escalation path as weak access governance because they can bypass the normal order of trust before any human or machine identity control can intervene. Teams that already track service accounts, secrets, and workload access should extend that discipline to framework inventory and endpoint reachability, using the MITRE ATT&CK Enterprise Matrix and NIST SP 800-53 Rev 5 Security and Privacy Controls as common reference points.

Execution-path visibility: the next maturity step is to know not just what dependencies exist, but which deployed services can execute them from the public edge. That creates a practical bridge between application security and NHI governance, because the same operational rigor used for non-human identity inventory now needs to cover framework reachability and runtime exposure.

If your programme still treats dependency scanning as a build-time task, this incident is the reminder that exposure is a runtime question. Security teams should pre-stage containment playbooks, tie them to change control, and make emergency access restriction a documented response option before the next critical RCE appears.

For practitioners

• Patch affected React and Next.js versions immediately Move affected React RSC packages to the patched releases and upgrade Next.js workloads using App Router or RSC features to the vendor-provided fixed versions. Use emergency change procedures for internet-facing services first.
• Inventory every RSC-enabled service and route Build a dependency-to-service map for react-server-dom-* packages, then identify which environments are exposed externally and which handle sensitive data. That map should drive remediation sequencing, not package lists alone.
• Apply temporary request filtering and exposure reduction Add WAF rules for suspicious RSC Flight payloads, monitor for high-entropy serialized frames and server function errors, and restrict network access to the highest-risk applications while patching is in progress.
• Tie framework risk to containment runbooks Document who can approve emergency restriction of high-risk applications, how telemetry is triaged, and what evidence is required before restoring service. That reduces delay when the next pre-auth RCE appears.

Key takeaways

• React Server Components turned a deserialization mistake into a pre-auth server execution path, which is why the control failure is architectural rather than cosmetic.
• The exposed blast radius depends on where affected packages run, so service-level inventory and internet exposure are the first triage priorities.
• Patching is necessary but not sufficient, because temporary request filtering, monitoring, and containment playbooks can narrow the attack window while upgrades 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 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.
• Pre-auth RCE: Remote code execution that occurs before a system has authenticated the requester. This is especially dangerous because the attacker does not need valid credentials, so the vulnerability can often be triggered from the public internet with a single request if the endpoint is reachable.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full analysis

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

• Exact patched versions for React RSC packages and Next.js release lines affected by the flaw
• Inventory and prioritisation workflow for finding vulnerable react-server-dom-* dependencies across repos and services
• Temporary WAF and monitoring guidance for malformed RSC Flight payloads during emergency remediation
• Suggested workflow steps for raising and tracking remediation work items across teams

👉 Apiiro's full post covers affected versions, exposure mapping, and mitigation steps for the RSC Flight protocol flaw.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management with a practical focus on lifecycle control. It helps security practitioners connect identity governance to the runtime risks that modern application stacks create.