React 19 - Vulnerability Emergency
Introduction
When React2Shell (CVE-2025-55182) dropped on December 3rd, it didn't behave like a normal vulnerability. It behaved like a zero-day suddenly made public.
Because React Server Components are enabled by default in modern frameworks — especially Next.js — thousands of production systems were exposed without knowing it. And while teams were still reading the advisory, attackers were already exploiting it.
This report explains exactly what React2Shell is, how it works, who is exploiting it, what real compromises look like, and what actions you should take immediately.
Main Takeaways
- Critical RCE (CVSS 10): attackers can execute code remotely with no authentication.
- Default frameworks were affected — most teams using modern Next.js were vulnerable even if they didn't realize they were using RSC.
- Exploitation was observed within hours and successful compromises within the first 24 hours.
- Multiple advanced threat actors (Earth Lamia, Jackpot Panda) and opportunistic botnets are exploiting it.
- Real compromises include miners, backdoors, Cobalt Strike, Sliver, and custom campaigns.
- Time to mass exploitation: ~3–4 days after disclosure.
- If your patch took longer than 4 days, assume you've been scanned and investigated now.
- If you had been on Kolega.dev, you would have been fully remediated within 2 hours of disclosure — days before mass campaigns started. We're able to respond to ecosystem events faster than the threat actors can scale up.
1. What React2Shell Actually Is (Simple Version)
On December 3, 2025, a critical vulnerability was disclosed in React Server Components (RSC)called React2Shell, tracked as CVE-2025-55182.
It's rated CVSS 10.0 and is a pre-authentication remote code execution (RCE) bug – the worst category: an attacker can run code on your server without logging in.
Where it lives:
React2Shell is an unsafe deserialization flaw in the Flight protocol used by React Server Components. When the server receives an RSC/Flight payload from the client and deserializes it, a malicious payload can trick the runtime into executing attacker-controlled code.
So in dev terms:
- • Your browser sends a serialized RSC payload.
- • The server parses / deserializes it.
- • Because of a bug in that deserialization step, the attacker can turn that into RCE on the server.
If your app uses Next.js App Router, React Server Components, or Server Actions, this is directly relevant to you.
2. Why This Vulnerability Is So Widespread
React2Shell wouldn't be terrifying if only a tiny number of people used RSC.
Unfortunately, that's not the world we live in.
Default-ish: common frameworks turned this on for you
- • React 19.0.0–19.2.0 RSC packages are affected, including:
- -
react-server-dom-webpack - -
react-server-dom-parcel - -
react-server-dom-turbopack
- -
- • These packages are used by Next.js 15.x and 16.x App Router and other RSC-aware frameworks.
- • TechRadar explicitly calls out that default configurations of common frameworks (Next.js, React Router, Waku, Parcel RSC, Vite RSC, etc.) are impacted.
Most teams start a project with something like:
npx create-next-app@latestThat typically gives you:
- • App Router enabled
- • Server Actions enabled
- • RSC enabled under the hood
You didn't have to do anything exotic. For many teams, React2Shell was "on" the moment they scaffolded a default app.
3. Versions Impacted
Vulnerable RSC/React versions:
- • React Server Components 19.0.0
- • 19.1.0
- • 19.1.1
- • 19.2.0
Patched versions:
- • 19.0.1
- • 19.1.2
- • 19.2.1 and later
The Next.js advisory for CVE-2025-66478 (now folded into CVE-2025-55182) directs users to upgrade to patched Next.js releases and even provides npx fix-react2shell-nextto bulk-update affected apps.
4. What Makes React2Shell So Dangerous
Three key properties make this a "drop everything and patch" situation.
4.1 Pre-auth remote code execution
This is a pre-authentication RCE bug.
An attacker just needs:
- • Network access to your RSC/server action endpoint, and
- • A crafted Flight payload.
They do not need:
- • Credentials
- • A session cookie
- • Any role/permission in your app
4.2 One malicious request is enough
React2Shell is a multi-stage exploit chain (four "locks" being picked in sequence) that ends in arbitrary code execution in the server context.
From the attacker's perspective, it boils down to:
"Send one carefully crafted RSC payload → get my code to run on your server."
4.3 It lives in the framework layer, not your business logic
The vulnerable code is inside the RSC runtime / Flight deserialization logic, not in your own app modules. The issue is unsafe deserialization of payloads from HTTP requests to Server Function endpoints.
So even if your own handlers are well-written and validated, the framework can be tricked before your code even runs.
5. The Exploitation Timeline (Hours, Not Weeks)
5.1 Series of Events
Much of the following is based on reporting by the great work at Trend Micro and Huntress.
📅 December 3, 2025
- • CVE-2025-55182 published, React advisory released.
- • First in-the-wild exploitation observed the same day
- • First public PoC (lachlan2k) posted to GitHub, quickly reused by others.
📅 December 4, 2025
Huntress reports the first recorded successful exploitation on a Windows endpoint:
- • Attacker exploited a vulnerable Next.js instance.
- • Dropped a shell script.
- • Then downloaded and executed:
- - A cryptocurrency miner.
- - A Linux backdoor.
In additional observed intrusions, attackers used public GitHub tools to scan for vulnerable Next.js servers before exploiting.
📅 December 5, 2025
Long term intrusion operations begin leveraging:
- • Coordinated infrastructure
- • Purpose-built tooling
- • Scripted exploitation runs
- • Possibly thousands of targets scanned
Notable events:
- • Go-based backdoor dropped in real-world attacks.
- • First Cobalt Strike beacon deployed via React2Shell.
- • First Sliver implant observed.
- • "Emerald" campaign first identified.
📅 December 6, 2025
- • "Nuts" campaign first observed.
- • "Secret-Hunter" payload first seen.
- • CISA adds CVE-2025-55182 to the KEV (Known Exploited Vulnerabilities) catalog, confirming active exploitation.
📅 December 6–7, 2025
Telemetry shows a marked spike in exploitation volume, as more actors and bots adopt the exploit.
Takeaway:
- Time to first exploitation: hours
- Time to first successful compromise: ~1 day
- Time to coordinated campaigns & implants: 2–3 days
- Time to mass scanning and automated exploitation: ~4 days
That's the real "SLO" you're up against when patching React2Shell.
5.2 - Visualizations of malicious activity
Datadog have published visualizations of how the malicious activity has spiked over time. Within 1 day, hackers were trying to leverage the exploit and within 2 days, the activity spiked heavily.
6. Who Is Actively Exploiting React2Shell?
6.1 State-linked threat actors
According to AWS's security blog and related reporting, within hours of public disclosure on Dec 3:
- • Amazon's threat intel teams saw active exploitation attempts by multiple China-nexus threat groups, including:
- - Earth Lamia
- - Jackpot Panda
- • These groups targeted organizations in:
- - Finance
- - Retail & e-commerce
- - Logistics & transportation
- - IT & cloud services
- - Education
- - Government and critical infrastructure
- • Their objectives included:
- - Establishing persistent backdoors
- - Conducting cyber-espionage
- - Building footholds for later operations
Other coverage (TechRadar, industrial cyber news) confirms that these China-nexus actors rapidly integrated React2Shell into their playbooks.
6.2 Opportunistic attackers & botnets
Trend Micro, Rapid7, Wiz, Qualys and others report:
- • Dozens of PoCs, scanners, and exploit tools appeared publicly within days, many low-quality but enough functional ones to drive real attacks.
- • Honeypots began seeing:
- - Replays of the original PoC with modified payloads.
- - Opportunistic attempts to install cryptominers.
- - Tooling to automatically discover vulnerable Next.js/RSC instances.
Sophisticated operators and commodity botnets are both in the game.
7. Known Successful Exploits (What Has Actually Happened)
This section is about real compromises, not just scanning.
7.1 Endpoint and server compromises
Huntress and The Hacker News have documented cases where React2Shell exploitation led to:
- • Dropping shell scripts via vulnerable Next.js endpoints.
- • Installing XMRig crypto miners on Linux hosts.
- • Deploying Linux backdoors for persistent access.
- • Issuing reconnaissance commands (
whoami,id,uname -a). - • Attempting multiple downloads from attacker-controlled C2 infrastructure.
7.2 Post-exploitation tooling
Trend Micro's PoC/ITW analysis and Wiz's threat research describe campaigns that:
- • Use React2Shell as the initial access vector, then:
- - Deploy Cobalt Strike beacons.
- - Deploy Sliver implants.
- - Use custom backdoors like PeerBlight and tooling like Fast Reverse Proxy (FRP).
- • Target a mix of cloud-hosted and on-prem RSC deployments.
7.3 Are big-name companies publicly confirmed?
So far:
- • CISA confirms that CVE-2025-55182 is actively exploited, enough to be added to the KEV catalog.
- • AWS, Trend Micro, Huntress, Wiz, Qualys and others state that multiple real organizations across many sectors have been compromised.
But as of December 11, 2025, no Fortune-500-style company has put out a public statement explicitly saying:
"We were breached because of React2Shell (CVE-2025-55182)."
That's not unusual: attribution to a specific CVE often appears later, if ever.
While no major company has yet publicly named React2Shell as the root cause of a breach, threat intel and CISA's KEV listing confirm that real compromises across multiple sectors have already happened.
8. What You Should Do Right Now
We're not doing a full forensics playbook here, just the essentials for engineers.
8.1 Patch React & RSC
Upgrade to patched RSC / React versions:
- • React 19.0.1, 19.1.2, 19.2.1 or later.
- • Matching patched versions of:
- -
react-server-dom-webpack - -
react-server-dom-parcel - -
react-server-dom-turbopack
- -
8.2 Patch your framework
- • Next.js
- - Follow the official CVE-2025-66478/React2Shell advisory.
- - Upgrade to patched versions in your major line (15.x / 16.x).
- - Consider running
npx fix-react2shell-nextto auto-update affected apps.
- • Other RSC frameworks (React Router RSC, Vite/Parcel RSC plugins, Redwood, Waku)
- - Follow their specific advisories; all now reference CVE-2025-55182 as the root issue.
8.3 Investigate if someone has compromised your servers
There is a very real possibility you may have been hit by this exploit - even if patched within days. We recommend this article by dynatrace to help you detect any exploitation activity.
9. Why Teams Using Kolega.dev Were Safer
Kolega.dev is built with rapid remediations of these types of vulnerabilities in mind.
9.1 The timeline with Kolega.dev
- • Disclosure day (Dec 3, 2025)
- - React2Shell is published; PoCs and in-the-wild exploitation begin the same day.
- - China-nexus groups start exploiting within hours.
If you were on kolega.dev, that same window would look like:
1. Minutes after disclosure
- • Kolega ingests the vulnerability once it is publicly disclosed.
- • It automatically maps them to your real stack:
- - Which repos use React 19.x
- - Which services use RSC/App Router
2. Within the first hour
- • Kolega opens focused incidents tickets:
- - Lists exact affected services & versions.
- - Proposes specific version bumps (React + framework).
- - Notifies all stakeholders.
3. Within 2 hours of React2Shell being announced
- • For a typical team using Kolega.dev:
- - PRs to patch React/Next.js are already open including tests and validation everything still works.
- - Receive mini-runbooks:
- - Log queries to spot suspicious RSC/server-action requests.
- - Indicators to look for (crypto miner drops, backdoors, unusual processes).
- - Vulnerability resolved, estate secure
Now compare that to the actual attacker timeline:
- • Hours: first exploitation attempts & first PoC.
- • ~24 hours: first successful compromises with miners and backdoors.
- • 48 hours: Cobalt Strike, Sliver, and named campaigns (Emerald, Nuts, Secret-Hunter) in the wild.
- • ~3 days: CISA adds it to KEV, confirming active exploitation.
So yes: if you were with Kolega.dev, you would have had React2Shell remediated within ~2 hours of it being announced — long before the biggest exploitation spike and mass-campaign activity kicked in.
We don't scramble blindly when these hit. We're able to respond to ecosystems events faster than the threat actors can scale up.
Appendix: Where React2Shell Lives in the Architecture (for the Curious)
For devs who do want some technical depth, this is the "how it works under the hood" section.
A.1 Flight & RSC deserialization
React Server Components use Flight, an internal protocol, to serialize:
- • Component boundaries
- • Props & data
- • References to server actions / functions
- • Then ables / promises
- • Other model tokens
On the server, React's RSC runtime:
- Receives an HTTP request with a Flight payload.
- Deserializes the payload into JS objects & function references.
- Resolves which server function to call and with what arguments.
- Executes it and streams a response back to the client.
React2Shell abuses step 2–3.
A.2 What the vulnerability is technically
- • The vulnerable code unsafely deserializes payloads from HTTP requests to Server Function endpoints.
- • Attackers can craft Flight payloads that:
- - Abuse how models/IDs are mapped back to server functions.
- - Use JavaScript's duck-typing and dynamic behavior to sneak malicious behavior into the reconstructed object graph.
- - Ultimately trigger execution of unintended code paths in the server environment.
Trend Micro breaks it into a four-stage exploit chain, each "picking a lock" on the way to full RCE.