Post

ReactOOPS – Exploiting CVE-2025-55182 in a Realistic Next.js Environment

A deep technical walkthrough of solving the ReactOOPS HackTheBox challenge using CVE-2025-55182, including fingerprinting, reconnaissance, exploitation workflow, and lessons learned.

ReactOOPS – Exploiting CVE-2025-55182 in a Realistic Next.js Environment

Introduction

The ReactOOPS challenge on HackTheBox provides a realistic simulation of CVE-2025-55182, a critical vulnerability affecting React Server Components (RSC) in Next.js. This challenge goes beyond simple script execution, requiring careful framework fingerprinting, endpoint analysis, and controlled exploitation techniques.

In this write-up, I’ll cover:

  • My approach to analyzing the challenge
  • Identifying React Server Components usage
  • The importance of version detection
  • How CVE-2025-55182 works in practice
  • Achieving code execution and retrieving the flag

This post focuses on methodology and educational content only.


Initial Access & Application Reconnaissance

After spawning the machine, I navigated to the target IP and was greeted with a clean Next.js SaaS-style interface:

Home Page

While the UI appeared benign, effective security assessments begin with framework analysis rather than surface-level inspection.


Analyzing JavaScript Sources for RSC Indicators

I opened DevTools and navigated to the Sources tab to inspect the /_next/static/ bundles. While examining the JavaScript chunks, I discovered a significant indicator:

Source Code Analysis

This keyword is a strong signal for React Server Components (RSC) because:

  • The Flight protocol uses specialized request markers
  • RSC actions require server-side deserialization
  • These markers only appear when the App Router is enabled

This discovery represents the first major confirmation that the application may be vulnerable.


Framework Version Fingerprinting

Next, I verified the framework version using Wappalyzer:

Wappalyzer Results

Result: Next.js 16.0.6

This version is significant because:

Next.js VersionStatus
16.0.6❌ Vulnerable (shipped with RSC v19.0.0–19.2.0)
16.0.7+✅ Patched

At this point, the vulnerability profile was clear:

  1. RSC detected
  2. Vulnerable Next.js version confirmed
  3. Public-facing server accessible

These factors provided high confidence for a vulnerability match.


Testing for CVE-2025-55182 Exposure

With the vulnerability confirmed, I proceeded to validate RSC exploitation potential using the publicly available proof-of-concept tool react2shell-scanner.

Testing command execution:

Whoami Command

The whoami command executed successfully, confirming:

  • The RSC endpoint is accessible
  • Vulnerable React Flight deserialization logic is active
  • Arbitrary server-side code execution is possible

This validates the core issue of CVE-2025-55182: deserializing untrusted RSC payloads into server action invocations.


Interactive Exploitation & Flag Retrieval

The tool provides an interactive shell mode. Using the find command, I enumerated .txt files on the server:

Find Command

Inside /app/, I located the flag file. Retrieving it:

Flag Retrieved

Flag obtained. Challenge complete.


Understanding the Vulnerability

CVE-2025-55182 exists because Next.js incorrectly trusts Flight payloads sent to RSC endpoints. Flight requests contain serialized objects representing server references, component tree values, and action identifiers.

In vulnerable versions, attackers can:

  1. Forge a Flight payload
  2. Redirect the deserializer into resolving crafted references
  3. Trick the server into executing code (often via Node.js built-in modules)

Because RSC endpoints are public, no authentication is required. This chain results in:

Pre-authentication Remote Code Execution

This explains the CVSS score of 10.0 (Critical).


Key Takeaways

This challenge demonstrates the critical nature of modern framework vulnerabilities. Traditional web application testing typically focuses on endpoints, parameters, and API routes. However, React Server Components introduce an entirely new attack surface:

  • A serialization protocol (Flight)
  • A hidden server function execution layer
  • Framework-driven server logic that developers don’t manually write

When frameworks control server-side behavior, vulnerabilities at the framework level can have catastrophic consequences. This challenge serves as an important reminder to stay current with framework updates and security patches.


Disclaimer: This write-up is for educational purposes only. Always practice ethical hacking and only test systems you have explicit permission to assess.

This post is licensed under CC BY 4.0 by the author.