On December 3, the coordinated disclosure of the critical vulnerability CVE-2025-55182 (CVSSv3 — 10) was made public. This vulnerability was found in React Server Components (RSC) as well as in several related projects and frameworks: Next.js, React Router RSC preview, Redwood SDK, Waku, and the RSC plugins for Vite and Parcel.
This vulnerability allows any unauthenticated attacker to send a request to a vulnerable server and execute arbitrary code. Considering that tens of millions of websites—including Airbnb and Netflix—rely on React and Next.js, and that vulnerable versions of these components were found in approximately 39% of cloud infrastructures, the potential scale of exploitation could be severe.
Immediate action is required to protect your online services. Initially, a separate CVE-2025-66478 was created for the Next.js vulnerability, but it was later deemed a duplicate, so the Next.js flaw is also included in CVE-2025-55182.
Where and how does the React4Shell (React2Shell/CVE-2025-55182) vulnerability work?
React is one of the most widely used JavaScript libraries for building web interfaces. With the advent of React Server Components (RSC) (which gained traction starting with React 18), part of the rendering process moved from the browser to the server.
In practice, your page can “ask” the server to execute React logic, receive the result, and insert it into the response already rendered. What’s the benefit? Faster websites, because the browser doesn't need to load as much unnecessary JavaScript.
RSC also splits the app into two worlds: server components and client components. Server components can handle “sensitive” tasks (database queries, access to secrets, heavy computations), while client components deal with interactive elements on the user’s device. To make this back-and-forth efficient, there’s Flight, a lightweight protocol over HTTP that transfers serialized data between client and server.
Where does the risk come in? In how those Flight requests are processed—specifically, through unsafe deserialization (when the server “unpacks” data and converts it into internal structures without proper validation). That’s where CVE-2025-55182 lives.
A range of React Server Components versions were reported as vulnerable (including packages like react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack), as well as multiple versions of Next.js linked to those implementations.
The most alarming scenario is how easily this can be exploited: an attacker could send a simple HTTP request to an exposed server and, without even authenticating, trigger execution of a process under the privileges of the React runtime on the server. In other words: if the endpoint is accessible and the version is vulnerable, the impact can be immediate.
While there wasn’t always clear public evidence of mass exploitation, cybersecurity experts warned that the abuse was fully viable and could escalate quickly. Technical reports mentioned that some proof-of-concept RCEs were highly reliable and that public prototypes already existed—something that often accelerates attacker adoption.
Now, beware of a common misconception: since React was originally designed to run primarily in the browser, there are older projects or setups where RSC is disabled. In those cases, the risk may be lower or even nonexistent. But just because “you don’t use server functions” doesn’t mean you’re automatically safe—RSC could still be enabled through configuration, dependencies, or defaults.
In fact, sites built with recent versions and default setups (e.g., a Next.js project created with create-next-app) are among those most likely to be exposed if patches and mitigations aren't applied.
Over 77,000 Potentially Vulnerable IP Addresses
The internet monitoring group Shadowserver reported that it had identified 77,664 exposed IP addresses potentially vulnerable to the React2Shell flaw, with nearly 23,700 of them located in the United States.
Geographic Distribution of Vulnerable IP Addresses (Source: ShadowServer)
And how did they arrive at that number? According to researchers, they used a detection technique developed by Searchlight Cyber / Assetnote: essentially, they send an HTTP request designed to "test" the server’s behavior and then validate a specific response that confirms whether the target might be vulnerable.
Meanwhile, GreyNoise observed 181 unique IPs attempting to exploit the vulnerability. Most of the traffic appeared to be automated (typical of bots scanning the internet at scale), and the attempts were primarily concentrated in the Netherlands, China, the United States, Hong Kong, and several other countries.
Unique IP addresses observed scanning for React2Shell (Source: Greynoise)
The most serious point came from Palo Alto Networks, which stated that more than 30 organizations may have already been compromised by React2Shell. According to their analysis, attackers are using the flaw to execute commands, perform environment reconnaissance, and attempt to steal configuration files and AWS credentials. The report even mentions intrusions linked to Chinese threat actors associated with state-backed operations.
Read more: Aisuru Botnet: How It Reached the 29.7 Tbps DDoS Record
Protection Measures Against CVE-2025-55182 Exploitation
1) Apply security patches
If you’re using React, it’s recommended to upgrade to versions 19.0.1, 19.1.2, or 19.2.1.
If you’re using Next.js, update to 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7.
The logic is simple: without a patch, any other measure is just a temporary fix.
2) Use your cloud provider’s WAF to buy time
Several providers have published rules to block exploitation attempts at the WAF level:
-
Akamai: rules for App & API Protector users.
-
AWS: rules included in the standard AWS WAF set, but you need to activate them manually.
-
Cloudflare: protects all customers, including on the free plan, as long as your traffic passes through Cloudflare WAF. On Pro/Business/Enterprise plans, it’s worth confirming the rule is active.
-
Google Cloud: Cloud Armor rules for Firebase Hosting and Firebase App Hosting apply automatically.
-
Vercel: rules applied automatically.
That said, all providers are clear (and rightly so): WAF is not a replacement for patching—it only buys you time while you update. RSC components must be updated in all your projects.
3) Self-Hosted? Block the exploit in layers
A less invasive option is to implement detection rules in your WAF or firewall to block patterns associated with the exploitation.
4) Can’t filter granular traffic? Reduce exposure immediately
If your environment doesn’t support fine-grained inspection, identify servers with active RSC (server function endpoints) and restrict access as much as possible:
-
For internal services: block anything not coming from trusted IP ranges.
-
For public services: tighten IP reputation filtering and apply aggressive rate limiting to stop automated scans.
5) Add EPP/EDR for detection and containment
An EPP/EDR agent on servers with RSC gives you an extra layer of defense: it helps detect unusual behavior after an exploitation attempt (unexpected processes, command execution, anomalous access) and can stop an attacker’s progress before escalation.
For deeper protection, at TecnetOne we can complement this layer with our SOC as a Service—centralizing visibility across endpoints, servers, and cloud to detect and respond faster. With vulnerability analysis and pentesting, you can also confirm whether any services are exposed, prioritize patching, and verify that mitigation measures have been correctly applied.
Read more: Hiring Pentesting: How to Do It and What to Consider
Conclusion
React2Shell (CVE-2025-55182) is the kind of vulnerability that leaves no room for “we’ll deal with it later.” If you’re running React/Next.js with RSC in production and exposed to the internet, the risk is real and the impact can be serious. The top priority is clear: update to patched versions, redeploy, and ensure no vulnerable components remain in your dependency chain.
From there, add defense in depth: use a WAF to buy time, reduce your attack surface, implement monitoring, and deploy EPP/EDR to detect abnormal behavior. And if you need support, TecnetOne can help with our 24/7 SOC to improve visibility and response, along with pentesting services to confirm exposure, validate patches, and reduce the risk of recurrence.
