A vulnerability in the ubiquitous logging software Log4j caused immediate turmoil when it was revealed at the end of 2021. Detecting it proved easier said than done in the months and years that followed, resulting in millions of attempts to exploit it and software that remains unpatched. At the end of 2025, React2Shell emerged, another serious cyber threat that could have a major impact. What do we know so far, and is this a full-fledged successor to Log4Shell?
CVE-2025-55182 is the current vulnerability in React Server Components (RSC), specifically versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0. Based on the CVSS score, its severity is equal to Log4Shell: 10.0, the maximum score. That score is more common than you would expect for a maximum and is virtually a given due to the remote code execution capabilities that hackers have after exploitation. The payload here is a targeted HTTP request to a React/Next.js server endpoint for RSC.
It is now known that more than 30 companies in various sectors have fallen victim to React2Shell, just five days after it became known. Chinese state actors in particular struck within hours, AWS reported the day after the announcement. The hyperscaler quickly identified them thanks to honeytokens (fake credentials created to monitor attacks) and the firewall rules that were already in place. Nevertheless, many attackers and victims could follow – assuming they do not patch or do not patch in time.
Read more about Log4Shell’s impact in this earlier article
Log4Shell and React2Shell: not as alarming, similar still
Anyone building user interfaces in a relatively straightforward way will likely do so with React or Next.js and therefore with RSC. Wiz discovered that 39 percent of cloud environments run vulnerable instances of one or the other solution. According to Wiz, the Next.js framework is present in 69 percent of all scanned environments. Sixty-one percent of these run public applications with Next.js, leading the cybersecurity company to identify 44 percent of all cloud environments as exposed Next.js instances. Organizations already running RSC 19.0.1, 19.1.2, and 19.2.1 are no longer vulnerable, provided no exploitation has yet occurred for persistent access.
Log4j was much more widespread than RSC at the time of Log4Shell and continues to be. It may be found in backend systems, routers, and appliances as the standard logging tool for Java applications. Cloud, on-prem, edge, modern, legacy, you name it: chances are Log4j is running somewhere in the background. For that reason alone, the fear surrounding Log4Shell was immediately greater than is now the case with React2Shell: good luck finding all Log4j instances before you can even patch them. At RSC, we assume that users are accustomed to updating their React or Next.js instances, but that remains to be seen in reality. These frameworks are used for mostly active web applications, so we are fairly confident that they will also see security bulletins or hear about them through the media.
Attack and defense are (even) better prepared
Log4Shell came as a surprise to the IT world. Massive spray-and-pray attacks led to millions of scans per hour from both botnets (such as Mirai) and hackers themselves. Due to deep nesting in dependencies (dependencies of dependencies), seemingly secure applications could be vulnerable without administrators being aware of it. Web application firewall (WAF) rules had to be set up in a hurry in response. The positive side of the story is that the almost apocalyptic warnings from security researchers were largely effective. The impact of such a well-known vulnerability is actually somewhat unclear. The response to it, through patching, searching for vulnerable components, or mitigating attacks, sometimes cost security teams tens of thousands of hours.
This is a different story altogether with the more limited impact of React2Shell. The big advantage is that everything indicates that its disclosure by the Meta security team took place before exploits. Major cloud providers such as AWS, Cloudflare, and Vercel had WAF rules in place. A framework update via ‘npm update’ is also something developers are used to.
The AWS analysis of exploitation shortly after the disclosure of React2Shell shows that attackers are more sophisticated and act faster when such a vulnerability arises. It appears that state actors now have a fairly detailed script ready for exploitable software. Since there are always slow patchers, there is also a good chance that there will be more victims in the near future. Advanced state hackers may already have gained a foothold, but still need to figure out how to move laterally through the network of a currently unknown victim.
Conclusion: the security world is on alert, but this was only a warning
Log4Shell put IT teams and security teams in particular on high alert. Its impact could have been worse, but its scale was unprecedented and the operational impact cost security teams countless hours. Even now, React2Shell is not a “worthy” successor. It is a more compact and manageable threat, but can be just as damaging to a single victim, resulting in downtime, data leaks, and/or enormous financial damage. It should not be underestimated, and the extent to which CVE-2025-55182 remains present in front-end systems is a good indicator of the patching speed of developers worldwide.
As a worst-case scenario, Log4Shell was a stress test for security teams. Thanks to the coordinated disclosure of React2Shell, they were able to respond in time and were sometimes already protected in advance because they only run in public cloud instances, for example. The modern nature of React and Next.js makes this vulnerability easier to resolve. It is, in fact, an application crisis rather than an infrastructure crisis. Cyber experts will continue to measure the impact of React2Shell, and we will keep an eye on it.
Read also: Meta warns of critical vulnerability in React Server Components