React2Shell (CVE-2025-55182): the CVSS 10 RCE haunting the React and Next.js ecosystem

Every few years, a vulnerability lands with such a vast attack surface that it forces the entire industry into an emergency patching scramble. In 2021, it was Log4Shell. In late 2025, it's React2Shell — officially CVE-2025-55182, a pre-authentication remote code execution rated CVSS 10.0 that strikes at the heart of React Server Components (RSC) and, by extension, the massive Next.js ecosystem. Six months after disclosure, it remains actively exploited: that is precisely what makes it a textbook case every web developer shipping React 19 needs to understand.

The nickname isn't marketing flourish. Like Log4Shell, React2Shell ticks every box on the nightmare checklist: a single HTTP request is enough, default configurations are vulnerable, the exploit is close to 100% reliable, and the malicious code runs without authentication. Let's break down the root cause, the real-world attack chain seen in the wild, and the only remediation that actually holds up.

What exactly are we talking about?

CVE-2025-55182 (which also encompasses CVE-2025-66478, the Next.js-side identifier) is an insecure deserialization vulnerability in the handling of React Server Components' internal protocol. It lets an unauthenticated attacker run arbitrary system commands on the server through a specially crafted HTTP payload.

The flaw was responsibly reported by security researcher Lachlan Davidson on 29 November 2025. The fix and public disclosure followed on 3 December 2025. The shift to active exploitation was lightning-fast: telemetry from several vendors shows the move from disclosure to mass exploitation happening within hours, with automated scanners and hands-on-keyboard operators alike.

Root cause: the "Flight" protocol and deserialization

To understand the flaw, you need to understand how RSC works. React Server Components lets part of the rendering logic run on the server rather than in the browser, which lightens the client and improves performance. To shuttle component trees and server function calls between client and server, RSC relies on an internal serialization protocol called "Flight".

That's where it all comes apart. The vulnerability lives in the react-server package and its handling of the Flight protocol: when it receives a malformed RSC payload, the server fails to properly validate the structure before deserializing it. This logical deserialization, combined with command-execution paths in the processing of RSC requests, opens the door to arbitrary code execution. It's the classic pattern of the great deserialization RCEs: attacker-controlled data treated as trusted code.

Why it's so dangerous

What turns a bug into an industry-wide catastrophe is that it affects default configurations:

• A standard Next.js application generated with create-next-app and compiled for production is exploitable with no code changes whatsoever by the developer.
• Server actions, enabled by default and reachable via well-known routes, expose the vector without the team even being aware of it.
• The exploit shows close to 100% reliability and accepts a wide variety of payload formats, which makes signature-based filtering hard.
• Merely having a vulnerable package in the dependency tree is often enough to make the system exploitable.

Affected versions and fixes

The scope is broad, matching the adoption of React 19.

The intense community research that followed disclosure surfaced three additional React vulnerabilities (CVE-2025-55183, CVE-2025-55184 and CVE-2025-67779), of more limited impact (information disclosure, denial of service). Worth noting: CVE-2025-67779 was born from an incomplete fix for CVE-2025-55184 — a reminder that half-patching can reopen a door.

The attack chain observed in the wild

Attackers primarily target internet-exposed Next.js frontends and RSC workloads running in cloud environments: Kubernetes clusters, managed PaaS platforms. If you run this kind of stack, the article on hardening Kubernetes 1.36 provides the defense-in-depth context that's relevant here.

Phase 1 — Reconnaissance

Once a shell is obtained inside a container or VM, operators profile the host: whoami, hostname, dumping environment variables, reading /etc/passwd. This is followed by DNS and HTTP beaconing through OAST-style domains to verify outbound connectivity and map the environment.

Phase 2 — Payload installation

Attackers then deploy scripts via wget, curl, chmod and BusyBox, often with Base64-encoded commands. On the menu: Linux droppers for persistence, Mirai loaders, and — by far the most common — XMRIG cryptocurrency miners.

Phase 3 — Actors and objectives

The range of attackers is wide. The Google Threat Intelligence Group observed widespread exploitation spanning opportunistic cybercriminals to suspected espionage groups, with campaigns deploying a MINOCAT tunneler, a SNOWLIGHT downloader, and the HISONIC and COMPOOD backdoors. Microsoft detected activity as early as 5 December 2025, mostly coin miners. Unit 42 (Palo Alto) documented a more sophisticated actor, CL-STA-1015 — an initial access broker suspected of links to China's Ministry of State Security — installing the SNOWLIGHT and VShell trojans. Wiz, for its part, observed a pivot toward cloud credential theft and mining.

Remediation: the WAF won't save you

This is the most misunderstood point of the whole episode. A web application firewall (WAF) is only a temporary stopgap. Because the exploit accepts multiple payload formats, attackers trivially bypass signature-based blocking. WAF rules buy time; they guarantee nothing.

The only reliable fix comes down to two words: patch and redeploy, immediately. Concretely:

1. Inventory your dependencies: npm ls react react-dom next on every project, including transitive dependencies.
2. Update to React 19.0.1 / 19.1.2 / 19.2.1 and the corresponding patched Next.js version, then rebuild and redeploy to production (a plain npm update without a rebuild does not protect an already-compiled artifact).
3. Hunt for compromise: look for xmrig processes, outbound connections to unknown OAST domains, binaries dropped in /tmp, suspicious cron jobs. An exploited RCE means you have to audit the host, not just patch.
4. Rotate any secret reachable from the compromised container (cloud keys, tokens) — credential theft has been observed.

Finally, know that the barrier to exploitation is rock bottom: a public exploit repository and an official Nuclei template are now circulating. Any still-vulnerable server is a target within reach of an automated scan. For broader host hardening, see the Linux server hardening checklist.

FAQ

Is my Next.js application vulnerable if I don't explicitly use Server Components?

Potentially yes. The danger of React2Shell stems precisely from the fact that RSC and server actions are enabled by default in modern Next.js configurations (App Router). An application generated with create-next-app and deployed as-is can be exposed. Don't assume that "I don't use it" protects you: check the installed versions and patch. Having the vulnerable package in the dependency tree is often enough.

Can a WAF or Cloudflare block exploitation while waiting for the patch?

Partially and temporarily only. The managed rules from major providers block known payloads, but the exploit accepts many variants that bypass signature-based filtering. Treat the WAF as buying a few hours to patch, never as durable protection. The only reliable remediation remains updating packages and redeploying.

How do I know if my server has already been compromised?

Look for the typical post-exploitation indicators: mining processes (xmrig), unexplained CPU spikes, outbound connections to OAST domains or unknown C2 infrastructure, recent binaries in /tmp, crontab modifications, and attempts to read /etc/passwd or dump environment variables in your application logs. When in doubt, treat the host as compromised: isolate it, rotate secrets and rebuild from a clean image.

Why is React2Shell compared to Log4Shell?

Because they share the DNA of catastrophic "one-shot" RCEs: a deserialization path, a massive attack surface (an omnipresent ecosystem), minimal prerequisites for the attacker, and a trigger as simple as a single request. Log4Shell showed that a deserialization flaw could threaten global infrastructure almost overnight. React2Shell replays that scenario across the JavaScript ecosystem, where Next.js powers a huge share of recent web applications.

Conclusion: deserialization, again and again

React2Shell is a reminder of a lesson the industry relearns every cycle: deserializing untrusted data is granting it the right to execute. RSC's Flight protocol merely added a new façade to an anti-pattern as old as RPC itself. The fact that the flaw affects the default configurations of a framework as widespread as Next.js makes it one of the most significant web security incidents since Log4Shell.

The good news is that remediation is simple and well known: update, rebuild, redeploy, audit. The bad news is that six months after disclosure, scanners keep finding targets — proof that the software supply chain remains our collective weak link. If you run React 19 in production and haven't checked your versions since December, do it now: the window between "exposed" and "mined" is measured in hours.