A Turkish version of this post was originally published on blog.arasmehmet.com.

Disclaimer: This is a retrospective analysis of a publicly disclosed CVE that has been patched since disclosure. All exploit mechanics discussed are conceptual; nothing here is a working exploit.

December 3rd, 2025. The React Security Advisory published CVE-2025-55182, nicknamed React2Shell. CVSS 10.0, the highest possible severity. A specially-crafted HTTP request, no authentication, arbitrary code execution on any app running React Server Components.

Lachlan Davidson reported it to Meta's Bug Bounty four days earlier. Meta's security team verified it the next day. The patch and the public disclosure went out together on December 3rd.

I went through the advisory, the patch diff and the postmortems. Not the security-industry hot takes, the actual mechanics. Below is what stood out.

What's in here:

1. The vulnerability
2. The Flight protocol and thenables
3. RCE through the prototype chain
4. Why default Next.js was vulnerable
5. Affected packages
6. Discovery and disclosure
7. Exploitation in the wild
8. Impact
9. The 700-line decoy patch
10. AI-generated fake PoCs
11. The Cloudflare outage
12. The fix
13. What to do

1. The vulnerability

React 19 introduced Server Components, which talk to the client over a protocol called Flight. Flight serializes data on one side of the wire and deserializes it on the other.

Flight wasn't validating incoming payloads properly. An attacker could send a specially-crafted HTTP request containing a fake "Chunk" object. When React tried to resolve that object as a Promise, a then method defined on the object would execute.

The exploit chain:

1. Attacker sends a fake Chunk object.
2. React tries to process it as a Promise.
3. The fake then method runs.
4. Through JavaScript's prototype chain, Array.constructor leads to the Function() constructor.
5. Function() compiles strings into executable code at runtime, so arbitrary code runs on the server.

2. The Flight protocol and thenables

The Flight protocol moves RSC payloads in this format:

0:{"name":"MyComponent","env":"Server"}
1:["$","div",null,{"children":"Hello"}]

The issue is that React was parsing incoming objects and trying to treat them as Promises without first checking the then method. In JavaScript, any object with a then method is considered "thenable":

// Regular Promise
const promise = Promise.resolve(42);
promise.then(val => console.log(val)); // 42

// Thenable object, acts like a Promise
const thenable = {
  then: function(resolve) {
    resolve(42);
  }
};
Promise.resolve(thenable).then(val => console.log(val)); // 42

Attackers exploited exactly this. A fake Chunk object with a custom then method would run when React tried to resolve it, and from there the attacker got access to internal state.

3. RCE through the prototype chain

In JavaScript, every array's constructor points to the Function constructor:

[].constructor.constructor === Function // true

// Which means:
const fn = [].constructor.constructor('return process.env');
fn(); // environment variables from the server

Function() compiles strings into executable code at runtime, the same dynamic-code-execution behavior people warn about in JavaScript. Attackers used this chain to run arbitrary code:

// Conceptual exploit (simplified)
const maliciousChunk = {
  then: function(resolve, reject) {
    // Reach Function via Array constructor
    const FnCtor = [].constructor.constructor;
    // From here, any Node API is reachable: file system,
    // environment, subprocesses, network. PoCs in the wild
    // used this to spawn shell commands like `whoami`.
    FnCtor("/* arbitrary server-side code */")();
  }
};

Once this payload was encoded into an HTTP request body and sent to an RSC endpoint, the code ran on the server.

Important detail: even if your app didn't explicitly use Server Actions, if RSC support was enabled, you were vulnerable. Every Next.js project created with create-next-app defaults ships with App Router enabled, which means direct exploitation worked out of the box.

4. Why default Next.js was vulnerable

npx create-next-app@latest my-app
# Accept all defaults

This command creates a project with the app/ directory, which enables the App Router. The App Router automatically exposes RSC endpoints:

POST /_next/rsc HTTP/1.1
Content-Type: text/x-component

[malicious Flight payload]

Even without a single Server Action defined, RSC payloads get processed through this endpoint. "I don't use Server Actions" wasn't protection.

5. Affected packages

React packages (versions 19.0.0, 19.1.0, 19.1.1, 19.2.0):

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

Affected frameworks:

• Next.js 15.x and 16.x
• React Router (with RSC support)
• Waku, RedwoodSDK
• Parcel and Vite RSC plugins

Not affected:

• Core react and react-dom packages
• Client-side-only React apps
• React 18 and earlier

6. Discovery and disclosure

Security researcher Lachlan Davidson reported the vulnerability to Meta's Bug Bounty program on November 29th, 2025. Meta's security team verified it the next day, and a patch went out with the React team on December 3rd, 2025. The coordinated disclosure and the patch landed the same day.

7. Exploitation in the wild

Within hours of the disclosure, China-linked state-sponsored groups started exploiting it. Per Amazon and Palo Alto Networks:

• Earth Lamia and Jackpot Panda carried out the first attacks.
• UNC5174 hit more than 30 organizations.
• Attackers harvested AWS credentials, SSH keys and cloud metadata.
• Cryptominers, backdoors and RATs were dropped.

CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on December 5th.

8. Impact

Per Wiz Research:

• 39% of cloud environments had at least one vulnerable React instance.
• 44% of them were hosting a public-facing Next.js app.

Censys estimated around 2.15 million internet-facing services were affected.

9. The 700-line decoy patch

The React maintainers (sebmarkbage in particular) didn't just fix the bug. They shipped a ~700-line patch that included the actual fix alongside unrelated code changes, general deserialization hardening and structural tweaks.

The intent was obvious: obfuscation. Make attackers spend more time figuring out where the real vulnerability sat.

The side effect was that security researchers got misled too. The $F primitive and the loadServerReference code path looked suspicious but were decoys. The real exploit path was somewhere else entirely. The community argued about this: it slowed attackers, but it also slowed defenders.

10. AI-generated fake PoCs

After the disclosure, dozens of "Proof of Concept" exploits started circulating. Per Trend Micro, around 145 fakes ended up in circulation, and most of them didn't actually trigger the real vulnerability.

The common shape of these fakes: they required the developer to explicitly expose functions like vm#runInThisContext, subprocess spawners or fs#writeFile. The real vulnerability didn't need any of that. It worked on default configurations.

Two risks came out of this:

1. False negatives: testing with a broken PoC and concluding "we're safe".
2. Misplaced confidence: underestimating the actual scope of the threat.

11. The Cloudflare outage

December 5th, 2025, 08:47 UTC. 28% of Cloudflare's HTTP traffic went down. A lot of sites went down, including LinkedIn, X, Zoom and Canva.

The cause: a config error during the emergency WAF rollout for React2Shell. While modifying body parsing logic, Cloudflare triggered a Lua error in the FL1 proxies, and every affected request returned HTTP 500.

The outage lasted 25 minutes. Cloudflare CTO Dane Knecht's statement: "This wasn't an attack. The changes to our body parsing logic, made while deploying detection and mitigation for the React Server Components vulnerability, triggered this."

Irony: Cloudflare's China network wasn't affected.

The incident is a decent reminder that emergency security patches carry their own risk.

12. The fix

The patch added validation that checks whether incoming objects are actually real Chunks. Conceptually:

// Vulnerable code (simplified)
function resolveChunk(chunk) {
  // Accepts any thenable
  return Promise.resolve(chunk);
}

// Patched code (simplified)
function resolveChunk(chunk) {
  // Check for the internal Chunk symbol
  if (!chunk[REACT_CHUNK_SYMBOL]) {
    throw new Error('Invalid chunk');
  }
  return Promise.resolve(chunk);
}

Patched versions (December 3rd, 2025):

• React packages: 19.0.1, 19.1.2, 19.2.1
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

Vercel deployed platform-wide WAF rules and shipped the npx fix-react2shell-next utility.

13. What to do

First, check whether you're vulnerable:

# Check package-lock.json or yarn.lock
grep -E "react-server-dom-(webpack|parcel|turbopack)" package-lock.json

# Or via npm list
npm list react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

Then:

• Update immediately: bump affected packages to patched versions.
• Rotate secrets: if you were exposed between December 3rd and 5th, change every credential.
• Review logs: check for suspicious RSC endpoint requests.
• Add WAF rules: temporary coverage, not a substitute for patching.

React2Shell is the first maximum-severity vulnerability in the React Server Components architecture. Deserialization bugs are one of the most dangerous classes in software security, and this one was exploitable in default configurations. People compared it to Log4Shell, and that comparison wasn't a stretch. Both the blast radius and the ease of exploitation lined up.

If you're running RSC or Next.js 15+, go patch.

Sources: React Security Advisory, Next.js CVE-2025-66478, Palo Alto Unit 42, Amazon Security Blog, Wiz Research, CISA KEV