Beyond React2Shell:

How CVE-2025-55184 & CVE-2025-55183 Could Still Hurt Your App — And What to Do

The security landscape around React Server Components (RSC) continues evolving as researchers uncover follow-up issues to the widely reported React2Shell vulnerability. While React2Shell (CVE-2025-55182) was a critical remote code execution flaw, there are two additional vulnerabilities that developers must urgently patch and understand: CVE-2025-55184 and CVE-2025-55183.

These new issues do not allow unauthenticated remote code execution, but they can still negatively impact applications relying on RSC or frameworks like Next.js.

First we need to understand what are these new vulnerabilities?

CVE-2025-55184 — Denial of Service (High Severity)

What it is: A specially crafted HTTP request sent to a Server Functions endpoint can trigger logic that enters an infinite loop inside React's server-side deserialization or Promise resolution flow. This effectively hangs the server, consuming CPU and preventing legitimate traffic from being handled.

Impact:

A service affected by this issue can stop responding to user traffic.
Autoscaling or health-check-based restarts may mitigate impact but do not replace patching.
Attackers don't need privileges or authentication to trigger the DoS.

CVE-2025-55184 is a high-severity denial-of-service (DoS) vulnerability (CVSS 7.5) in React Server Components (RSC). It was publicly disclosed on December 11, 2025, following increased scrutiny of RSC after the critical remote code execution vulnerability CVE-2025-55182 (known as "React2Shell"). The vulnerability allows an unauthenticated attacker to send a specially crafted HTTP request to a Server Actions (or Server Functions) endpoint. Due to unsafe deserialization of the payload in the RSC "Flight" protocol, this can trigger an infinite loop or infinite promise recursion in the Node.js server process, consuming CPU and hanging the worker thread. This effectively takes the application offline, preventing it from serving further requests.

Root Cause

The issue stems from insecure deserialization in the RSC payload handling. Attackers can craft payloads that create cyclic or self-referencing structures, particularly involving Promises. When React deserializes these:

A Promise can resolve to itself (or a chain that loops back). During resolution/unwrapping in Node.js, this leads to infinite recursion in the microtask queue. Node.js's event loop gets starved, as the microtasks never complete, blocking other operations.

This is an algorithmic complexity attack targeting the event loop rather than simple resource exhaustion (e.g., no massive memory/CPU spikes beyond the loop). Example of Vulnerable Behavior (Conceptual JavaScript) The following is a simplified illustration of how a self-referencing Promise can cause infinite recursion (not the exact exploit payload, but demonstrates the principle):

// Conceptual demonstration of infinite promise recursion
const p = Promise.resolve();
p.then(() => p);  // Creates a cycle: the promise resolves to a then-chain that waits on itself
 
// In Node.js, awaiting or unwrapping this would loop forever
(async () => {
  await p;  // This will never resolve — infinite microtask recursion
})();

In the context of RSC deserialization, a malicious payload encodes a similar cyclic Promise structure, forcing the server to enter this state when processing the request.

CVE-2025-55183 — Source Code Exposure (Medium Severity)

What it is: Under specific conditions, a crafted request to a Server Function coerces an argument such that its stringified form forces the system to return compiled source code for any Server Function handler.

Impact:

Attackers can see your application logic—not just error messages.
Hard-coded secrets embedded directly in server functions may be exposed.
Even if environment variables remain safe, this intelligence can help attackers craft further attacks.

Root cause

In RSC, server functions are executed on the server and can serialize responses back to the client via the RSC Flight protocol. The flaw arises when a server function processes user input in a way that implicitly or explicitly stringifies an argument originating from its scope. An attacker can craft an HTTP request that triggers the server to serialize and return the function's own source code (or that of other referenced functions) as a string in the response payload.

This occurs because the serialization process (e.g., via toString()) on a server function object inadvertently exposes its internal representation, including the bundled source code. The exposed scope is limited to the function body and any inlined dependencies from the bundler, but it can still reveal proprietary logic or static secrets.

'use server';
 
export async function serverFunction(name) {
  const conn = db.createConnection('SECRET KEY');  // Hardcoded secret
  const user = await conn.createUser(name);
  
  // Implicit stringification via template literal (leaked in 'message')
  // Explicit stringification via JSON response
  return {
    id: user.id,
    message: `Hello, ${name}!`  // Vulnerable: name is stringified and returned
  };
}

In this case, the name parameter is user-controlled. If an attacker sends a request that references the function object itself (e.g., via a malformed RSC payload), the server may serialize the entire function body, including the 'SECRET KEY' literal.

Who is Affected?

Both CVEs affect the same React RSC packages that were vulnerable to React2Shell, including:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

And frameworks or bundlers depending on them—most notably Next.js App Router implementations across versions 13.x, 14.x, 15.x, and 16.x.

If your app does not use Server Components / Server Functions, it may not be affected—but library dependencies still matter.

Immediate Action: Patch or Upgrade

The only reliable mitigation for both vulnerabilities is to upgrade to the patched versions of affected packages and frameworks. For example, in Next.js:

# Upgrade to patched versions
npm install next@latest   # ensures latest versions with fixes for CVE-2025-55184 and CVE-2025-55183

Refer to framework advisories for exact version mappings—patched releases are published for all active LTS lines.

Example: Identifying Vulnerable Endpoints

If your Next.js or RSC deployment uses Server Actions, audit functions like:

'use server';
 
export async function createUser(data) {
  // Potentially exposed logic
  return await db.saveUser(data);
}

Then ensure:

Inputs are validated strictly.
No sensitive logic relies on stringified function inputs.
Patching occurs immediately.

Additional Mitigation Strategies

Even with upgrades applied, consider:

WAF / Virtual Patching

Web Application Firewalls (e.g., Cloudflare, Akamai) have deployed rules targeting known exploit patterns for both CVEs. Virtual patching can reduce exposure while you roll out upgrades.

Monitoring & Alerting

Set up logging or AppSec tooling to track:

Heavy CPU loops
Unexpected request payloads to Server Function endpoints

These can be early signs of a DoS attempt.

Why These Matter Even After a Critical RCE

Discovering follow-up flaws after a critical CVE like React2Shell is common as deeper code paths get scrutinized. While these two CVEs may seem less severe than RCE, they both increase risk and operational impact if exploited.

A DoS can disrupt availability.
Source code exposure aids adversaries in crafting future attacks.

Both are worth treating with urgency.

Final Takeaways

CVE	Severity	Impact	Mitigation
CVE-2025-55184	High	Denial of Service	Patch to fixed versions immediately
CVE-2025-55183	Medium	Source Code Exposure	Patch and avoid hard-coded logic

Upgrading your dependencies and closely monitoring Server Function endpoints should be part of your production security hygiene. Patching these CVEs closes two more doors that attackers could use in combination with other exploits.