On December 12th, React officially confirmed that researchers, while validating last week's patches, unexpectedly discovered two new vulnerabilities in React Server Components (RSC).

In the past week, the aftereffects of the React2Shell vulnerability still lingered: servers were hijacked for cryptocurrency mining, cloud vendors imposed emergency bans, and even more consequences ensued. To mitigate the risks, Vercel even spent $750,000 on vulnerability bounties and emergency response costs in just one weekend. A vulnerability in a front - end framework directly penetrated the entire technology stack. React's official team has continuously issued emergency announcements, repeatedly emphasizing "please upgrade immediately." This is already the second large - scale patch update in a short period.

The two vulnerabilities disclosed this time are: the high - risk DoS (Denial - of - Service) CVE - 2025 - 55184, where a single request can cause the server to crash; and the medium - risk source code leak CVE - 2025 - 55183, which may expose the source code of React Server Components.

1 One React Vulnerability Shakes the Global Web

In the past week, a vulnerability known as React2Shell has swept through the entire Internet industry. The fundamental reason for such a significant shock is simple: React is of utmost importance. It is almost the "default foundation" of modern web.

From Meta's own Facebook and Instagram to large - scale platforms such as Netflix, Airbnb, Shopify, Walmart, and Asana, all rely on it. Not to mention the millions - strong developer ecosystem, and many frameworks depend on the vulnerable React package.

The React team numbered it as CVE - 2025 - 55182, which received a perfect severity rating of 10.0 in the Common Vulnerability Scoring System. As the creator and main maintainer of Next.js, Vercel also assigned a separate CVE number, CVE - 2025 - 66478, to this issue.

What makes it terrifying is that attackers can exploit this vulnerability with almost no pre - conditions. Cloud security vendor Wiz observed that 39% of cloud environments contain Next.js or React instances with the CVE - 2025 - 55182 vulnerability. It is estimated that when the leak occurred, over two million servers had security vulnerabilities. Even worse, in their experimental verification, they found that the exploitation of this vulnerability is "almost 100% successful" and can stably achieve complete remote code execution.

The affected component scope includes versions 19.0 to 19.2.0 of core modules such as react - server - dom - webpack, and also affects the default configurations of multiple React frameworks and packagers, such as Next.js, React Router, Vite RSC, etc. For many frameworks (especially Next.js with App Router), RSC is actually enabled by default.

When a Level 10 vulnerability is made public, it's not just about "the vulnerability being reported and fixed." There are real - world destructive impacts.

Many developers publicly shared their experiences of being affected on X. Developer Eduardo was one of them. After his server was blocked, he immediately checked the logs and found that the machine had long been "taken over" - the CPU soared to 361%, suspicious processes were frantically consuming resources, and continuous connections were being made to an IP in the Netherlands. "My server is no longer running my application. It's mining for someone else!"

Even worse, the intrusion didn't occur through SSH brute - force cracking but inside the Next.js container. After exploiting the vulnerability, attackers could execute any code they wanted on the server, then deploy more "professional" malicious programs, and even disguise the processes as web services like nginxs or apaches to reduce the risk of exposure. "It infected my entire server just through one Next.js Docker container!"

Finally, he warned, "If Docker is still running with ROOT privileges and the exploited React version hasn't been updated, you'll be hacked soon." (Because with ROOT privileges, one can install cron, systemd, and persistent scripts, ensuring their presence even after a restart.)

The non - profit security organization ShadowServer Foundation stated that since the disclosure of the vulnerability, the attack traffic from Next.js assets controlled by botnets has suddenly increased tenfold. "Like other institutions, we've also observed large - scale attempts to exploit React's CVE - 2025 - 55182, including activities related to botnets."

Why It Can Be Fixed with (Almost) "One Line of Code"

Security researcher Lachlan Davidson was the first to disclose this issue and released a detailed technical analysis. He described the vulnerability as "a serious lack of security checks intertwined with a highly creative exploitation mechanism."

The research process itself was also extremely challenging. It was revealed that he invested over 100 hours in this. And the independent researcher Maple, who was the first to publicly reproduce the attack code, successfully constructed a minimum viable attack chain within dozens of hours after the patch was made public, demonstrating the risk that the vulnerability could be quickly weaponized.

Simply put, this vulnerability doesn't lie in some "obscure edge feature" but in the core communication mechanism of React Server Components.

To make server components fast enough, React designed the Flight protocol. You can think of it as a set of "front - end - specific data channels" built into React. Instead of sending the complete page data to the browser all at once, the server sends data in batches according to the rendering tree structure. This way, the interface can first render the parts that can be rendered, and the rest will be filled in gradually.

The problem is that this ability is very powerful. The Flight protocol not only needs to transmit strings, numbers, and JSON data but also "incomplete things," such as intermediate states like Promise, and reconstruct the component tree. To achieve this, React needs to deserialize and interpret the content of requests sent from the client on the server - side, restoring them into objects that can be further executed.

This is where the vulnerability lies. Attackers can forge a special HTTP request and send content "that looks like normal Flight data" to any React Server Function endpoint. When React parses this data, it mistakes them for legitimate internal objects and continues processing according to the normal process. As a result, the data constructed by the attacker is treated as part of the code execution path, ultimately directly triggering remote code execution on the server.

The entire process doesn't require logging in, no credentials are needed, and there's no need to bypass traditional security boundaries. Just because React lacks a basic hasOwnProperty check in its internal serialization structure, the crucial runtime boundary is breached.

After Lachlan Davidson responsibly reported the vulnerability to Meta, Meta immediately collaborated with the React team and launched an emergency patch in just four days. In terms of implementation, it's almost "adding one line of code," yet it blocks an attack chain capable of destroying the server.

2.Vercel, Cloudflare, etc. Are Innocently Caught in the Crossfire

As soon as a Level 10 vulnerability is exposed, it's often not a small team that gets hit first but an entire industry chain relying on React, especially front - end hosting and Serverless platforms. Leading platforms represented by Vercel are almost inevitably at the center of the storm because they are not only the key maintainers of Next.js but also the default entry points for a vast number of applications.

During the emergency response phase, various vendors indeed rolled out WAFs (Web Application Firewalls) at the first moment. Companies like Vercel, Cloudflare, AWS, Akamai, and Fastly all deployed rules to intercept known React2Shell exploit payload patterns. This can indeed buy some time, but the problem is that WAFs can only serve as a buffer, not a solution.

The essence of WAFs is a rule - matching pattern. Attackers can completely adjust the form of the payload to bypass it. Many applications don't rely on these service providers at all. Self - hosted, privately - deployed, or publicly - running instances are even beyond the reach of WAFs. More importantly, mitigation measures on the edge side are always just one layer of a multi - layer defense, not your patching strategy. For a 10/10 - level RCE (Remote Code Execution), the only real fix is to upgrade React/Next and redeploy, completely removing the vulnerable code from the running environment.

Precisely because the statement "don't rely on WAF as the main repair method" hit a sore spot, there was quite a bit of contention in the industry. Shubham Shah, the co - founder of Assetnote, posted on LinkedIn accusing the Vercel CEO of asking him to remove the tweet about "not relying on WAF to protect against this vulnerability" in an almost bullying manner. Shubham Shah said:

"The Vercel CEO tried to deny the fact that their WAF could be bypassed. The vulnerability involves the latest Next.js/RSC remote code execution. He asked me to remove the tweet about 'not relying on WAF to protect against this vulnerability' in an almost bullying manner. My advice at that time was that users should directly patch their own systems instead of relying on WAF - because we could already bypass Cloudflare's protection at that time, and now Vercel's WAF can also be bypassed. This advice still holds true today.

WAFs do have their role, but the core solution is always to fix system vulnerabilities. Currently, many users have difficulty identifying the risk points in their own systems, and defenders need clear information to guide the patching work. WAF vendors like Vercel should not pressure researchers to cover up the fact that their WAF can be bypassed.

I just released an update for the react2shell - scanner tool, adding the --vercel - waf - bypass parameter. This feature is based on the attack payload designed by Adam Kues from the Searchlight Cybersecurity Research Team and can effectively bypass Vercel's WAF protection."

Trying to cover up problems is always in vain. As more people discovered Vercel's vulnerability, Vercel's attitude underwent a major change. The Vercel CEO has apologized for his previous attitude of questioning whether the WAF could be bypassed and expressed his respect to the Searchlight Cybersecurity Research Team.

The Vercel team responded to Shubham Shah's team's report within a few minutes and deployed a fix within half an hour. Shubham Shah stated in his latest LinkedIn post:

"The Vercel CEO has apologized for his previous attitude when questioning whether the WAF could be bypassed and expressed his respect to the Searchlight Cybersecurity Research Team. He also invited us to collaborate in a shared Slack workspace.

We have submitted multiple valid WAF - bypass solutions through their special vulnerability bounty program

https://lnkd.in/gMsnZFeu
Some of these vulnerabilities allowed us to completely bypass Vercel's WAF protection layer (these vulnerabilities are very interesting!), and others benefited from our in - depth understanding of Node.js and Next.js.
So far, Adam Kues, Dylan Pindur, and I in the team have independently discovered different bypass methods. Assisting Vercel is crucial to us because many of our clients deeply rely on its infrastructure. The difficulty of bypassing the WAF is gradually increasing. The Vercel team can respond to our reports within a few minutes and deploy a fix within half an hour. Their attention to this matter is reassuring. In the end, it turned out to be a happy ending."

Under the dual pressure of the new vulnerability and the React Level 10 vulnerability, Vercel temporarily launched what could be called the most radical security patching plan in history.

On December 11th, on YouTube, a program called "The Programming Podcast" analyzed how Vercel spent $750,000 in just one weekend to stop this "perfect hacker" attack, as well as the line of code in the Dockerfile that could expose users' environments.

This podcast mentioned that after the incident was exposed, Vercel quickly launched an emergency response process, collaborating with the React team, the HackerOne community, and security researchers. They completed the investigation and repair in just one weekend and paid a total of $750,000 in vulnerability bounties. This handling speed and transparency were praised by the industry as "a highly exemplary public relations and technical response."

The reason why the incident didn't cause more extensive damage lies in the rapid response of the community and the platform. After the vulnerability was made public, Vercel collaborated with HackerOne to open up all relevant vulnerabilities and boundary conditions to the white - hat community. Within three days and nights, they received 17 to 19 repair suggestions and boundary situations, involving different levels of security risks. Eventually, Vercel paid approximately $750,000 in bounties to reward the developers and security researchers who participated in the repair at a crucial moment. Multiple teams of engineers, including those from React, Next.js, etc., were also fully engaged over the weekend to promote the rapid implementation of the patches.

Due to the extremely wide user base of React, besides Vercel being severely affected, Cloudflare was also thrown into chaos for a while.

In an attempt to remedy the impact of the React2Shell vulnerability, Cloudflare hastily introduced a change, which affected approximately 28% of HTTP traffic. A large number of websites relying on Cloudflare returned a 500 Internal Server Error, causing about a quarter of Internet traffic to be inaccessible for a time.

Dane Knecht, the Chief Technology Officer of Cloudflare, later stated that this incident was not caused by a cyber - attack but by an internal change introduced when the company was hastily dealing with the high - risk vulnerability in React Server Components.

In addition to these platforms, the National Cyber Security Center (CSOC) of NHS England also said on Thursday that there are already multiple functional proof - of - concept vulnerability exploitation programs for CVE - 2025 - 55182 and warned that "the possibility of continued successful exploitation of this vulnerability in a real - world environment is very high."