Opinions & Insights

Netlify’s ongoing response to React2Shell

It’s been roughly two weeks since the internet was rocked by the public disclosure of CVE-2025-55182, which has been commonly named React2Shell, a 10.0 / 10.0 Critical risk vulnerability in the Next.js / React Server Components. Netlify remains committed to protecting customers affected by this vulnerability, as well as the two additional vulnerabilities in Next.js announced in the wake of React2Shell.

Our response

Prior to the announcement of React2Shell, Netlify worked as part of a coordinated industry-wide group of peers to block potential exploitation of this vulnerability. While the vulnerability was announced in a responsible manner by the Meta team and the security researcher who discovered the flaw, within 24 hours of the fix being made available, actors were able to reverse engineer the patch and public exploits began circulating on the public internet. Netlify immediately began seeing traffic associated with React2Shell exploit attempts upon release of the first public exploit.

While some of the exploit attempts observed were from bug bounty hunters, it was also quickly taken advantage of by cryptomining campaigns, criminal groups, and perhaps most seriously, nation-state threat actors who pounced on the opportunity to probe vulnerable websites and exfiltrate sensitive data.

Within the first 24 hours of the first public exploit being made available, bypasses to the industry-wide blocking rules became available. Again, Netlify swiftly worked with industry peers to analyze the new exploit variants and add traffic blocking rules to nullify these new variants.

Currently, Netlify is not aware of public exploit variants which bypass current React2Shell mitigations applied by Netlify and all other major providers who host Next.js web applications, and we are continuing to monitor for any significant developments.

In addition to adding traffic blocking rules, Netlify took action to block all site deploys using versions of Next.js vulnerable to React2Shell to ensure customers would not be affected by this vulnerability when deploying future sites and web applications.

What you can do to mitigate risk

The only method to fully ensure the safety, integrity, and confidentiality of sites affected by React2Shell is to upgrade to a non-vulnerable version of Next.js. This upgrade should be prioritized as urgent, and we encourage all customers to upgrade immediately. Additionally, we recommend that all access tokens and secrets supplied as environment variables, accessible in the Functions scope of vulnerable Next.js sites, be rotated following upgrade.

One of the security strengths of deploying an application to Netlify, and using a decoupled application architecture, is limiting the potential impact of a serious application vulnerability. Scoping secrets and environment variables used in Netlify-deployed applications to just those scopes required, and placing access restrictions on the secrets and API tokens used within the application, limits the overall exposure and risk of a severe vulnerability. Simply put, by restricting the type of access the application has to systems which hold sensitive data, the overall recovery effort of mitigating a vulnerability as urgent as React2Shell becomes easier.

The following graph shows the number of exploit attempts Netlify has observed and blocked following the public release of the first React2Shell exploit. Traffic spikes from zero to significant within hours of the first public exploit becoming available.

Exploits blocked by Netlify

Monday, December 8, 2025 saw the largest volume of exploit attempts, as rapid and massive attack traffic exploded across the internet. The volume of exploit attempts on December 8 was roughly 2.8x the next highest spike in volume, and approximately 7x the baseline levels we are seeing on a continuous basis.

The volume of exploit attempts remains significant per day, and we expect this trend to continue for some time.

Self-hosted sites not protected by the blocking rules put in place by Netlify, and our peers in industry, would almost certainly be compromised within hours of the first exploit being made available. This short timeframe of disclosure to exploitation fits current industry metrics which have noted the increased speed at which adversaries exploit Known Vulnerabilities, often within 24 hours of disclosure. This short timeframe often exceeds the speed that software engineers can reliably test and release updates to core application components.

Analyzing exploit attempts yields the following attack traffic origins:

ASNOrganization% of Total Attack Volume
16509AMAZON-0230.09%
14618AMAZON-AES13.52%
14061DIGITALOCEAN-ASN8.11%
135161GMO-Z com NetDesign Holdings Co., Ltd.3.30%
42624Global-Data System IT Corporation3.28%
12876Scaleway S.a.s.3.24%
208137Feo Prest SRL3.13%
51396Pfcloud UG1.90%
42532SIA VEESP1.84%
13335CLOUDFLARENET1.83%
Top 10 total70.25% of all attack traffic
Country% of Total Attack Volume
US27.64%
DE23.55%
FR5.50%
SG5.28%
JP4.59%
NL3.79%
GB3.58%
SC3.29%
IR3.15%
ID2.10%
Top 10 total82.46% of all attack traffic
IP address block% of Total Attack Volume
150.95.80.0/243.65%
62.210.130.0/243.38%
62.60.135.0/243.03%
185.208.156.0/242.56%
119.235.221.0/242.53%
3.222.217.0/242.36%
3.232.79.0/242.28%
52.202.251.0/241.58%
185.70.11.0/241.31%
209.97.152.0/21.15%
Top 10 Total23.8% of all attack traffic

These attack trends indicate that threat actors continue to abuse legitimate cloud hosting providers to carry out attacks, rendering mitigation strategies like geographic blocking ineffective. Instead, blocking ingress traffic from ASNs not used as part of an application architecture, and IP address ranges that do not affect public search engine scraping, can be a more effective strategy when abusive address ranges are known.

Conclusion

React2Shell was a major framework-level vulnerability that deserves the tech media attention given to its coverage, and has many parallels to the massive Log4j / Log4Shell vulnerability disclosed almost exactly four years ago. Netlify continues to work closely with framework developers and our industry peers to protect our customers applications, and makes every effort to ensure the safety and security of your software and your data. React2Shell is the type of vulnerability that requires action not only to be taken by us as a provider, but also you as the customer. Together in partnership we can ensure a safer and better web.

Keep reading

Recent posts

How do the best dev and marketing teams work together?