React Server Functions RCE exposes downstream frameworks to attack

At a glance

What this is: This is a disclosure about a React Server Functions remote code execution vulnerability that affects multiple downstream frameworks and can be abused through insecure deserialization of HTTP payloads.

Why it matters: It matters because IAM, PAM, and application security teams need to treat framework dependencies as execution-risk surfaces, especially where server-side components can be reached through authenticated or unauthenticated request paths.

By the numbers:

• A second CVE-2025-66478 had been submitted specifically for the Next dependency.

👉 Read Semgrep's analysis of the React Server Functions RCE and affected frameworks

Context

React Server Functions move execution logic onto the server while allowing client code to invoke that logic through component patterns. That design reduces application complexity, but it also creates a security boundary that depends on how payloads are parsed, deserialised, and routed through downstream frameworks. In this case, the primary issue is not just the React disclosure itself, but the transitive exposure created when multiple ecosystems inherit the same server-side behaviour.

For IAM and application security teams, the relevant lesson is that a framework dependency can become an execution path even when the application team never wrote a traditional API endpoint. That changes how exposure should be assessed across build pipelines, package inventories, and runtime controls. The starting assumption that server components are safer because they are abstracted is typical, and that is exactly why this class of issue persists.

Semgrep Supply Chain can be used to verify whether affected dependencies are present, but the real governance question is broader: which teams own dependency risk, who validates transitive exposure, and how quickly update decisions are enforced across distributed codebases.

Key questions

Q: What should teams do first when a framework RCE flaw exposes server-side application code?

A: Start by identifying which workloads expose the vulnerable endpoint, then patch the affected framework versions and isolate any public assets that may already have been touched. If the vulnerable process held secrets or service credentials, rotate them as part of containment. The priority is to remove the reachable attack path before assuming the application is clean.

Q: Why do transitive dependencies make framework vulnerabilities harder to manage?

A: Because the application team may not directly install the vulnerable package, yet still inherit the same execution path through another framework. That splits ownership across build, platform, and security teams, which slows patching and creates blind spots in inventory, testing, and release approval.

Q: What breaks when organisations rely on firewall rules instead of patching?

A: Firewall rules can block known exploit paths, but they do not remove the vulnerable code or the residual risk on other environments. If a deployment, exception, or alternate route bypasses the rule, the attacker still has a path to code execution, so containment must be paired with remediation.

Q: How should teams reduce identity risk after application code execution exposure?

A: Assume any reachable secrets may be exposed and rotate them in priority order, starting with service account tokens, API keys, and signing certificates. Then narrow runtime privileges so the compromised process cannot reach broader cloud or internal services if exploitation occurs again.

Technical breakdown

How insecure deserialisation turns server functions into RCE

React Server Functions accept structured requests that are intended to resolve server-side logic safely, but insecure deserialisation breaks that trust boundary. If attacker-controlled HTTP payloads can influence how modules or exports are resolved, the server may execute code paths that were never meant to be externally reachable. That is the core RCE pattern here: input is interpreted as instructions rather than data. The danger increases when the same pattern is embedded in shared framework components used by many applications.

Practical implication: validate every server-side deserialisation path and treat request parsing as an execution surface, not just an input validation problem.

Why transitive dependencies expand exposure across frameworks

The disclosure affects not only React Server Functions directly, but also downstream frameworks such as Next, React Router, Waku, Parcel RSC, Vite RSC, and RedwoodJS. That matters because modern applications rarely pin a single direct package and stop there. Bundled or transitive dependencies can inherit the vulnerable code path even when the application team does not realise the framework is in use. This is a classic software supply chain problem: ownership, visibility, and patching are fragmented across library layers.

Practical implication: inventory both direct and transitive dependencies so you can identify impacted server-component frameworks before relying on application-level testing.

Why firewall rules help, but do not replace patching

Hosting providers can reduce exploitability by blocking known request patterns, but network-layer controls are compensating measures, not a fix for vulnerable execution logic. If the underlying package remains present, the application still carries residual risk wherever those protections are absent, bypassed, or misconfigured. Security teams should see this as layered defence, where runtime filtering buys time but does not eliminate the need to remove the vulnerable component. For identity teams, any server-side RCE also raises the stakes for secrets exposure and privilege misuse if the compromised host can access credentials or tokens.

Practical implication: use firewall rules as temporary containment only, then accelerate patching and credential review for any system that could have executed the vulnerable code.

Threat narrative

Attacker objective: The attacker aims to obtain arbitrary code execution on affected servers so they can steal credentials, access data, or establish persistence.

1. Entry occurs when an attacker sends a crafted HTTP payload to a server function endpoint that accepts deserialised input.
2. Escalation happens when the payload influences module or export resolution and the server executes attacker-chosen code paths.
3. Impact follows when the attacker uses code execution to access sensitive data, steal tokens, or deploy additional malware on the host.

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

Execution-path risk now matters as much as package risk: this disclosure shows that application security teams can no longer treat framework dependencies as passive libraries. When a server component accepts attacker-influenced payloads, the dependency itself becomes an execution surface. That means exposure management must extend beyond version tracking to runtime behaviour, route reachability, and privilege on the host. The practical conclusion is that software composition analysis alone is not enough without execution-path verification.

Transitive framework inheritance is a governance gap, not a tooling detail: the affected ecosystem includes multiple downstream frameworks, which means ownership is spread across app teams, platform teams, and security teams. That is exactly where vulnerabilities persist after disclosure, because no single group sees the full dependency chain. This is a software supply chain control problem that belongs in change governance and release gatekeeping, not just in vulnerability tickets. Practitioners should assume inherited risk until proven otherwise.

Server-side RCE becomes an identity problem the moment credentials live on the host: once arbitrary code runs in the application runtime, the attacker is no longer limited to the vulnerable function. Service account tokens, deployment credentials, and cloud metadata access can all turn a code flaw into broader identity compromise. That intersection between application execution and non-human identity governance is where many incident paths widen. The control implication is clear: runtime access, secret placement, and privilege scope must be reviewed together.

Framework-level firewalling should be treated as compensating control, not closure: the fact that some hosting providers deployed rules quickly is useful, but it does not change the governance obligation to patch source packages and verify downstream exposure. Security programmes often overestimate the value of perimeter blocking because it creates visible reassurance. In practice, the durable fix is dependency remediation, verified deployment, and post-exposure credential review. The conclusion for practitioners is to measure how quickly a vulnerability can be removed, not how quickly it can be hidden.

Application RCE increasingly overlaps with NHI exposure: modern server runtimes often hold API keys, signing material, and orchestration tokens needed for internal services. A vulnerability that starts in a framework can therefore become a pathway into machine identity abuse if those secrets are reachable from the compromised process. That makes NHI governance relevant even in what looks like a pure application security issue. Practitioners should therefore map where server processes can reach privileged credentials and limit that blast radius.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 52 NHI Breaches Analysis is a useful companion for understanding how exposed credentials widen the impact of application compromise.

What this signals

Framework RCE disclosures increasingly force security teams to connect application remediation with identity containment. The operational signal is not only whether the package is patched, but whether host-reachable secrets, API keys, and service account credentials were exposed before remediation completed. When that happens, application security and NHI governance need to move together, because code execution often becomes credential abuse within the same incident window.

Execution-path governance: this is the control gap that matters most in server-component ecosystems. Teams should track which runtimes can execute attacker-influenced server logic, which secrets those runtimes can reach, and how quickly those identities can be revoked or rotated after disclosure. That is where application vulnerability management turns into identity risk management.

For programmes using modern React-based stacks, this is a cue to tighten build-time scanning, deployment verification, and post-disclosure secret review. It also aligns naturally with the OWASP Non-Human Identity Top 10, because exposed server credentials are often the bridge from code flaw to broader environment compromise.

For practitioners

• Inventory direct and transitive framework exposure Build a dependency inventory that includes direct packages, bundled components, and transitive server-component frameworks such as Next-related and RSC-enabled libraries. Confirm which workloads can reach the vulnerable execution path before you rely on version pinning alone.
• Patch affected packages on a verified rollout path Move impacted applications to the patched versions identified in the disclosure, then verify the change in build output and deployed artefacts rather than assuming the package manager update propagated everywhere.
• Review runtime credentials on exposed application hosts Check whether the affected runtimes can reach service account tokens, API keys, signing certificates, or cloud metadata. If they can, rotate credentials that were accessible from the application process and narrow the host’s identity scope.
• Treat firewall rules as temporary containment only Use provider firewall rules to reduce immediate exploitability, but do not rely on them as the fix. Track them as compensating controls while you complete patching, redeployment, and post-exposure validation.

Key takeaways

• A React Server Functions RCE can turn an application dependency into an execution surface, which means vulnerability management must include runtime behaviour, not just version tracking.
• The disclosure matters because transitive frameworks widen exposure across many stacks, and any reachable secrets can quickly convert code execution into identity compromise.
• Patch the affected packages, verify the deployment, and review host-reachable credentials together, because firewall rules alone do not close the underlying risk.

Key terms

• Server-side rendering: Server-side rendering is the practice of generating application output on the server before it reaches the browser. It improves performance and user experience, but it also expands the trusted execution surface, which means bugs in parsing, hydration, or component transport can have server-level consequences.
• 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.
• Transitive dependency: A transitive dependency is a package that your application uses indirectly through another library or framework. These dependencies often create hidden exposure because teams may not realise they are present, yet they can still introduce vulnerable code into the runtime or build pipeline.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full analysis

Semgrep's full advisory covers the operational detail this post intentionally leaves for the source:

• Exact affected package ranges for Next, react-server-dom-* variants, and downstream frameworks.
• React's update instructions and the precise patched versions teams should deploy.
• Hosting-provider firewall context for Cloudflare, Vercel, and Railway deployments.
• Usage patterns for React Server Components that can be abused in practice.

👉 Semgrep's full post covers the vulnerable usage patterns, affected package ranges, and update instructions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect application exposure to the identity controls that limit blast radius across the programme.