CVE-2025-55182: Remote Code Execution in React Server Components

1. Summary

• Vulnerability class: Unsafe deserialization → arbitrary code execution.
• Affected feature: React Server Components (RSC) “Flight” protocol.
• Root cause: Server-side RSC parsers trusted client-supplied data structures and executed certain functions during hydration.
• Impact: Unauthenticated attackers could remotely execute code on servers running vulnerable RSC implementations.
• Severity: Critical
• Exploit maturity: Fully weaponizable; trivial payload delivery via HTTP POST/GET to RSC endpoints.

Fixed in: React 19.0.1, 19.1.2, 19.2.1 and downstream framework releases.

2. Technical Details

2.1. How React Server Components Work

React Server Components rely on a protocol internally called Flight. The server returns a serialized component tree which includes:

• React component metadata
• Function references
• Streamed partial component payloads
• Serialized props and nested structures
  

The client hydrates the server-rendered output by evaluating the incoming RSC instructions embedded in the Flight response.

2.2. Where the Vulnerability Occurred

During deserialization, React expects certain internal markers (e.g., $F, $L, $S tags) representing functions, modules, and lazy-loaded nodes. These markers instruct the runtime to:

• Resolve a function reference
• Load a module
• Reconstruct a server action
• Execute code as part of hydration
  

In affected builds, the deserializer failed to sufficiently validate or sanitize these markers. As a result:

1. Attacker crafts a Flight payload with a malicious function reference.
2. The vulnerable RSC parser interprets it as a legitimate server function.
3. The parser rehydrates it into a live function pointer.
4. Execution occurs during hydration, giving the attacker arbitrary code execution.
   

2.3. Why This Becomes RCE

The vulnerable code paths allowed:

• Resolution of arbitrary module paths.
• Execution of module-scoped functions.
• Invocation of server “actions” without authentication.
• Execution during initial hydration before application routing or session logic.
  

Because the Flight endpoint is typically exposed as a public HTTP endpoint in frameworks like Next.js, this leads to unauthenticated RCE.

2.4. Conditions Required for Exploitation

The exploit requires only:

• A reachable RSC server endpoint /react, /__flight, _rsc, or framework-specific endpoints.
• The server running a vulnerable RSC package version.
• The ability to send arbitrary HTTP requests (GET or POST).
  

No authentication, CSRF token, session cookie, API key, or login is required.

It does not require:

• SSR templates
• Server Functions explicitly defined
• Custom server actions
  

The underlying parser vulnerability exists even if no user-defined server functions are shipped.

3. Impact

The impact is determined by what the Node.js process or server runtime has access to.

An attacker can:

• Execute arbitrary JavaScript on the server.
• Read filesystem content.
• Write or overwrite files.
• Access environment variables.
• Interact with internal network resources.
• Execute shell commands.
  

Any RSC-enabled app running on a public domain is potentially vulnerable.

4. Affected Versions

4.1 Directly affected React packages

4.2 Downstream frameworks

These embedded the vulnerable RSC implementations and are therefore affected until patched:

If you're unsure whether your framework bundles RSC internally, check your lockfile for the above packages.

5. Detection & Assessment

Recommended checks:

1. Search your dependency tree: ‍
   
   • npm ls react-server-dom‍
   • ‍yarn why react-server-dom‍
   • ‍pnpm list react-server-dom*‍
2. ‍Inspect lockfiles for any affected versions.‍
3. Enumerate reachable RSC endpoints
   Look for routes like:
   
   • _rsc
   • __flight
   • /_react
   • framework-specific RSC fetchers‍
4. Review logs for unexpected module loads. Attackers often trigger error messages when probing module-resolution boundaries.

6. Remediation

6.1. Update Immediately

Upgrade to the fixed versions:

react-server-dom-parcel@19.0.1 / 19.1.2 / 19.2.1
react-server-dom-webpack@19.0.1 / 19.1.2 / 19.2.1
react-server-dom-turbopack@19.0.1 / 19.1.2 / 19.2.1

Or upgrade your framework if you're using:

• Next.js
• Remix with RSC
• Any meta-framework shipping RSC internally
  

6.2. Patch all environments

Apply updates to:

• Production
• Staging
• Preview/branch deployments
• CI/CD ephemeral environments
• Local developer containers or VMs

6.3. Rotate secrets if necessary

If you detect suspicious activity or cannot confirm log integrity, rotate:

• Environment variables
• API credentials
• Database passwords
  

7. Why This Matters Architecturally

The vulnerability underscores a broader class of issues:client-controlled serialized instructions that trigger server execution.

This pattern has historically caused systemic issues in:

• Java Serialization
• Python pickle
• PHP unserialize
• Ruby’s YAML.load
  

React’s RSC Flight protocol introduced a similar risk surface by allowing the client to send structured data that maps to executable server actions.

The fix required tightening validation, adding guardrails around function markers, and eliminating code paths that allowed untrusted instructions to survive deserialization.

8. Conclusion

CVE-2025-55182 highlights how full-stack frameworks like React Server Components can expose server-side behavior through client-accessible interfaces. This blurring of client and server boundaries increases the risk of critical vulnerabilities, especially ones that traditional static analysis tools or linters often miss, because the dangerous behavior only becomes apparent at runtime.

Teams building with React Server Components — either directly or through frameworks like Next.js — should upgrade immediately, verify that no vulnerable endpoints remain exposed, and review internal usage of RSC to ensure that server-side execution is treated as a high-risk boundary.

References

1. Facebook Open Source. (2025, December 3). Critical security vulnerability in React Server Components. React.dev. https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
2. Aikido Security. (2025). React / Next.js RCE: CVE-2025-55182 technical analysis. https://www.aikido.dev/blog/react-nextjs-cve-2025-55182-rce
3. CVE Program. (2025). CVE-2025-55182. MITRE. https://cve.mitre.org
4. OWASP Foundation. (2024). Vulnerability disclosure cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
5. Vercel. (2025). Security advisory: CVE-2025-55182 — React Server Components. Vercel Changelog. https://vercel.com/changelog/cve-2025-55182
6. The React Team. (2025). Critical Security Vulnerability in React Server Components. https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components 
7. Node.js Security Working Group. (2023). Security considerations for server-side JavaScript execution. Node.js Documentation. https://nodejs.org/en/docs
8. Python Software Foundation. (2024). Security implications of pickle and unsafe deserialization. Python.org. https://docs.python.org
9. OWASP Foundation. (2023). Deserialization vulnerability guidelines. OWASP. https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data