What is CVE-2025-55182 and why all the noise and concern?
15th December 2025CVE-2025-55182 is a critical flaw in React’s 'Flight' protocol used by React Server Components (often in Next.js apps), nicknamed 'React2Shell.'
What is CVE-2025-55182 (React2Shell) in simple terms?
Imagine a web application as a restaurant where the kitchen (the server) prepares food (web pages) based on orders (requests) from customers (browsers).
React Server Components use a special “order language” (the Flight protocol) so the browser can ask the server to run certain functions and send back the result. CVE-2025-55182 is a bug in that order language, that lets a threat actor send a specially crafted “order” that tricks the kitchen into running any command they want, like opening a shell (command line access), installing malware, or stealing all the data on that server.
Question: Is this likely to impact some industries or segments more than others?
Answer: Short answer is, no it doesn’t appear so. However, industries that run big, complicated online sites for their customers (like software companies, online banks, shopping sites, airlines, and streaming services) often use the same modern web technology across many of their apps and pages. Because they run lots of separate pieces of software built this way, there are more places an attacker could try to break in, and it can be harder and slower for them to fix every affected system when a new security problem is found like this.
The worst part is the hacker doesn’t need to log in or have any special access. They can do this from the internet as a stranger.
Why is this vulnerability so worrying?
This one is especially scary for three main reasons. It’s a “remote code execution” (RCE) with no login required.
The vast majority of serious bugs only let attackers read data or crash the app. This one lets them run any command on the server itself, as if they were sitting at the keyboard, and they don’t need a password or account to do it. This is why it has the highest possible severity score (CVSS 10.0)
That means it’s easy to exploit, works over the network, and gives the attacker full control of the server, which can lead to data theft, ransomware, or using that server to attack other systems. It affects very popular, modern web frameworks like React and Next.js which are used by thousands of companies for their main websites and apps. Because the bug is in the core React Server Components “Flight” protocol, many standard out of the box Next.js apps are vulnerable by default, so the potential number of affected systems is huge.
How is this different from other vulnerabilities?
Compared to typical web bugs, CVE-2025-55182 stands out in a few ways.
It’s an “unsafe deserialization” flaw in a modern server side component protocol, not a classic SQL injection or crosssite scripting (XSS) bug. That means the problem stems from how the server interprets structured data from the browser, not in how it handles user input in a form or URL.
It’s not just one app or one company; it’s a flaw in a widely used open‑source library (React Server Components) that many frameworks (like Next.js) build on top of, so patching requires updating that core library, not just fixing custom code.
Question: What does updating a core library involve and why is it harder than deploying a patch?
Answer: Think of a core library as the shared engine in hundreds of cars from the same company. Fixing one car's engine is quick but repairing every car with that engine means checking them all, testing the fix so nothing breaks, and updating across factories, showrooms, and roads everywhere.
Ultimately it touches everything, one update can accidentally mess up many apps that rely on it, so teams test endlessly first.
They are often hard to find everywhere, the old broken version might hide inside other software, so spotting all spots takes longer.
The coordination required is huge with different teams, offices, and or even partners must all apply the fix together, slowing things the process.
Because it’s an unauthenticated RCE in a default configuration, attackers can scan the internet for vulnerable sites and compromise them quickly, which is why there is already widespread scanning and exploitation in the wild meaning IT departments globally working around the clock since it became public.
Question: Is an “unauthenticated RCE in a default configuration” is it possible that some users will have changed the default configuration and will this mitigate the issue? Can the configuration be changed now as a security measure?
Answer: The flaw reportedly looks to exploit standard out the box configurations of the React 19 and Next.js app router apps. So many deployments especially in far reaching and broad service providing industries (SaaS, fintech and e-commerce for example) often run unchanged defaults for simplicity and speed.
Changing the configuration post vulnerability would help but its impact would be minimal compared to the recommended remediation(s) (as linked at the bottom of the page).
Is this already being exploited in the wild?
CVE202555182 (React2Shell) is already being actively exploited in the wild, and it is considered a critical, urgent threat by cloud providers, MSSPs, and threat intel firms. Multiple threat intel and cloud vendors (AWS, Wiz, GreyNoise, Dataminr) confirm that exploitation is ongoing and widespread.
A full proof of concept exploit is publicly available, so both sophisticated attackers and automated botnets can use it broadening the potential threat actors. GreyNoise and Wiz reported that scanning and exploitation attempts began within hours of the public disclosure and are now rapidly expanding across the internet. Wiz has already identified multiple confirmed victims whose servers were compromised via this vulnerability, and they expect it to be used in both targeted and opportunistic campaigns.
Publicly documented examples include Chinanexus APT groups with AWS and XM Cyber reporting that China's nexus cyber threat groups, including Earth Lamia and Jackpot Panda, are actively exploiting CVE202555182. These are sophisticated, state linked actors that typically target organisations for espionage, data theft, and access broker resale.
GreyNoise observes that the exploit is already being added to botnet exploitation kits, meaning it will soon likely be used in largescale, automated attacks for crypto mining, credential theft, and ransomware staging.
Threat reports link the vulnerability to malware such as phishing infrastructure, Jackpot (financial sector malware), and Lamia (a Chinanexus toolset), indicating it is being used to establish initial access and deploy follow on payloads.
The targeting pattern shows both broad opportunistic scanning and focused campaigns. Any organisation running React/Next.js apps with Server Components (RSC) is exposed, but the most attractive targets are going to be Financial services (banks, fintech, payment processors), Ecommerce and retail platforms for the obvious quick financial rewards.
Because React Server Components are common in modern web apps, the pool of potential victims is very large, including both public facing sites and internal business applications.
Chinanexus groups like Earth Lamia and Jackpot Panda are primarily targeting organisations in East and Southeast Asia, but they also hit targets in Latin America, the Middle East, and globally. Opportunistic, automated scanning is global and not limited to any region. Any internet facing React/Next.js app with the vulnerable RSC implementation is a potential target.
From a cyber insurer or risk management perspective, this is a “patch now” vulnerability because it is already being exploited by both APTs and botnets, so the window to patch before compromise is very short. The attack is unauthenticated and remote, so perimeter controls alone (WAF, firewall) are not enough; the underlying React/Next.js framework must be upgraded to a patched version.
For any internal risk manager, anyone assessing portfolio exposure or a looking at a specific insured, the immediate questions are going to be:
- Are they using React Server Components or Next.js with RSC?
- Have they upgraded to the patched React/Next.js versions (19.0.0‑rc‑eac8943c‑20251203 or later)?
- Are they exposed to the internet, and do they handle sensitive data or run critical workloads on those apps?
- Are React Server Components (RSC) or Next.js used in any production web applications?
- Are those apps internet facing, or are they internal admin tools, portals, or APIs?
- What versions of React and Next.js are currently in use in production?
- How many applications use React/Next.js with Server Components?
- Are there any third party or vendor-built apps (e.g., SaaS, internal tools) that use React RSC and are hosted on prem or in the company’s cloud?
- How are React/Next.js dependencies managed?
- Is there an automated way to scan for vulnerable React/Next.js versions across all repos and environments (e.g., SCA, GitHub apps, internal tooling)?
- Have all React/Next.js applications been upgraded to a patched version?
- Has the patch been applied to all environments (dev, staging, production) and all instances (containers, VMs, serverless)?
- If patching is not yet complete, what temporary controls are in place?
- Are WAF rules (e.g., blocking suspicious next-action or rsc-action-id headers) deployed and enforced?
- Has network access to RSC endpoints been restricted (e.g., IP allowlisting, internal only access)?
- Are rate limiting and anomaly detection enabled on these endpoints?
- Are application and web server logs being monitored for suspicious RSC‑related requests (e.g., unusual POST patterns, next-action headers, unexpected process execution)?
- Are EDR/EDR agents enabled on servers running React/Next.js apps to detect post exploitation activity (e.g., shell spawning, file changes, lateral movement)?
- Has the patching been included in the company’s vulnerability management program (e.g., tracked in a ticketing system, marked as “remediated” in the CMDB)?
From a risk assessment or underwriting perspective, a company can be considered to have closed this exposure when they can demonstrate a clear inventory of all React/Next.js apps using Server Components. Evidence that all instances have been upgraded to a patched React/Next.js version (e.g., deployment logs, dependency scans, SCA reports).
Confirmation that interim controls (WAF, network restrictions) are in place for any apps that cannot be patched immediately, with a concrete remediation timeline.
Ongoing monitoring (logs, EDR, vulnerability scanning) to detect both exploitation attempts and successful compromises. If the company is using a cloud provider (AWS, Google Cloud, Azure, Vercel, etc.), also check whether the provider has applied any virtual patch rules for this CVE and whether the customer has enabled them.
CVE‑2025‑55182 (React2Shell) is a textbook example of how a single critical flaw in a widely used software component can expose thousands of companies at once, and it highlights three big, systemic issues in enterprise cybersecurity: the fragility of modern software supply chains, the patching gap, and the mismatch between risk and control maturity.
Modern apps are built on layers of opensource and third party code (React, Next.js, etc.), so a vulnerability in one core component becomes a “critical software flaw” that underpins many different applications across many different companies.
When that flaw cracks (like an RCE in React Server Components), it doesn’t just affect one app; it affects every company that uses that stack, regardless of their industry, size, or internal security controls. This creates a “mass exposure” scenario where the same vulnerability appears in internet facing customer portals, internal admin tools, and SaaS platforms, all at the same time. Even “secure” companies with good firewalls, EDR, and MFA can be compromised if they run an unpatched version of a critical framework. The risk is not just about one company’s configuration: it’s about the entire ecosystem’s dependence on a small number of foundational libraries.
React2Shell is a CVSS 10.0, unauthenticated RCE, yet many organisations will still be vulnerable days or weeks after the patch is released. This exposes the “critical patching gap” that insurers and risk teams see repeatedly. Many companies don’t have a complete, up to date inventory of all their web apps and the underlying frameworks (React, Next.js, etc.), so they can’t quickly answer “Are we exposed?”.
Even when the risk is known, patching requires coordination between developers, operations, and security, and often gets delayed by testing, change windows, or fear of breaking functionality. Interim controls are not enough, WAF rules and virtual patches can buy time, but they are not a substitute for fixing the underlying flaw, and attackers quickly adapt to bypass them. The result is a window of exposure where attackers (including state‑nexus groups) can scan the internet and compromise systems before the patch is applied, turning a known vulnerability into a predictable loss event. AWS honeypots lit up December 3rd. Commands running. Files writing. /etc/passwd reads everywhere. React2Shell wasn't theoretical anymore with a reported 2.15M Web Services Running Next.js Exposed Over Internet.
From a cyber insurer or risk management perspective, React2Shell reinforces that risk is concentrated in a few critical components. A small number of widely used frameworks (React, Log4j, Spring, etc.) create outsized risk. A single flaw can affect a large portion of a carrier’s book. Controls are often misaligned with the real threat. Companies may spend heavily on perimeter security, EDR, and MFA, but if they can’t rapidly patch critical framework vulnerabilities, those controls are easily bypassed by a pre authenticated RCE. The “software supply chain” is a first order risk factor. How a company manages dependencies, tracks versions, and responds to critical CVEs in opensource libraries is now as important as traditional controls like firewalls and access reviews.
For any risk assessor, this vulnerability suggests that underwriting and portfolio monitoring should place more weight on Software stack hygiene. Do the insured use modern web frameworks (React, Next.js, etc.)? Do they have a clear, automated way to track and patch critical dependencies across all environments? Critical patching capability, how quickly can they respond to a CVSS 10.0, internet facing RCE in a core framework? Do they have a documented process for emergency patching, including change management exceptions and rollback plans? Are third party or vendor-built apps using the same vulnerable components? Is there a process to validate that vendors have patched critical framework vulnerabilities?
React2Shell is not an outlier, it’s a reminder that in modern software, the weakest link is often not a misconfigured firewall or a weak password, but a single, unpatched line of code in a critical dependency that runs across the entire organization.
Remediation recommendations from 5th December 2025: Responding to CVE-2025-55182 | Google Cloud Blog
Sources:
Dynatrace – React2Shell CVE‑2025‑55182: What it is and what to do
Rapid7 – React2Shell (CVE‑2025‑55182): Critical unauthenticated RCE affecting React Server Components
Wiz – Critical RCE Vulnerabilities Discovered in React & Next.js
Security Labs (Datadog) – CVE‑2025‑55182 (React2Shell): Remote code execution in React Server Components
AWS – China‑nexus cyber threat groups rapidly exploit React2Shell vulnerability CVE‑2025‑55182
NVD (National Vulnerability Database) – CVE‑2025‑55182 Detail
GreyNoise – CVE‑2025‑55182 (React2Shell) Opportunistic Exploitation in the Wild
XM Cyber – CRITICAL ALERT: React2Shell CVE‑2025‑55182 is Under Active Exploitation
SentinelOne – Protecting Against the Critical React2Shell RCE Exposure
Vercel – Summary of CVE‑2025‑55182