[!WARNING] For authorised security research and penetration testing only. Scanning systems without explicit written permission is illegal. The author assumes no responsibility for misuse of this tool.

Table of Contents

• Vulnerability Overview
• Affected Versions
• How Detection Works
• Installation
• Usage
• Options Reference
• Output & Verdicts
• Browser Mode
• Version Detection Pipeline

Vulnerability Overview

React Server Actions pass action data as multipart form data directly into a server-side execution context. Due to insufficient prototype-pollution sanitisation in affected versions of react-server-dom-webpack, an attacker can:

1. Inject a crafted multipart payload that pollutes Object.prototype
2. Override _response._prefix on the internal response object
3. Force the server to execute arbitrary shell commands via:
   root@kitploit:~

   process.mainModule.require('child_process').execSync(cmd)
   

This gives unauthenticated Remote Code Execution on any publicly accessible Next.js application using React Server Actions with an affected version of React.

CVE-2025-55182 - Broad: affects React 19 packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack)
CVE-2025-66478 - Strict: Next.js-specific exploitation path via the / Server Action endpoint

Affected Versions

How Detection Works

This scanner uses output-based canary verification - the most reliable method for confirming real code execution with zero false positives:

1.  POST /  with Next-Action header + multipart prototype-pollution payload
2.  Payload executes:  echo <random_canary>
3.  Vulnerable server throws NEXT_REDIRECT with base64(canary) in the URL
4.  Response header:   X-Action-Redirect: /login?a=<base64(canary)>
5.  Scanner decodes base64 → matches canary → RCE confirmed ✓

allow_redirects=False is critical - the confirmation lives in the header, not the redirect destination.

Installation

git clone https://github.com/InferiorAK/React2Shell
cd React2Shell

pip install -r requirements.txt

# Required only if using --browser mode for improved version detection:
playwright install chromium
playwright install-deps chromium

Requirements: Python 3.10+

Usage

CVE-2025-55182 Scanner - Broad (React + Next.js)

# Single target
python3 CVE-2025-55182_scanner.py -u https://target.com

# Scan a list of URLs
python3 CVE-2025-55182_scanner.py -f urls.txt

# Quiet mode - only print RCE / Vulnerable results
python3 CVE-2025-55182_scanner.py -f urls.txt -q

# Browser mode - headless Chromium for accurate version detection
python3 CVE-2025-55182_scanner.py -f urls.txt -b

# Full options - recommended for large-scale scanning
python3 CVE-2025-55182_scanner.py -f urls.txt -b -q -c 3 -t 20

Options Reference

CVE-2025-55182 Scanner

Output & Verdicts

Each scanned target is assigned one of the following verdicts:

Output files (saved to outputs/ folder, created automatically):

• outputs/vuln.txt — RCE and VULNERABLE results (appended on each run)
• outputs/unknown.txt — Unknown-version targets; retry these with -b for accurate version detection

Browser Mode

Why does version show as unknown for 90%+ of sites?

Modern Next.js 13+ using the App Router architecture never embeds the framework version in static HTML. The version only exists in window.next.version after JavaScript executes in a real browser context.

Without --browser:

• Version detection relies on HTTP headers, __NEXT_DATA__, inline scripts, and hashed chunk files
• App Router sites almost always return unknown - version-based filtering is bypassed

With --browser (-b):

• Playwright launches headless Chromium
• Page JavaScript fully executes
• Scanner reads window.next.version directly from the live DOM
• Version accuracy goes from ~10% → near 100% on modern Next.js sites

# Recommended with browser mode - reduce concurrency (browser pages are resource-heavy)
python3 CVE-2025-55182_scanner.py -f urls.txt -b -c 3

Version Detection Pipeline

The scanner runs up to 7 stages, stopping as soon as a version is found:

Stage 1 │ HTTP Response Headers
        │  X-Powered-By: Next.js X.Y.Z
        │  x-nextjs-*, x-next-version

Stage 2 │ Inline <script> Blocks (per-block scan)
        │  window.next = { version: "X.Y.Z", ... }
        │  version:"X.Y.Z", router: ...      ← minified bundle adjacent-key pattern
        │  "nextVersion":"X.Y.Z"
        │  Next.js vX.Y.Z                    ← plain text in meta / HTML comments
        │  __NEXT_VERSION__ = "X.Y.Z"

Stage 3 │ __NEXT_DATA__ JSON Blob
        │  Pages Router only - "version":"X.Y.Z" safe in this context

Stage 4 │ Hashed Chunk URLs (extracted from <script src>)
        │  /_next/static/chunks/*, /_next/static/app/*, /_next/static/runtime/*
        │  Fetches up to 12 real bundle files, scans for version strings

Stage 5 │ Fixed-name Fallback Chunks
        │  main.js, framework.js, webpack.js, _app.js, pages/_app.js

Stage 6 │ /package.json endpoint
        │  Dev mode / misconfigured servers expose this directly

Stage 7 │ Playwright Headless Browser  [--browser / -b only]
        │  Evaluates window.next.version after full JS execution
        │  Only triggered when stages 1–6 return "unknown"

Disclaimer

This tool is published for educational and authorised security research purposes only.
The author, InferiorAK, is not responsible for any damage caused by misuse.
Always obtain written permission before testing any system you do not own.

My Links