React2Shell-CVE-2025-55182

React2Shell CVE-2025-55182: unauthenticated unsafe deserialization in React Server Components leading to reliable remote code execution via the Flight protocol.

✅ Fixed versions

• 19.0.1
• 19.1.2
• 19.2.1

This room walks us through why this bug exists, how it is exploited, and what defenders can do about it.

Flag: No answer needed.

🧠 Task 2: React Server Components & the Flight Protocol

Before exploitation, we need architecture clarity.

What are React Server Components?

React Server Components (introduced in React 19) allow parts of a React app to run on the server, not the browser. This means:

• Heavy computation stays server-side ⚙️
• Client receives only rendered output 📦
• Better performance, smaller bundles

Enter: React Flight ✈️

Communication between client and server happens via the React Flight protocol. This protocol serializes data on the client and deserializes it on the server.

It uses special markers:

• $@ → Chunk reference

• $B → Blob reference

• Property paths via colon notation Example:

  root@kitploit:~

  $1:constructor:constructor
  

⚠️ And this serialization logic is exactly where things go wrong.

Question: What symbol denotes a Blob reference? ✅ Answer: $B

💣 Task 3: The Core Vulnerability — Unsafe Deserialization

At the heart of CVE-2025-55182 lies a classic unsafe deserialization flaw.

Let’s look at the vulnerable pattern (do not crop 👇):

Why is this dangerous?

In JavaScript, bracket notation:

does not limit access to exported properties only. It walks the entire prototype chain.

Now comes the critical insight 👀:

• Every JavaScript function has a .constructor
• constructor points to the Function constructor
• Function("code") = arbitrary JS execution

Weaponizing Flight references

Because the Flight protocol allows colon-separated paths, an attacker can send:

Which resolves to:

1. Get module chunk
2. Access .constructor
3. Access .constructor again → Function

At this point, game over 🎮.

Flag: No answer needed.

🧨 Task 4: Exploitation Chain — From Bug to RCE

Now let’s break down maple3142’s PoC, step by step.

🧩 Stage 1: Fake Chunk Object

The attacker sends a multipart request containing a fake Chunk object:

This object mimics React’s internal Chunk structure. By pointing then to Chunk.prototype.then, React is tricked into awaiting attacker-controlled logic.

🧩 Stage 2: Blob Handler Abuse

The $B1337 marker triggers the Blob deserialization handler, which internally executes:

But we poisoned:

• _formData.get → Function
• _prefix → malicious JS

Resulting execution:

💥 Arbitrary JavaScript execution achieved.

🧩 Stage 3: OS Command Execution

The PoC executes:

This can be trivially replaced with:

• Reverse shells
• Secret exfiltration
• File reads
• Cloud credential theft ☠️

Flag: No answer needed.

📦 Task 5: Full HTTP PoC Breakdown

Here’s the complete exploit request (verbatim, not cropped):

(…multipart body continues…)

Key things to notice 👇

• Next-Action header triggers Server Actions
• multipart/form-data is mandatory
• $@0 creates a self-reference
• $B1337 triggers Blob logic
• constructor:constructor leads to Function

This is not accidental — it’s a precisely engineered chain.

🌍 Affected Ecosystem

• React: 19.0.0, 19.1.0, 19.1.1, 19.2.0

• Next.js:

  • ≥14.3.0-canary.77
  • All 15.x
  • Early 16.x

• Others: React Router (RSC), Waku, Redwood SDK

📊 Wiz research: 39% of cloud environments exposed 🌐 Shodan: 571k+ React servers, 444k+ Next.js

That’s… a lot 😶

🧪 Task 6: Exploitation in the Lab

First in Repeater, make New HTTP Request and select Target.

Using Burp Suite Repeater, we send the payload:

And later:

✅ Results

• User: ubuntu

• Flag:

  root@kitploit:~

  {React-19.2.0}
  

Clean, reliable, repeatable exploitation 💀

🛡️ Task 7: Detection & Defense

Good news for defenders 👮‍♂️ — exploitation leaves fingerprints.

🔎 Indicators of Attack

• Next-Action header
• multipart/form-data
• "status":"resolved_model"
• "then":"$1:__proto__:then"

These should never appear in normal user traffic.

🚨 Snort Rule (v3)

🧾 OSQuery — Finding Vulnerable Packages

Perfect for:

• CI/CD pipelines
• Endpoint audits
• Pre-production checks

🧠 Final Thoughts

React2Shell is a textbook example of:

• Why unsafe deserialization is deadly
• How prototype chains can betray you
• Why “default configs” are dangerous

Once patched versions are installed and npm audit recommendations followed, the exploit dies completely ✅.

⚠️ Never test this outside authorized labs.
🔥 Always patch fast.
🧠 Always understand why a bug exists — not just how to exploit it.

⭐ Follow Me & Connect

If you enjoyed this write-up or want to stay connected with my work in cybersecurity, CTFs, and VAPT:

🔗 GitHub: https://github.com/AdityaBhatt3010
💼 LinkedIn: https://www.linkedin.com/in/adityabhatt3010/
✍️ Medium: https://medium.com/@adityabhatt3010

Happy hacking — responsibly 🗿🚀