React2Shell: Securing Your Stack and Your Supply Chain

Home / Blog / React2Shell: Securing Your Stack and Your Supply Chain

Monday / December 8, 2025 / Frank Konig / Cybersecurity / 0 Comments

Tags: JavaScript News Security Tutorial

My Weekend With React2Shell: Testing, Patching, and Mapping Exposure

CVE-2025-55182 stole my weekend. Here's what I learned patching 4 enterprise apps and assessing 139 vendors across 5 TPRM clients.

Friday afternoon, I started seeing chatter about a new React vulnerability. By Saturday morning, it was clear this wasn't going away—CVSS 10.0, unauthenticated RCE, public exploits, and reports of active exploitation. I spent most of the weekend digging into it, and figured I'd write up what I found in case it saves someone else some time.

1. What React2Shell Actually Is

On December 3rd, the React team disclosed CVE-2025-55182, a CVSS 10.0 vulnerability affecting React Server Components (RSC).

When I first heard the nickname "React2Shell," I assumed it was Twitter hype. Then I read the advisory... and realized it was dead accurate.

Here's the core issue: React Server Components deserialize incoming data before any application logic, middleware, or authentication runs. If an attacker can reach an RSC endpoint—even one you didn't know existed—they can send a crafted payload that triggers arbitrary code execution on the server.

The vulnerable packages:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

Affected versions: 19.0.0, 19.1.0, 19.1.1, 19.2.0
Patched versions: 19.0.1, 19.1.2, 19.2.1

Here's the kicker: you might be vulnerable even if you never used RSC intentionally.

Several frameworks ship with RSC endpoints exposed by default:

Next.js (13+)
React Router RSC
Waku
Vite RSC plugin
Parcel RSC
Turbopack-based apps

If your build pipelines pulled React 19 automatically (common with loose semver), you may have gone vulnerable without realizing it.

2. Why I Dropped Everything

A few things made this one feel urgent:

Remote, unauthenticated code execution — No login, no CSRF tokens, no cookies. Just reach the endpoint, send payload, get execution.
Pre-middleware execution — Your rate limiting, API gateway, or auth checks never run. The vulnerability hits before any of that.
Nearly universal exposure in frameworks — If your build tool added RSC endpoints, you might not know they exist.
Mass scanning began within 24 hours — Proof-of-concept payloads were extremely reliable. By December 4th, Amazon was reporting China-nexus groups actively exploiting it.
Many apps don't patch dependencies often — Lots of orgs freeze frontend dependencies, meaning they may be stuck on exactly the vulnerable versions.

3. How I Tested for Exposure

Between Saturday and Sunday I reproduced the exploit in a controlled environment, tested exposure on 4 internal enterprise apps, and helped 5 TPRM clients assess their vendors. Here's the exact process I used.

3.1 Check for reachable RSC endpoints

First, I ran these against each app:

# Main RSC endpoint
curl -I https://yourapp.com/_rsc

# Server Actions
curl -I https://yourapp.com/_next/server-actions

# React Router / Edge Runtime variant
curl -I "https://yourapp.com/react?__rsc__=1"

# POST handling (the actual exploit path)
curl -X POST -I https://yourapp.com/_rsc

Here's how I interpreted the responses:

Response	What it means
404 / 405	Likely not exposed
200	Endpoint exists — investigate further
500	Endpoint reachable but failing — still exposed
`Content-Type: text/x-component`	Definitely an RSC endpoint
RSC exceptions in response body	Endpoint is live

If you get anything other than a clean 404, assume exposure until proven otherwise.

3.2 The universal probe (most reliable)

The most reliable test I found came from Assetnote. This works against any route—even / or a non-existent path:

curl -X POST https://yourapp.com/ \
  -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad" \
  --data-binary $'------WebKitFormBoundaryx8jO2oVc6SWP3Sad\r\nContent-Disposition: form-data; name="0"\r\n\r\n["$1:a:a"]\r\n------WebKitFormBoundaryx8jO2oVc6SWP3Sad\r\nContent-Disposition: form-data; name="1"\r\n\r\n{}\r\n------WebKitFormBoundaryx8jO2oVc6SWP3Sad--\r\n'

Vulnerable: HTTP 500 with E{"digest" in the body
Not vulnerable: 4xx, or 500 without that digest string

This probe only triggers an error condition—it doesn't actually execute anything—so it's safe to run against production if you need to.

Assetnote also released a bulk scanner: github.com/assetnote/react2shell-scanner

3.3 Confirming package versions

Even if the endpoint checks came back clean, I wanted to verify versions directly. Most of our Node apps live in /var/www/ or /opt/, so I SSH'd in and ran:

cd /var/www/your-app

# Check for vulnerable packages
npm ls react-server-dom-webpack
npm ls react-server-dom-parcel
npm ls react-server-dom-turbopack

# Or grep the lockfile
grep '"react-server-dom' package-lock.json | grep '"version"'

# For Yarn or pnpm
yarn why react-server-dom-webpack
pnpm list react-server-dom-webpack

If you see 19.0.0–19.2.0, upgrade immediately:

npm install [email protected]

Then rebuild and redeploy.

One thing that tripped me up: Next.js bundles React internally (they call it "vendored"), so standard dependency scanners sometimes don't flag it. I had to check the Next.js version separately and cross-reference with Vercel's advisory.

Vulnerable Next.js versions: 15.0.4, 15.1.8, 15.2.5, 15.3.5, 15.4.7, 15.5.6, 16.0.6, plus canary releases from 14.3.0-canary.77 onward.
Patched Next.js versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

If you're on a 14.x canary, the guidance is to downgrade to stable:

npm install next@14

4. Hardening: Reducing the Attack Surface

Even patched, this category of bug may reappear. Here's what I'm recommending to clients:

Block RSC endpoints at the edge

If you don't need RSC exposed publicly, block the paths:

Nginx:

location ~ ^/_rsc {
    return 404;
}

location ~ ^/_next/server-actions {
    return 404;
}

Cloudflare / Fastly / Akamai: Block paths beginning with /_rsc or /_next/server-actions.

Pin dependency versions

Avoid semver ranges like ^19.0.0 that auto-upgrade into vulnerabilities.

Add build-time alerts

Fail CI if React or RSC packages bump unexpectedly.

Network segmentation

For internal tools, put them behind Cloudflare Zero Trust or a VPN rather than relying on app-level auth.

Scan for accidental RSC imports

Many devs didn't realize their frameworks shipped React Server Components under the hood.

5. Sunday: The Third-Party Problem

By Sunday I'd made decent progress on the technical side, but my week was about to get more complicated. I do TPRM work for a number of companies, and I knew what was coming: clients asking about their vendors.

I decided to get ahead of it. Pulled up the critical vendor lists across my client base and started working through them. 139 unique vendors by the time I was done counting. Nine hours later, I had... well, a start.

5.1 Using rating platforms to narrow things down

There was no way I was going to blast all 139 vendors with a questionnaire on a Sunday. So I started by checking the cyber rating platforms to see which ones might actually be running React or Next.js.

In BitSight: I looked at the "Technologies" section in each vendor's profile for React, Next.js, Vercel, or Node.js indicators. The portfolio filtering helped speed things up.

In SecurityScorecard: The "Digital Footprint" section sometimes shows technology stack details. Same approach—filtering for JavaScript frameworks.

In RiskRecon: The "IT Profile" or "Technology" data was useful here. Filtered by web framework and JavaScript library detections.

This got me down to a shorter list of vendors that were likely running something React-based. Not perfect—these platforms can't tell you if a vendor is running a vulnerable version, or whether they've patched—but it beats guessing.

5.2 Manual fingerprinting for the gaps

For vendors where the rating platforms didn't have technology data, I did some manual checking:

Indicator	Where to look	What it suggests
`/_next/` in URLs	Browser network tab, page source	Next.js
`__NEXT_DATA__` script tag	View page source	Next.js with data fetching
`x-powered-by: Next.js`	Response headers	Next.js confirmed
`/_next/static/` assets	Network requests	Next.js static assets

If I saw those indicators, that vendor went on the outreach list.

5.3 The outreach (starting today)

I've got my list. Now comes the part I'm not looking forward to: actually sending the emails.

Here's the template I'm planning to use:

Subject: Security Inquiry: CVE-2025-55182 (React2Shell)

Our security monitoring flagged that [application name] appears to use Next.js or React Server Components. We wanted to check in about CVE-2025-55182, the RCE vulnerability disclosed on December 3rd.

Could you confirm:

Whether your systems use React Server Components or Next.js with App Router

If affected, whether patches have been applied

If not yet patched, your expected timeline

Whether you have interim protections in place (WAF rules, etc.)

Happy to discuss further if helpful. Given the active exploitation reports, we're trying to get responses within the next few days if possible.

5.4 How I'm planning to bucket responses

Once replies start coming in, here's roughly how I'll be categorizing them:

What they say	My read	Next step
"We patched, here's our changelog"	Solid	Document and move on
"We're patched" (no details)	Probably fine, but...	Ask for attestation or scan results
"We're protected by Cloudflare/Vercel"	Better than nothing	Ask for a patch timeline
"We're looking into it"	Concerning	Set a follow-up, flag for the client
No response	TBD	Follow up mid-week

5.5 Hosting provider protections

Some vendors mentioned they were protected by their hosting provider even though they hadn't patched yet. For context:

Vercel: Deployed runtime-level protections (not just WAF rules)
Cloudflare: Pushed WAF managed rules for this CVE
AWS WAF: The AWSManagedRulesKnownBadInputsRuleSet includes blocking rules
Google Cloud Armor: Rules available

These aren't substitutes for patching, but they lower the immediate risk. I'm still asking for patch timelines, but these vendors aren't at the top of my worry list.

Side note: I use Cloudflare myself, and I'm honestly not 100% sure how much protection their managed rules are actually providing here—whether it's blocking exploit attempts outright or just logging them. It's on my list to dig into this week. If anyone has clarity on what the Cloudflare rules actually do for this CVE and how/what needs to be done for enforcement, I'm all ears.

6. Timeline

Date	What happened
November 29	Lachlan Davidson reports the vulnerability to Meta's bug bounty
November 30	Meta confirms and starts working on a fix
December 1	Fix created; coordination with hosting providers begins
December 3	Patches published to npm; CVE-2025-55182 disclosed
December 4	Public PoC released; Amazon reports China-nexus exploitation

7. Where I'm At

That was my weekend. Nine hours on vendor reviews, preparing all the vendor emails and doing my best to minimize the intrusion, while get responses, and a week ahead of following up and documenting everything for clients.

The short version of what I've learned so far:

The Assetnote probe I found to be the most reliable way to check direct exposure
Rating tools can help narrow down which vendors to focus on, but they won't tell you who's patched
Getting actual answers still means reaching out and waiting
Document everything—clients will want records, and so will auditors
To reduce the TPRM questionnaires/customer questions for the apps I have created, we updated our Security Page.

I'll probably update this once I've heard back from more vendors and have a better sense of how this shakes out. For now, if you're in the same boat, good luck—and pace yourself. This one's going to take more than a weekend.

References

Comments (0)

No comments yet. Be the first to comment!