Vulnerability Summary

If you’re running a modern React SSR or Next.js App Router with anything touching RSC, streaming, or Flight, treat this as an incident: patch immediately, verify what’s deployed, then audit exposure and logs. The most likely mass-exploitation path is the default, reachable Next.js applications that expose the RSC/Server Action surface area without teams realizing it.

The Difficulty of RSC: Render. Serialize. Compromise

What makes this vulnerability particularly nasty is its lack of forensic artifacts. React doesn’t log anything, and most people may have base HTTP logs from reverse proxies at best.

Attackers are currently cycling through the full menu of Node.js process execution primitives to see what sticks:

• exec()
• spawn()
• execSync()
• spawnSync()

Understanding RSC: Render. Serialize. Compromise

Discovered by Lachlan Davidson and disclosed to the React Team on November 29, 2025, CVE-2025-55182 is an unsafe deserialization vulnerability in React Server Components. The vulnerability was named RSC: Render. Serialize. Compromise by security researchers. React and Next.js are widely used frameworks for building modern digital experiences. The vulnerability resides in a part of these frameworks called React Server Components.

Key facts:

• CVSS score: 10.0 (Maximum severity)
• Attack vector: Unauthenticated remote code execution
• Frameworks affected:
  • React Server components in Next.js 14.3.0-canary.77 and later canary releases and 15.x/16.x with App Router
  • React 19.x, including react-server-dom-parcel, react-server-dom-turbopack, react-server-dom-webpack
  • React Router (RSC mode)
  • Waku
  • Parcel RSC (@parcel/rsc)
  • Vite RSC (@vitejs/plugin-rsc)
  • RedwoodSDK (rwsdk)
• A standard create-next-app production build is vulnerable without modifications. Default configurations are exploitable out of the box.
• Fixed Next.js Versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

Summary of Affected Versions

Exploitation Timeline

• November 29th: Lachlan Davidson reported the security vulnerability via Meta Bug Bounty.
• November 30th: Meta security researchers confirmed and began working with the React team on a fix.
• December 1st: A fix was created, and the React team began working with affected hosting providers and open source projects.
• December 3rd: The fix was published to npm and publicly disclosed as CVE-2025-55182. Attacks began shortly after.
• December 4th: First exploitation activity observed. AWS honeypots observed near-real-time scans.
• December 5th: Infrastructure linked to Earth Lamia and Jackpot Panda confirmed to be repurposing for attacks.

React Server Components (RSC)

Before dissecting the exploit chain, we need to understand the architecture that makes this possible.

Understanding React Server Components and the Flight Protocol

React Server Components is a feature introduced in React 19 that allows components to be rendered on the server. The communication between the server and client relies on a protocol called React Flight. This protocol handles the serialisation and deserialisation of data using specific type markers (e.g., $@ for chunk reference, $B for Blob reference).

The Core Vulnerability: Unsafe Deserialization

The vulnerability exists in the requireModule function within the react-server-dom-webpack package. The critical flaw is in the bracket notation access moduleExports[metadata[2]]. An attacker can reference properties that weren’t explicitly exported by the module, such as constructor to access the global Function constructor.

The Exploitation Chain

The exploit begins by sending a multipart form request with a prepared payload containing a malicious chunk object. This object mimics React’s internal Chunk class structure and abuses the then property to create a self-referential structure. It also uses a $B Blob reference to trigger execution of code via the Function constructor.

This payload demonstrates RCE by launching a calculator. Real attacks could establish reverse shells or exfiltrate secrets.

Mitigation Actions

• Upgrade to the Latest Patched Version: Install the appropriate fixed version for your release line (e.g., Next.js 15.0.5, 15.1.9, etc.).
• Required Downgrade for Vulnerable Canary Builds: If using Next.js 14.3.0-canary.77+, downgrade to stable 14.x.
• Scan your infrastructure: Run automated scanners (SCA / static analyzers).
• Deploy runtime detections: Use tools like Falco or Sysdig Secure.
• Enable WAF protections: Cloudflare, Google Cloud Armor, and others have deployed rules.