CVE-2025-55182 shows how RSC deserialization becomes RCE

At a glance

What this is: A critical React Server Components deserialization flaw can let a single crafted HTTP request trigger remote code execution in default deployments.

Why it matters: It matters because application-layer trust boundaries affect identity, secrets, and privilege exposure whenever server-side code runs with access to tokens, service accounts, or downstream systems.

By the numbers:

• The vulnerability is rated CVSS 10.0 and affects React 19.0, 19.1.0, 19.1.1, and 19.2.0, as well as multiple Next.js versions.
• Patched Next.js versions include 14.3.0-canary.88, 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.

👉 Read Abstract Security's analysis of CVE-2025-55182 in React Server Components

Context

React Server Components split client and server execution, which improves developer flexibility but also creates a boundary where untrusted input can be processed with server privileges. In this case, the core issue is insecure deserialization in the Flight protocol path, not a misconfiguration by the operator, so standard deployments can be exposed immediately.

For IAM and NHI practitioners, the relevance is straightforward: any web runtime that can reach secrets, tokens, or privileged backend services can turn an application vulnerability into identity compromise. That makes code execution bugs part of access governance, because the blast radius depends on what identities and credentials the affected process can reach.

Key questions

Q: What breaks when React Server Components are exposed to crafted Flight payloads?

A: The server can deserialize attacker-controlled data as if it were legitimate framework state, which can redirect execution flow and trigger remote code execution. In practice, the break is not just a parsing error. It is a collapse of the trust boundary between client-supplied payloads and internal server logic, which can lead to file access, process spawning, or full compromise.

Q: Why do server-side rendering features create more risk for secrets and access control?

A: They place privileged logic behind web endpoints that accept client input, so a parsing flaw can expose the same process that holds tokens, certificates, or cloud credentials. That means the security outcome is determined by what the runtime can reach. Least privilege, secret isolation, and route inventory therefore become access-control controls as much as appsec controls.

Q: How do security teams know whether they are exposed to React Server Components RCE risk?

A: Look for applications running affected React or Next.js versions, any use of Server Functions or custom RSC routes, and evidence that the runtime can reach sensitive secrets or internal APIs. If those conditions exist, treat the application as exposed until patched. Logging and request inspection should focus on malformed JSON and suspicious object keys.

Q: Who is accountable when a framework flaw lets a web runtime reach internal systems?

A: Accountability sits with the teams that own the application, the platform that deploys it, and the security function that governs patching and privilege scope. Framework flaws become operational risk when the organisation cannot prove inventory, version control, and runtime segregation. NIST CSF, access governance, and incident response ownership should align before exploitation occurs.

Technical breakdown

How React Server Components process client payloads

React Server Components move part of application rendering and function execution to the server, then use the Flight protocol to serialize and deserialize data between client and server. Server Functions accept HTTP requests that are translated into server-side calls, which means the server must trust the structure of the incoming payload before acting on it. If validation is incomplete, attacker-controlled JSON can influence execution flow. That is why deserialization bugs in this layer become code execution issues rather than simple parsing errors.

Practical implication: treat every server function endpoint as a privileged input boundary and inspect it like an exposed API.

Why insecure deserialization in the Flight protocol becomes RCE

The flaw described here is a logical insecure deserialization problem. The server decodes malformed payloads, fails structural validation, and then continues along execution paths that were never intended for attacker-controlled data. In practice, that can let a crafted object shape, including prototype pollution patterns, alter server behaviour and reach arbitrary JavaScript execution. Because the vulnerable code runs on the server, the impact is determined by the permissions of the hosting process, not the browser session.

Practical implication: constrain server runtime privileges so code execution does not automatically mean broad infrastructure access.

Why default-vulnerable framework features expand the attack surface

The article notes that applications using React Server Components may be vulnerable even without explicit custom endpoints, because the feature itself introduces server-side handling paths. That matters because security teams often inventory only externally obvious APIs and miss framework-mediated routes such as /_next/server/endpoint or custom server actions. When default behaviour is exploitable, the attack surface is architectural rather than configuration-driven, which means version management and feature inventory become core controls.

Practical implication: maintain a framework feature inventory and map it to exposed routes, patch status, and process privileges.

Threat narrative

Attacker objective: The attacker aims to gain arbitrary code execution inside the web application runtime and use that foothold to reach secrets, downstream services, or internal systems.

1. Entry occurs when an attacker sends a specially crafted HTTP POST request to a React Server Function endpoint or equivalent RSC route.
2. Escalation follows when the malformed JSON payload bypasses structural checks and the server deserializes attacker-controlled data into privileged execution logic.
3. Impact occurs when the web process runs arbitrary JavaScript with server privileges, enabling process spawning, outbound connections, lateral movement, and potential secret access.

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.
• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

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

NHI Mgmt Group analysis

Server-side framework trust is now an identity boundary. When a web framework can deserialize client data into server execution, the issue is no longer just application security. The runtime may hold tokens, certificates, service credentials, and access to internal APIs, so exploitation becomes an identity problem as soon as the process can act on behalf of a trusted workload. Practitioners should treat privileged application runtimes as governed identities, not anonymous code containers.

Default-vulnerable features create governance debt faster than misconfigurations do. This flaw matters because it exists in common deployment patterns, not only in unusual edge cases. That means inventory accuracy, version tracking, and feature awareness matter as much as patching speed. Runtime deserialization boundary: once client-controlled input reaches a server function without strict validation, the boundary between request handling and code execution collapses. Teams should map where that boundary exists in their own applications.

The real blast radius is whatever the compromised process can reach. A successful RCE in a web application becomes far more serious if the process can read environment variables, call cloud metadata services, or invoke internal IAM-integrated systems. That is why privilege scoping, secret isolation, and service account separation are part of application resilience, not just infrastructure hygiene. The control question is not only whether the bug exists, but what the runtime can touch if it is exploited.

This is a reminder that appsec and identity governance overlap at the process level. React Server Components blur client and server execution, and that makes process identity, secrets handling, and least privilege part of the same control set. NHI governance applies wherever a workload identity or secret can be abused after code execution. Practitioners should evaluate web runtimes the same way they evaluate service accounts: by access scope, not by label.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, according to The State of Non-Human Identity Security.
• For a broader breach perspective, see 52 NHI Breaches Analysis for recurring credential and access failure patterns.

What this signals

React framework RCEs will keep exposing identity-adjacent risk because the dangerous part is not only code execution, but which workload identities and secrets the process can touch after compromise. Teams should assume that application runtime access is a governed identity problem and align patching, secret scoping, and service account separation accordingly.

Runtime deserialization boundary: this is the control point practitioners need to track when framework features blur client and server execution. If the boundary is not explicit in inventory, it is already a governance gap. [NHI Mgmt Group research on NHI visibility gaps](https://nhimg.org/the-state-of-non-human-identity-security) shows how often organisations lose track of access paths once third-party and workload relationships proliferate.

The next operational question is not whether one framework flaw exists, but whether your patching and privilege model can absorb the next one without broadening blast radius. [The 52 NHI breaches Report](https://nhimg.org/52-non-human-identity-breaches) repeatedly shows that exposure becomes material when credentials, runtime permissions, and logging are all weak at the same time.

For practitioners

• Patch React and Next.js immediately Upgrade to the fixed React and Next.js versions cited in the disclosure, then verify every RSC-enabled framework in the stack rather than only the primary app. Include build pipelines and deployed containers in the verification so stale images do not keep vulnerable code in production.
• Inventory every React Server Components route Identify all applications that use React Server Components, Server Functions, or custom server action routes, including internal tools and preview environments. Map routes such as /_next/server/endpoint and equivalent custom handlers to the exact versions deployed.
• Reduce the runtime’s reachable secrets Separate application runtime credentials from broader platform access, remove unnecessary environment variables, and avoid giving web processes direct paths to cloud metadata or privileged internal services. If the process is compromised, the smallest possible secret set limits the breach.
• Search historical logs for deserialization indicators Review web, application, and process logs for POST requests with __proto__, constructor, or prototype keys, malformed JSON to server function endpoints, unusual child processes, and unexpected outbound connections. Use the search to determine whether exploitation started before patching.
• Isolate high-risk applications before patch completion Where immediate upgrade is not possible, segment vulnerable applications from sensitive back-end systems and monitor their process behaviour for code execution indicators. This is a containment measure, not a substitute for patching.

Key takeaways

• CVE-2025-55182 turns React Server Components into a server-side code execution concern, not just a framework bug.
• The practical risk is determined by runtime privilege, secret exposure, and internal network reach, not by the vulnerability alone.
• Teams should patch, inventory RSC usage, and reduce process-level access now so a future exploitation path has less to abuse.

Key terms

• React Server Components: A React feature that splits rendering and execution between browser and server. It lets applications send and receive structured payloads that influence server-side behaviour, which means vulnerabilities in the server path can expose privileged code execution rather than just client-side rendering problems.
• 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.
• Runtime Privilege: Runtime privilege is the effective access an identity has after tools, data sources, and permissions are combined during execution. For AI agents, it can exceed the originally approved scope because the agent may chain actions across systems in ways no single entitlement review reveals.
• 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.

What's in the full analysis

Abstract Security's full post covers the operational detail this post intentionally leaves for the source:

• Exact vulnerable and patched version mapping for React, Next.js, and other RSC-enabled frameworks
• Indicators of compromise for logs, request payloads, and process behaviour that can help confirm exploitation
• Cloudflare and WAF rule references for organisations that need immediate compensating controls
• Recommended response sequencing for isolation, forensic review, and recovery after suspected exploitation

👉 Abstract Security's full post covers the exploit path, indicators of compromise, and patch guidance in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a practical foundation for connecting application runtime risk to identity control decisions.