React2Shell — CVE-2025–55182: Practical Exploitation of the Vulnerability

In a previous post, we explored React2Shell as a concept and how insecure deserialization in React Server Components (RSC) can lead to prototype pollution and in RCE.

This time we have Northport Ledger application (created with Codex ), we’ll walk through a small, intentionally vulnerable Next.js application, identify the exact code paths that introduce risk, and then observe how the vulnerability can be exercised in practice using a crafted RSC Flight request.

This is a training demo for my source code review challenges , which you can find and practice on my github. With this I am trying to provide quality source code review challenges inspired from real CVEs and Bugs. For this I am inspired from Florian, who has excellent challenges.

And I have taken a huge inspiration from the AppSecmaster to make this particular challenge. I strongly encourage you to checkout their website as they have organized and hand-on source code review challenges. They are generous to provide this coupon code to get 35% off KICKOFF35, if you plan to subscribe them.

Northport Ledger (what are we looking at?)

The application is a minimal Next.js project built using:

• App Router
• React Server Components
• Server Actions

Functionally, it behaves like a simple banking dashboard:

• Users log in
• Accounts are displayed
• Funds can be transferred between accounts

Architecturally, it’s split into three parts:

• Server Actions (app/actions.ts): Handles authentication and fund transfers.
• Client Components: A login page and a dashboard that invoke Server Actions.
• Data Layer (lib/db.ts): In-memory users, accounts, and transactions.

I highly recommend you to go at this challenge github and look at code. Nothing exotic right? that’s the main thing. The issue starts with a Server Action responsible for transferring funds. It looks harmless:

• It’s marked with ‘use server’
• It accepts user-controlled parameters
• It performs basic business logic

What it does not do is validate the structure or type of incoming data before React deserializes it. At a glance, this feels reasonable. After all, Server Actions are “internal”, right?

That assumption is the root problem. that’s what React2Shell is. We have already explained about that in previous blog or you can do google about it.

>There is no clever bypass, no race condition, no logic bug. A single missing validation step is enough.

• The structure of incoming Flight data is not validated
• JavaScript prototypes can be polluted during deserialization
• The constructor → constructor chain can be reached
• Arbitrary JavaScript can be executed in the server context

Server Actions amplify the impact by exposing this deserialization path as an HTTP endpoint by default.

Exploitation

Because Server Actions are exposed as POST endpoints, an attacker does not need direct access to the UI. A crafted multipart/form-data request that mimics a valid RSC Flight payload is enough to reach the vulnerable deserialization path. Below is an example captured in Burp Suite.

Training Route

we have /api/training/rsc-probe endpoint where we can send this request and test the vulnearbility.

Instead of executing payloads, it:

• Detects dangerous tokens (__proto__, constructor)
• Flags suspicious RSC structures
• Returns detailed rejection reasons

To craft the payload we have to keep three things in mind:

1. Prototype Pollution using __proto__
2. Constructor chaining to reach the Function constructor
3. Deserialization side-effects triggered during Flight reconstruction

we can compare both screenshots and see how to exploit this vulnerability. Exploit would have same logic for any application having this vulnerability. You just have to tweak it according to situation and what your goal is.

(Unfortunately, Medium is not allowing me to paste the payload but you can see it in the image)

Remediation

Primary fix: Upgrade React and Next.js to the patched version!

• Validate all Server Action inputs with schemas (e.g., Zod)
• Monitor unusual Server Action requests
• Alert on malformed multipart RSC payloads
• Block prototype pollution patterns at the edge

React2Shell is not about “bad developers”, all it says is how powerful abstractions fail when trust boundaries are not clear. This must be taken into consideration whenever doing System design or Threat Modeling of the application in the early phase.

This is it from my side about this CVE. you can apply this same concept to any application having vulnerable version and receive the bounty, haha. Also, don’t forget to check out AppSecMaster platform and the coupon code is KICKOFF35. By far, that’s the most realistic platform for source code review practice, and of course my GitHub too, aha.