DEV Community

Cover image for React2Shell: The Critical RCE Vulnerability Every Next.js Developer Must Address Now
martin rojas
martin rojas

Posted on • Originally published at nextsteps.dev

React2Shell: The Critical RCE Vulnerability Every Next.js Developer Must Address Now

#react #nextjs #security

You've built your Next.js application using the App Router, deployed it to production, and moved on to the next feature. Then December 4th happened. Public exploits dropped for React2Shell—a critical remote code execution vulnerability affecting React Server Components—and within hours, state-sponsored threat actors were actively targeting vulnerable applications. If your production Next.js app is running versions 15.0.0 through 16.0.6, you may already be compromised.

This isn't hyperbole. CVE-2025-55182 carries the maximum CVSS score of 10.0, requires no authentication, and can be triggered with a single HTTP request against default Next.js configurations. Security researchers report near-100% exploitation success rates, and cloud security vendors have observed cryptomining campaigns, credential harvesting, and persistent backdoors deployed through this vulnerability within days of public disclosure.

Let's walk through what's happening under the hood, how to determine if you're affected, and the immediate steps you need to take to secure your applications.

Understanding the Attack Surface

React Server Components introduced a communication protocol called "Flight" that handles serialization and deserialization between server and client. When your Next.js application processes form submissions or server function calls, it uses this protocol to decode incoming payloads. The vulnerability lies in how React's deserialization logic handles malformed payloads—specifically, how it traverses prototype chains when resolving references.

The technical mechanism involves manipulating special chunk references in multipart form data. React's Flight protocol uses $-prefixed strings to trigger specific behaviors and resolve references. By crafting payloads with carefully constructed __proto__, constructor, and prototype references, attackers can escape the intended object boundaries and execute arbitrary JavaScript on your server.

What makes this particularly severe is the default exposure. A standard project generated with create-next-app using the recommended settings enables the App Router, which includes React Server Components and exposes the vulnerable endpoints—even if your application doesn't explicitly use server functions. The mere presence of RSC support creates the attack surface.

Here's what the attack flow looks like:

Attacker crafts malicious multipart/form-data POST request
    ↓
Request reaches Next.js server with RSC-enabled route
    ↓
Flight protocol deserializes payload
    ↓
Prototype chain traversal triggers arbitrary code execution
    ↓
Attacker has server-side RCE with application privileges
Enter fullscreen mode Exit fullscreen mode

From that initial foothold, attackers have been observed exfiltrating environment variables (including database credentials and API keys), dropping cryptominers, establishing reverse shells, and deploying persistent backdoors.

Are You Affected? Assessment Checklist

The vulnerability affects these specific packages and versions:

React packages (CVE-2025-55182):

  • react-server-dom-webpack: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-parcel: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-turbopack: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0

Next.js (tracked as GHSA-9qr9-h5gf-34mp):

  • All stable versions from 15.0.0 through 16.0.6
  • Canary versions 14.3.0-canary.77 and later
  • Canary versions prior to 15.6.0-canary.58

Other affected frameworks using React Server Components:

  • react-router (with unstable RSC APIs)
  • waku
  • @parcel/rsc
  • @vitejs/plugin-rsc
  • rwsdk

To quickly check your deployed version, open your browser's developer console on any page of your application and run:

// Returns your deployed Next.js version
next.version
Enter fullscreen mode Exit fullscreen mode

Or check your package.json and lockfile:

# Check package.json
cat package.json | grep '"next"'

# Check actual resolved version in lockfile
npm ls next
# or
yarn why next
# or  
pnpm why next
Enter fullscreen mode Exit fullscreen mode

Vercel users should see a dashboard banner if production deployments are running vulnerable versions. However, don't rely solely on this—verify your versions directly.

Important: Applications are vulnerable even if they don't explicitly use server functions, as long as they support React Server Components. If your Next.js app uses the App Router (has an app/ directory), you should assume vulnerability unless you're running a patched version.

Immediate Remediation Steps

Step 1: Identify Your Current Version and Upgrade Path

Reference this table to find your specific patched version:

Currently Running Upgrade To
Next.js 15.0.x 15.0.5
Next.js 15.1.x 15.1.9
Next.js 15.2.x 15.2.6
Next.js 15.3.x 15.3.6
Next.js 15.4.x 15.4.8
Next.js 15.5.x 15.5.7
Next.js 16.0.x 16.0.7
Next.js 14 canaries (≥14.3.0-canary.77) Downgrade to 14.2.x stable
Next.js 15 canaries (<15.6.0-canary.58) 15.6.0-canary.58 or later

Step 2: Apply the Fix

Vercel has released an automated fix utility. In your project root:

npx fix-react2shell-next
Enter fullscreen mode Exit fullscreen mode

This scans your project for vulnerable packages and upgrades them to patched versions. For manual upgrades:

# Update package.json to patched version
npm install next@15.3.6  # Replace with your target version

# Ensure lockfile is updated
npm install

# Verify the update
npm ls next
Enter fullscreen mode Exit fullscreen mode

Critical: Always commit lockfile changes with package.json changes. Mismatched lockfiles are a common source of failed patches.

Step 3: Deploy Immediately

Once tested locally, deploy without delay:

Step 4: Rotate All Secrets

This is the step teams often skip—don't skip it. If your application was publicly accessible and unpatched as of December 4th, 2025 at 1:00 PM PT (when public exploits emerged), assume your environment variables have been compromised. Rotate in priority order:

  1. Database credentials
  2. Third-party API keys (Stripe, SendGrid, AWS, etc.)
  3. OAuth client secrets
  4. JWT signing keys
  5. Internal service authentication tokens

For Vercel deployments, their documentation on rotating secrets provides a systematic approach. The process involves generating new credentials in each service, updating your Vercel environment variables, redeploying, and then invalidating the old credentials.

Post-Exploitation Detection

Determining whether your application was exploited isn't straightforward. However, several indicators warrant investigation:

Log analysis: Review application logs for unusual POST requests, particularly to routes you didn't explicitly configure. Look for:

  • Unexpected multipart/form-data requests
  • Requests with malformed or suspicious content-type headers
  • Spikes in 500 errors from RSC routes
  • Function timeout patterns (though successful exploits often complete without timeouts)

Runtime anomalies:

  • Unexpected processes running in your container environment
  • Unusual network connections to external hosts
  • DNS queries to unfamiliar domains
  • CPU usage spikes inconsistent with traffic patterns

Common post-exploitation behaviors observed in the wild:

  • Attempts to access cloud metadata services (169.254.169.254)
  • Environment variable exfiltration
  • Cryptominer installation (often disguised as system processes like systemd-devd)
  • Reverse shell establishment
  • Persistent cron jobs or process respawners

If you identify suspicious activity, treat it as a confirmed breach: isolate affected systems, preserve logs for forensic analysis, and engage your incident response procedures.

Defense in Depth: Additional Protections

While patching is the only complete fix, layered defenses provide breathing room:

Web Application Firewall rules: Major WAF providers have deployed rules targeting known exploit patterns. Vercel applied WAF mitigations globally prior to public disclosure, AWS WAF's AWSManagedRulesKnownBadInputsRuleSet includes CVE-2025-55182 rules, and Cloudflare, Fastly, and other providers have similar protections. Note that WAF rules cannot guarantee protection against all variants—they're a stopgap, not a solution.

Deployment protection: Enable authentication for non-production deployments. In Vercel, Standard Protection prevents unauthorized access to preview deployments. Audit any shareable links that bypass deployment protection.

Network segmentation: Limit outbound connectivity from application containers where possible. This constrains an attacker's ability to exfiltrate data or establish command-and-control channels even if they achieve code execution.

Metadata service hardening: If running in cloud environments, restrict access to instance metadata services. Use IMDSv2 (AWS), or equivalent protections on other platforms.

What This Means for React Server Components

This vulnerability reveals a fundamental challenge with server-side JavaScript deserialization. The Flight protocol's complexity created opportunities for prototype pollution attacks—a class of vulnerability that's notoriously difficult to eliminate entirely in JavaScript. The React team deserves credit for rapid response (patch within days of responsible disclosure), but this incident raises questions for teams evaluating RSC adoption.

For existing Next.js applications: the App Router and React Server Components remain powerful tools for building performant applications. The patched versions address the specific deserialization flaw. Continue using RSC with confidence once you've upgraded.

For teams evaluating new projects: this vulnerability shouldn't dissuade you from React Server Components, but it's a reminder that server-side rendering introduces server-side risks. Factor security monitoring and update procedures into your architecture planning.

For those still on Next.js 14 stable (Pages Router only): you're not affected by this specific vulnerability, but you're also not receiving active feature development. Plan your migration path deliberately rather than reactively.

Timeline of Events

  • November 29, 2025: Lachlan Davidson reports vulnerability to Meta Bug Bounty
  • November 30, 2025: Meta security confirms and begins fix development
  • December 1-2, 2025: Coordination with hosting providers and framework maintainers
  • December 3, 2025: Public disclosure as CVE-2025-55182; patches released
  • December 4, 2025 (afternoon PT): Public proof-of-concept exploits emerge
  • December 4-5, 2025: Active exploitation observed by Amazon, Wiz, GreyNoise, Datadog
  • December 5, 2025: Vercel releases fix-react2shell-next CLI tool
  • December 8, 2025: Vercel Agent automated PR capability for vulnerable projects

Next Steps for Your Team

  1. Immediate (today): Verify all production Next.js applications are running patched versions. Deploy fixes for any that aren't.

  2. This week: Rotate secrets for any application that may have been exposed. Review logs for indicators of compromise.

  3. This month: Audit deployment protection settings. Ensure preview and staging environments aren't publicly accessible without authentication.

  4. Ongoing: Establish a security update process. This won't be the last critical framework vulnerability, and response time matters.

The React and Vercel teams handled disclosure and patching responsibly, but the rapid weaponization—with state-sponsored actors exploiting the vulnerability within hours—demonstrates the compressed timelines security teams now face. Building security responsiveness into your development workflow isn't optional anymore.

Sources

Top comments (0)