React2Shell Explained: Carpathian's Incident Response
CVE-2025-55182 React2Shell: Critical Zero-Day RCE. Real Cyber Attack Analysis and Threat Detection, IOCs, Remediation Steps. React & Next.js Security.
CVE-2025-55182 React2Shell: Critical Zero-Day RCE. Real Cyber Attack Analysis and Threat Detection, IOCs, Remediation Steps. React & Next.js Security.
It’s Saturday December 6th and I’m sitting on the cold Iowa ground with my back against the trunk of a tree, silently awaiting the 10 point buck I’ve seen wandering this area to come cruising down a trail in my line of sight when I get my favorite kind of text – “I think we got hacked”.
Don’t hackers have any sense of sanctity for Iowa whitetail season?
With my first look at the hack, I thought, this is going to be big. I explained it to the company owner like this—similarly to Log4Shell and Log4J, this vulnerability is embedded in widely utilized subcomponents of what was likely used in a ton of publicly available services. And like those two, because it was a sub-component, vulnerability detection was going to be difficult for the entire industry. (Later finding out it got named after Log4Shell was all too satisfying).
Turns out it was a little bug related to RSC (React Server Components), a zero-day cataloged as CVE-2025-55182, a monster CVSS 10/10 (Critical Priority), which later became the so aptly named React2Shell. Before I get into what happened at Carpathian, let me give you some as-quick-as-possible background on RCS, Java Next.js, how React2Shell works, how its being exploited around the world, and then we'll get to Carpathian.
React is an open-source JavaScript library (not a full framework) for building user interfaces, primarily for web applications. It was created by Facebook (now Meta) and first released in 2013 and the core idea is a component-based architecture: UIs are broken down into reusable, self-contained pieces called components (often written as functions or classes) that manage their own state and rendering. The problem is that this “rendering” is done on the client, meaning that after a user requests a webpage, they stare at a blank white page while they’re computer runs the code that unpacks and processes it. It’s like sending the Ikea instructions for a website in a single javascript and letting the user’s laptop build the website turning it into usable HTML for the web browser.
Back in the old days of the internet servers would store HTML files, and users would request a copy of those files and viewing webpages was born. As websites became significantly more complicated—user logins, dynamic content, etc. etc. developers have moved to these more complex “webpages as running code” model that can accommodate significantly more interactivity. For example: let’s display who’s logged in, let’s display a top relevant list of products to buy from a database of 10 million products, let’s have a chat bot conversation running, let’s display flights that are canceled and just that part of the website updates every 3 seconds. You get the picture.
So in 2020 the React team is facing the challenge of ever more complex websites creating ever longer blank-white websites while users wait for their dinky laptops to live-render the webpage. Their solution? By late 2020 they release React Server Components (RSC). The idea is—let’s have a process by which our website can choose which information should be rendered into usable HTML by the users machine, and which more computationally intensive content could be rendered into HTML by our serves, and then we’ll send them HTML directly and then the client machine simple has to combine the pre-rendered content. This is much faster.
React Server Components use a protocol called Flight to stream rendered components from the server to the client. This includes handling serialized payloads for server actions/functions (e.g., form submissions or server-side interactions). The core issue is unsafe deserialization in the RSC payload processing:
Public proof-of-concepts (PoCs) emerged shortly after disclosure.
• Vulnerable: React 19.x (early releases), Next.js using App Router in certain 15.x/16.x versions.
• Patched: Update to fixed versions (e.g., latest React 19 patches, Next.js 15.1.9+, 16.x patched releases).
Even if you don't explicitly use server actions, RSC-enabled apps can be vulnerable. Tools like ‘npx fix-react2shell-next’ automate upgrades.
React powers approximately 82% of JavaScript applications according to the 2024 State of JavaScript survey. Next.js, the leading React framework for server-side rendering, is used by ~20% of developers. When Wiz analyzed cloud environments, they found 39% contained vulnerable versions of React or Next.js.
When the Shadowserver Foundation looked at the possible impact of React2Shell, they detected nearly 78,000 vulnerable public internet addresses within 48 hours of disclosure.
The vulnerability went from public disclosure to active exploitation by nation-state actors in under 24 hours. CISA added it to the Known Exploited Vulnerabilities catalog on December 5, 2025, mandating federal agencies patch by December 26, 2025. Google, Amazon, Microsoft, Palo Alto Networks, and Datadog have all published threat intelligence confirming widespread exploitation across multiple sectors.
November 29, 2025 | Vulnerability discovered by security researcher Lachlan Davidson and privately disclosed to the React Team.
December 3, 2025 | Public disclosure by Vercel and React, with initial patches released for affected frameworks (e.g., React 19.0.0–19.0.2, Next.js 15.x–16.x).
December 4, 2025 | Early reports of in-the-wild exploitation emerge, including China-nexus threat groups rapidly weaponizing the flaw for RCE attacks. Security firms like AWS and Datadog publish initial analyses.
December 11, 2025 | React discloses related vulnerabilities (CVE-2025-55183, CVE-2025-55184, CVE-2025-67779) in the same affected packages, involving denial-of-service and source code exposure risks.
December 12, 2025 | Surge in global attacks reported, with tools like GreyNoise observing widespread scanning and exploitation. CISA adds to Known Exploited Vulnerabilities (KEV) catalog, mandating federal patches. Ongoing discussions on platforms like Hacker News and podcasts highlight the vulnerability's broad impact.
Early React2Shell exploitation has been linked to multiple threat actors, and while in Carpathians case we can’t definitely link it to one, it seems more likely than not this was attributable eager cyber criminals over China-nexus groups (a new term for any group with ties to the CCP). Let me explain why:
One such CCP tied entity is APT41 aka “Wicked Panda” (yes, seriously), a hacking group which was among the first to weaponize the vulnerability turning a simple POC into Exploitation of Public-Facing Applications (MITRE ATT&CK: T1190) and immediately deploying reconnaissance tools like credential harvesters and reverse shells. Their motivations appear rooted in state-sponsored espionage, targeting intellectual property in sectors like technology and finance, where React-based applications are prevalent for dynamic user interfaces. This clearly parallels the operating procedure seen in Log4Shell exploits, where similar groups pivoted to supply-chain vulnerabilities for persistent access.
In Carpathian's incident, the multi-OS credential-harvesting commands and Hong Kong-based C2 attempts suggest an automated script from a cybercrime toolkit, potentially tied to actors like those using RATs in widespread campaigns. To me, this more likely point to opportunistic cybersecurity criminals just looking for a payout, but there’s no way to be certain.
Beyond regular layered security, least privilege, zero trust blah blah, here are the specific things you can do to mitigate and detect in my order of precedence:
• Patch to React 19.0.3+ and Next.js 15.1.9+ immediately (duh).
• Look for Node.js executions spiking post-request
• Many SIEMs or EDRs can look for outbound connections to known C2 servers, but in this case our attackers IP didn’t seem to be know so that wouldn’t have helped, but a basic “no traffic to China” firewall did.
• I read that SIEM rules monitoring for anomalous RSC payloads could help identify: A sample Sigma rule could flag POST requests to /_rsc/* endpoints with multipart/form-data headers and payload sizes >10KB
• Future proofing, CA tools like Snyk or Kiuwan in CI/CD to scan for vulnerable dependencies pre-deployment.
Carpathian was being actively attacked less than 2 days after public disclosure, as if cybersecurity professionals needed proof added to the pile of ever-growing evidence that the gap between disclosure and attack execution is shrinking ad infinitum. Logs showed Next.js, an open source React library used by the site was used to gain some command level access to the machine hosting the services.
• entered password testing commands
• unsuccessfully attempted sudo user access
• explored its local filed systems using ENOENT for common Linux/Windows/ and MacOS paths
• used local scheduled scripts to build additional outbound-connected persistence
• attempted to cat dump from directories that didn’t exist. A classic sign of attempting to extract credentials and API and SSHI keys, or other secrets
• Ran broad credential harvesting commands, applicable on all kinds of OS’s (Linux, Kubernetes, AWS, Docker, GCloud credentials)
• ran multi-operating system commands clearly indicating that the attacks were prepared and multi-platform scripted
• attempted to created reverse shells back to an IP address from a cloud hosting services provider in Hong Kong, which was blocked by firewalls
• Initial Access: Next.js web component was vulnerable to React2Shell.
• Lateral Movement: From web app to system commands, the attacker gained shell access via the app process.
• RCE Confirmed: The shell command execution shows successful code injection, via the Next.js app vulnerability.
• Payload Goals: Downloaded malware from a Hong Kong IP and attempted to harvest creds and enumerate the system.
• Persistent Access: Not established, controls prevented connection.
• Failure Reasons: Malware was automated and too generic to escalate privileges further.
Thankfully, good segmentation and other security controls at Carpathian mean the only data possibly exfiltrated was the components of the public website. No live sessions, no secrets and most importantly, no client data. I always advocate for hosts running any public service to be credentialed completely separately from internal services.
Thanks for reading and happy hunting,
Levi Horsley
NIST NVD – CVE-2025-55182
Carpathians Public Disclosure Vercel Security Incident: What To Know
Vercel Security Disclosure Critical Security Vulnerability in React Server Components
I tried to explain RSC the best I could—Josh W. Comeau has this great article about it that helped me understand.
Horizon3 – CVE-2025-55182 - React Server Components RCE
Technical Deep Dive into CVE-2025-55182 (React2Shell), Reddit Post
Security Researcher Lachlan Davidson site post , and his original GitHub POC post
The Hacker News
