React2Shell is the name used for CVE-2025-55182, a critical remote code execution flaw in React Server Components. An unauthenticated attacker could send a crafted HTTP request to a Server Function endpoint and run code on the server. It was disclosed on December 3, 2025, has a CVSS score of 10.0, and is fixed in React 19.0.1, 19.1.2 and 19.2.1.
React2Shell (CVE-2025-55182, also tracked as CVE-2025-66478, which has since been rejected as a duplicate) is a critical deserialization vulnerability in React Server Components that enables remote code execution across Next.js deployments, quickly emerging as one of the most consequential security events in the modern web ecosystem. This article examines the five days following React2Shell’s public disclosure—how exploitation accelerated, how threat actors adapted their techniques, and why the risk expanded far beyond initial expectations. In a landscape where the transition from disclosure to active compromise happened almost instantly, React2Shell has become more than a single vulnerability; it is a systemic warning for the entire industry.
What CISOs Need to Know Now
Five days after the disclosure of React2Shell (CVE-2025-55182), the situation has shifted from a theoretical supply-chain concern to a fully active, multi-actor exploitation wave. What began as a deserialization flaw in React Server Components, reported on November 29, 2025 and disclosed with a fix on December 3, 2025 according to the React advisory, is now one of the most consequential security events the modern web ecosystem has faced since Log4Shell.
The uncomfortable truth: the window for silent, preventative patching is long gone.
We are now dealing with real intrusions, real credentials stolen, and real post-exploitation activity across the internet.
- CVE.
- CVE-2025-55182 (CVE-2025-66478 was rejected as a duplicate).
- Product.
- React Server Components.
- Severity.
- CVSS 10.0, critical.
- Affected versions.
- 19.0, 19.1.0, 19.1.1 and 19.2.0.
- Fixed versions.
- 19.0.1, 19.1.2 and 19.2.1.
- Disclosed.
- December 3, 2025.
What Has Changed by Day 5?
Full transition from disclosure → weaponization → active compromise
The initial “responsible disclosure period” was short: according to the React advisory, the flaw was reported on November 29, 2025 and published with fixes on December 3, 2025. We now observe widespread exploitation across:
– Opportunistic botnets
– Financially motivated actors launching miners
– State-aligned APT groups treating React2Shell as a high-fidelity entry point
China-nexus groups such as Earth Lamia and Jackpot Panda were among the first to adopt the exploit, an indicator that this vulnerability is being treated as a strategic foothold opportunity.
Are default Next.js deployments vulnerable out of the box?
React2Shell is a zero-config compromise. A default create-next-app build exposes the vulnerable RSC endpoint without the developer writing a single Server Action.
This dramatically expands the attack surface across SaaS vendors, media platforms, fintech environments, and startups relying on Next.js for rapid delivery.
WAFs are repeatedly bypassed
Day-2 managed rules from major cloud providers slowed down only the most basic scans.
Attackers are now using:
– Chunk reordering inside Flight protocol streams
– Unicode escaping
– JSON structure manipulation
– Keyword-free payload variants
…to walk past signature-based WAF controls with ease.
If a company is relying on WAF rules instead of patching, they are already compromised or will be.
Attack patterns have evolved beyond miners
Early exploitation focused on reconnaissance and cryptomining. Day 3–5 shows a clear escalation:
– Sliver C2 deployments
– MeshAgent installs disguised as legitimate remote management
– Environment variable dumping for cloud key harvesting
– Attempts at persistence on compromised containers
This is no longer “hit-and-run RCE.” It is long-term access preparation.
The biggest risk is not RCE itself — it’s stolen secrets
Once inside a Next.js server, attackers can access process.env, which often includes:
– AWS IAM keys
– Database credentials
– Stripe / Twilio / SendGrid API keys
– JWT signing secrets
– Session secrets
Patching the vulnerability does not invalidate secrets stolen on Day 1–4.
This is the core message for Day 5:
Rotate your secrets, or assume breach.
What Should Organizations Do About React2Shell Right Now?
Patch, rebuild, redeploy
Upgrading dependencies is not enough — the patched RSC code must be rebuilt into the production artifact. The same holds for the October 2026 Next.js and Node.js security updates.
Should you rotate all secrets?
Any organization patched after December 4 should treat secrets as compromised.
Hunt for indicators of compromise
Look for:
– Node.js processes spawning shells
– Outbound connections to known C2 IPs
– Modifications under /tmp
– Suspicious new .js files
Stop relying on WAF filtering
WAFs reduce noise, not risk.
Treat this as a supply-chain event, not a simple CVE
The industry is collectively relearning that frameworks can become single points of systemic failure.
- Patch, rebuild, redeployThe patched code must be rebuilt into the production artifact.
- Rotate all secretsThe post advises treating secrets as compromised if you patched after December 4.
- Hunt for indicators of compromiseNode.js processes spawning shells, odd outbound connections, changes under /tmp.
- Stop relying on WAF filteringWAFs reduce noise, not risk.
Day 5 Takeaway
React2Shell is no longer a theoretical vulnerability — it is an active mass-compromise event. APTs, botnets, and ransomware affiliates are all converging on the same entry point, and the organizations that delay patching or secret rotation will carry the highest long-term exposure.
– Patch the code.
– Rotate the keys.
– Hunt the network.
The vulnerability may be in the framework, but the risk is now in the credentials.
