CVE-2025-55182 shows how RSC deserialization becomes RCE

At a glance

What this is: CVE-2025-55182 is a critical React Server Components flaw that lets a malformed request move from deserialization into server-side code execution.

Why it matters: It matters because default-vulnerable application stacks can expose high-impact execution paths even when no obvious misconfiguration is present, forcing IAM, appsec, and platform teams to tighten trust boundaries.

By the numbers:

• The vulnerability is rated CVSS 10.0 and is unauthenticated.
• The flaw affects React versions 19.0, 19.1.0, 19.1.1, and 19.2.0.
• Next.js versions 14.3.0-canary through 16.x are also affected.
• Patched Next.js releases include 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.

Context

React Server Components let client requests invoke server-side logic through a protocol boundary, which means the security model depends on strict validation of payload structure before any privileged execution happens. CVE-2025-55182 shows what happens when that boundary is too permissive: malformed input can be deserialised into code execution.

For IAM and application security teams, the key issue is not only patching a framework flaw. It is recognising that trusted server execution paths can be reached through ordinary application traffic, so request validation, deployment inventory, and runtime detection all become part of identity-adjacent governance for application workloads.

Key questions

Q: What fails first when React Server Components are vulnerable to deserialisation attacks?

A: The first failure is the trust boundary between client-controlled payloads and server execution. When a framework turns structured input into privileged logic before validating object shape, malformed requests can become code execution paths. In practice, the failure is not only technical. It is a governance gap where parsing, runtime privilege, and exposure inventory are treated as separate problems instead of one attack surface.

Q: Why does unauthenticated RCE in a web framework matter beyond the application team?

A: Because a compromised web process often becomes the starting point for broader compromise. Attackers can use it to read secrets, abuse service identities, spawn child processes, and pivot into connected systems. That means appsec, IAM, and platform teams all own part of the response. The risk is not confined to code correctness. It reaches workload trust and downstream access control.

Q: What signs show that a React exploitation attempt may already be under way?

A: Look for exploit-shaped HTTP requests, unusual headers tied to React Server Components, unexpected command execution on the server and file writes to temporary directories. Those signals indicate the issue has moved from vulnerability discovery to active exploitation and require host-level investigation as well as patching.

Q: What should teams do when a public framework vulnerability affects default deployments?

A: Teams should prioritise containment before everything else: patch the affected packages, restrict public access where possible, and reduce the runtime privileges of the impacted workload. Then validate the full SBOM and monitor for exploitation traffic. Default-deployment exposure means the blast radius may be wider than expected, so remediation needs both code and identity controls.

Technical breakdown

How React Server Components deserialise client payloads

React Server Components use a client-to-server exchange that turns HTTP requests into server-side function calls. That design is powerful, but it also means the server must treat inbound payloads as untrusted until structural checks succeed. In CVE-2025-55182, the flaw sits in the react-server package's handling of the Flight protocol, where malformed JSON-like input can reach deserialisation logic before validation stops it. Once the server accepts attacker-shaped structure, the code path can diverge into privileged execution. The security lesson is that transport authenticity is not the same as object safety.

Practical implication: validate every server-function payload before deserialisation reaches execution context.

Why prototype pollution matters in server action endpoints

Prototype pollution becomes dangerous when application code interprets keys such as __proto__, constructor, or prototype as part of a nested object tree. In this case, the attacker does not need prior access. They only need a crafted POST request that causes the server to process attacker-controlled structure in a way that alters runtime behaviour. For frameworks that expose server actions or server function routes, that means the attack surface includes any endpoint that accepts structured JSON and forwards it into privileged logic. This is a parser boundary problem, not just a bug in one route.

Practical implication: inspect server-action routes for unsafe object handling and reject suspicious structural keys.

Why default-vulnerable deployments change the patching priority

A default-vulnerable configuration removes one of the most common assumptions teams make about exploitability, namely that only unusual setups are at risk. Here, standard deployments using affected React or Next.js versions can be attacked without special misconfiguration. That broadens the operational problem from a code fix to an estate-wide exposure question: which apps use React Server Components, which frameworks bundle react-server, and which endpoints are reachable from the internet. In practice, the vulnerability turns application inventory into a security control, because untracked use equals unmeasured exposure.

Practical implication: inventory all RSC-enabled applications and treat missing ownership as an exposure gap.

Threat narrative

Attacker objective: The attacker aims to gain arbitrary code execution on the application server and use that foothold for deeper compromise.

1. Entry occurs through a specially crafted unauthenticated HTTP POST to a React Server Function endpoint such as /_next/server/endpoint or /react-server-function.
2. Credential access is not required because the attacker abuses deserialisation logic directly, using malformed JSON fields to influence server execution flow.
3. Escalation follows when the server interprets the payload and executes attacker-controlled JavaScript with application privileges.
4. Impact is remote code execution on the web server, with possible lateral movement, process spawning, and outbound connection activity from the compromised application host.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

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

RSC deserialisation trust is the core failure mode here: the server assumed that structured client input could be translated into executable server logic before full validation. That assumption breaks the moment request shape becomes an execution primitive. In practical terms, the control gap is not just a missing patch, but a missing trust boundary between client data and privileged runtime behaviour.

Application frameworks increasingly create identity-adjacent risk even when the subject is not IAM: once a web process can execute code from malformed input, the affected service becomes a high-value identity boundary for workload access, service accounts, and downstream secrets. That matters to NHI governance because compromised web tiers often become the launch point for credential theft and environment pivoting. The practitioner lesson is to treat framework-driven execution paths as part of identity-controlled attack surface.

Default-vulnerable releases collapse the value of configuration-only security thinking: teams cannot assume a safe baseline just because no custom hardening has been bypassed. When a mainstream framework version is exploitable out of the box, inventory, version management, and compensating detection become primary controls. Practitioners should treat framework version exposure as a governance issue, not a developer convenience problem.

Deserialisation bugs are a repeatable pattern, not an isolated React event: the article points to a broader class of failures where complex request parsing meets privileged execution context. That pattern appears across modern web stacks whenever client-controlled objects are turned into server actions too early. The security takeaway is to prioritise parser hardening, route inventory, and runtime monitoring wherever request data can shape server behaviour.

Abstract Security's disclosure is a reminder that application-layer RCE often precedes identity compromise: once an attacker controls the web process, secret access, service account abuse, and lateral movement become realistic next steps. That makes the fix more than a vulnerability ticket. It is a boundary re-check for how application workloads inherit trust, privileges, and network reach.

What this signals

RSC deserialisation risk is now an application governance issue, not a niche framework bug: when client input can influence server execution, inventory and patch discipline become part of the control plane. Teams should assume that any internet-facing React Server Components deployment needs the same scrutiny they apply to privileged back-end services.

Workload trust expands once a web process can execute attacker-shaped input: the practical blast radius includes service credentials, secrets, and downstream systems reachable from the application host. That makes containment, segmentation, and runtime telemetry essential for programmes that already use NHI or service-account governance.

Abstract Security's disclosure sharpens a named concept we should track: server-deserialisation trust collapse is the point where a parser boundary becomes an execution boundary. When that happens, the right control question is not whether a route is publicly documented, but whether it can be coerced into privileged code paths.

For practitioners

• Patch affected React and Next.js versions immediately Move React to 19.0.1, 19.1.2, or 19.2.1 and upgrade Next.js to the patched release that matches your current branch. Treat this as the only definitive mitigation for exposed RSC deployments.
• Inventory every RSC-enabled application and endpoint Identify all services using React Server Components, React Server Functions, or bundled react-server implementations, including framework plugins and preview builds. Missing inventory means missing exposure.
• Monitor for prototype pollution request patterns Add alerts for POST requests to server-function routes that contain __proto__, constructor, or prototype keys, and review malformed JSON that returns unexpected 200 OK responses.
• Hunt for post-exploitation server behaviour Look for unexpected child processes, new files in web directories, unusual outbound connections, and lateral movement attempts from Node.js or web server processes.
• Tighten temporary containment on unpatched applications Segment vulnerable systems, reduce internet exposure where possible, and prepare isolation and forensic collection steps before exploitation is confirmed.

Key takeaways

• CVE-2025-55182 shows that React Server Components can turn malformed requests into remote code execution when the server trusts payload structure too early.
• The article's evidence points to a default-exploitable attack surface, with prototype pollution-style payloads and post-exploitation process anomalies as key warning signs.
• The immediate control priority is patching, followed by inventory, telemetry, and containment for any application that exposes React Server Function behaviour.

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.
• Insecure deserialisation: Insecure deserialisation is a flaw where software rebuilds objects from incoming data without tightly controlling what can be instantiated. In platform software, it can turn a management interface into a code execution path when hostile payloads are accepted from a trusted channel.
• Prototype Pollution: Prototype pollution is a JavaScript bug where attacker-controlled keys modify Object.prototype or another shared prototype. That makes the injected property visible to many objects that were never directly touched by the attacker. In security terms, it creates hidden state that later code may treat as trusted configuration.
• Server function endpoint: An HTTP route that forwards client requests to privileged server-side logic. These endpoints are sensitive because they accept user input and can directly influence server execution, so they require strict input validation, logging, and tight process-level access controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect application trust to identity control. It is useful when your programme has to govern privileged service paths, not just human access.