3 min readJust now

–

On December 9th at 23:20, I got one of those emails you never want to see from your cloud provider.

Press enter or click to view image in full size

Nice.

A harmless little side server had quietly turned into someone else’s DDoS node.

And here’s the part that really bothered me:

• The React2Shell vulnerability (CVE-2025–55182) was reported to the React team on November 29.
• Public advisories and patches dropped on December 3.
• Threat actors started exploiting it within hours.
• It’s December 9, I’m getting abuse emails, and most devs I talk to still haven’t even heard the name React2Shell.

That gap between “security teams know” and “engineers actually patch” is exactly where are.

🤯 React2Shell in One Minute

React2Shell (CVE-2025–55182) is a critical, unauthenticated remote code execution bug in React Server Components’ “Flight” protocol. It hits:

• React 19.x
• Next.js 15.x / 16.x with App Router
• And other frameworks that embed React Server Components under the hood.

The worst part?

• A default production Next.js App Router app is exploitable.
• Attackers only need a crafted HTTP request.
• Exploitation has already been observed in the wild, with near-100% reliability in real setups.

Under the hood, it’s a classic unsafe deserialization problem in how RSC payloads are processed. The server trusts specially structured data more than it should, and attackers abuse that to get their own JavaScript executed on your server.

No login. No fancy tricks. Just “hit the endpoint, get a shell.”

🧬 How Your App Becomes a Zombie

The kill chain for React2Shell looks roughly like this:

1. Scan & exploit

Automated scanners hit every public React/Next.js endpoint they can find, firing RSC payloads tailored to React2Shell.

If your app uses vulnerable versions → they get remote code execution.

2. Drop a payload

Once they have code execution, they usually:

• Run recon commands (whoami, id, uname)
• Pull down shell scripts or post-exploitation frameworks
• Write files under /tmp or user directories

3. Monetize you

Common post-exploitation moves:

• Install XMRig or another cryptominer
• Scrape cloud credentials from environment variables and metadata services
• Pivot deeper into your cloud environment

4. Abuse your bandwidth

Once they control enough boxes, they point them all at a target IP.

That’s how I end up with a line in my inbox saying my droplet contributed 54,408 packets per second to a DDoS.

5. You notice last

• Abuse tickets from your cloud provider
• Bizarre CPU/network spikes
• Angry users and timeouts

At that point, “we’ll just change passwords” is security theatre. Someone has already executed arbitrary code as your app.

🧠 Final Thought (and a Small Ask)

If you’re looking for a tidy moral, here it is:

In 2025, your app is either part of someone’s patch notes, or part of someone’s threat intel slide deck. Choose early which one you prefer.

If you want the technical deep dives, read:

• react2shell.com — Lachlan’s original write-up and timeline
• https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
• https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/

If you want more stories from the blurry line between “cute side project” and “unwitting participant in global cyber operations” — plus more on MCP, LLM security, and agents misbehaving — you can follow me. :))