By /

On December 3, 2025, the React team disclosed React2Shell or CVE-2025-55182, a CVSS 10.0 critical vulnerability affecting React Server Components (RSC) and related packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack). This flaw allows unauthenticated remote code execution (RCE) on servers using React’s server-side features.
A sister CVE (CVE-2025-66478) was originally issued for Next.js, it was later marked as a duplicate because Next.js bundles React internally.

React2Shell (CVE-2025-55182) A Critical Threat to Modern Web Apps

Why It’s Dangerous

The React2Shell vulnerability received the higher Vulnerability score possible of 10/10. But this does not mean that the world is burning down. We should understand why such a high score, and how to take care of it in our environments. So why is it so dangerous?

  • Unauthenticated Attack Vector: Exploitation requires no credentials. A crafted HTTP request to an RSC endpoint can trigger unsafe deserialization, leading to arbitrary code execution.
  • Widespread Exposure: Early telemetry suggests roughly one-third of monitored environments are affected! Hence this is serious and urgent, though not as pervasive as Log4Shell.
  • Modern Framework Impact: Popular frameworks like Next.js, React Router, Waku, and bundlers like Parcel and Vite are impacted due to their integration with RSC.
  • Rapid PoC Development: Public proof-of-concepts appeared within 30 hours of disclosure, increasing the risk of opportunistic exploitation.

Common Misconceptions

Be aware!  Because of the level of criticality this vulnerability has caught many eyes. But not all of them in a useful way, this generated a lot of noise, and people jump the gun on signatures and protection way to early, with some being too generic and others plainly looking for the wrong thing.

  • Invalid PoCs: Many circulating PoCs rely on developers exposing dangerous APIs like child_process.exec, which is unrelated to the real vulnerability. The genuine flaw does not require such misconfigurations.
  • False Positives in Scanners: Some automated tools flag Next.js instances incorrectly. When in doubt, patch immediately rather than relying solely on scanner output.

How to Detect If You Are Vulnerable

  1. Check Your React Version:

These are the Vulnerable versions of React:

  1. react-server-dom-webpack: 19.0, 19.1.0, 19.1.1, 19.2.0
  2. react-server-dom-parcel: same versions
  3. react-server-dom-turbopack: same versions\ Fixed versions: 19.0.1, 19.1.2, 19.2.1
  4. Check Framework Versions:
    • Next.js: 15.x and 16.x (patched in 15.0.5+, 16.0.7)
    • Canary builds ≥14.3.0-canary.77 are vulnerable
  5. Inspect Dependency Tree:

Run npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack to confirm.

  1. Runtime Indicators (What should you use as IoC) :
    • Unusual POST requests to /_next, /api, /react, /rsc endpoints
    • Large or deeply nested JSON payloads
    • Presence of keys like __proto__, constructor, prototype in request bodies

Proof-of-Concept (PoC) Test Cases

Because of all the noise, I decided to share some of the PoCs that I used to validate if you are vulnerable, or if your mitigation devices like WAF or runtime protections actually block malicious exploitation.:

Test 1: Prototype Pollution Key

curl -X POST "https://your-app.example.com/api/server-actions" \
  -H "Content-Type: application/json" \
  --data '{"__proto__":{"admin":true},"data":"waf-test"}'

Test 2: Constructor/Prototype Keys + Nested JSON“:

curl -X POST "https://your-app.example.com/_next/data/rsc" \
  -H "Content-Type: application/json" \
  --data '{"constructor":{"prototype":{"polluted":true}},"payload":{"a":{"b":{"c":{"d":{"e":{"f":{"g":"waf-test"}}}}}}}}'

Test 3: Oversized Body

curl -X POST "https://your-app.example.com/react/server" \
  -H "Content-Type: application/json" \
  --data '{"__proto__":{"flag":true},"data":"waf-test","n1":{"x":1},"n2":{"x":2}...}'

Test 4: Query String Pollution

curl "https://your-app.example.com/api/server-actions?__proto__=waf-test&constructor=1"

Detection Strategies

  • WAF Rules: Block requests containing __proto__, constructor, or prototype keys in JSON bodies or query strings.
  • Here is a rough example rule for ModSecurity:

SecRule REQUEST_BODY "@rx (?:__proto__|constructor|prototype)\s*:" \
  "id:5518202,phase:2,block,msg:'Prototype pollution attempt'"
  • Heuristic Checks:
    • Oversized or deeply nested JSON payloads to RSC endpoints
    • Unauthenticated POST requests to /_next, /api, /react, /rsc
  • Runtime Monitoring:
    • Unexpected Node.js child processes
    • File writes or outbound network calls from the app process
  • Vendor Signatures: Enable Akamai Rapid Rule 3000976 or equivalent in your WAF.

Immediate Actions

If you have read this far is either because you are really interested on this vulnerability or because your environment might be vulnerable. So, let’s get to some actionable intel. What should you do if you are vulnerable today:

  • Patch React and Next.js to fixed versions.
  • Apply WAF rules and runtime mitigations. (If you did your homework before hand and have a defense in depth strategy)
  • Monitor logs for suspicious requests and prototype pollution patterns. (If you are vulnerable, immediate patching is not always an option, so make sure you keep an eye for bad guys while you patch safely)

Sources:

Related Posts

Scroll to Top