When “No CVEs” Isn’t Reassurance: React2Shell Confirms the Risk of Silent Frameworks

Just a week ago, I wrote about Angular’s historically calm security record and how the recent wave of vulnerabilities shattered the idea that mature frameworks are inherently safe. The message was simple:

A quiet CVE history is not a security guarantee. It is often a sign of insufficient scrutiny.

Now, here we are again—this time with React and Next.js.

React Server Components—the backbone of Next.js’ App Router—received a critical RCE vulnerability so severe that security teams across AWS, Google Cloud, Akamai, Fastly, and Netlify issued rapid advisories. Active exploitation began almost immediately.

If your application was online and unpatched as of December 4, 2025 at 1:00 PM PT, security teams recommend rotating your secrets.

This is not an indictment of React. It’s not an indictment of Next.js. It’s an indictment of complacency in how we evaluate risk in open-source dependencies.

‍

Why React’s Vulnerability Mirrors Angular’s

1. Quiet ≠ secure

Before Angular’s recent CVEs, the framework’s near-silent vulnerability record created an illusion of inherent safety. React and Next.js weren’t much different. Major CVEs are uncommon, and developers often interpret that as evidence of airtight design.

But the absence of CVEs does not reflect the absence of vulnerabilities.
It reflects the absence of detection.

‍

2. Modern frameworks are incredibly complex

React Server Components introduced a new execution model. Angular’s SSR pipeline did the same. With complexity comes risk—and not the simple “we forgot to sanitize an input” kind.

We’re dealing with:

• compiler-driven rendering
  
  
• new transport protocols
  
  
• hydration and serialization boundaries
  
  
• evolving SSR architectures
  
  
• implicit trust relationships between client and server
  
  
• massively configurable build chains
  
  

The more powerful these frameworks become, the easier it is for subtle assumptions to go unnoticed for years.

‍

3. Vulnerabilities cluster when scrutiny increases

Angular saw three significant issues disclosed in rapid succession. Now React/Next.js is experiencing the same. These are not coincidental waves of insecurity—they’re waves of attention.

Once researchers start digging into a subsystem, latent vulnerabilities tend to surface quickly. The danger wasn’t new. The research was.

‍

Understanding the React2Shell Vulnerability (CVE-2025-55182 / CVE-2025-66478)

The core issue lies in how React Server Components process certain requests. Under specific conditions, a malicious request could manipulate execution paths on the server—ultimately leading to remote code execution.

Applications are affected when using:

• Next.js 15.x
  
  
• Next.js 16.x
  
  
• Next.js canary builds with PPR
  
  
• Any RSC-enabled App Router configuration
  
  

Pages Router apps and Edge Runtime are not impacted.

The vulnerability is severe enough that:

• patches were released immediately for every minor version line
  
  
• a CLI tool was released (npx fix-react2shell-next) to auto-patch apps
  
  
• cloud providers warned that unpatched apps should rotate secrets
  
  
• multiple threat actors—including state-backed groups—began probing for targets within hours
  
  

This isn’t a niche bug. It’s a reminder of the fragility hiding beneath the surface of optimized developer experience.

‍

The Bigger Lesson (Again): Security Is Not a Historical Accident — It’s an Ongoing Process

The Angular CVEs were not an anomaly.  The React2Shell RCE is not an anomaly. They are symptoms of a deeper truth:

Open-source security depends on active, continuous review—not on the passage of time.

The age of a framework does not make it safer. Its popularity does not make it safer. Its sponsor does not make it safer.

Only ongoing scrutiny, ongoing patching, and ongoing maintenance can do that.

And this brings us to one of the most overlooked risk multipliers in modern application development.

‍

Older Framework Versions Are Especially Vulnerable

Here’s why:

1. They receive fewer updates

Teams focus on shipping new features to current versions, not patching bugs in versions released 3, 5, or 10 years ago.

2. They receive far less scrutiny

Security researchers analyze the current version, not the ones long past their end of life.

3. Vulnerabilities in old frameworks often go unnoticed for years

Because no one is actively looking.

This issue is at the heart of long-term enterprise risk.

It doesn’t matter if your Angular or React app is stable.
It doesn’t matter if your current version works.
It doesn’t matter if “it hasn’t had a CVE in years.”

If your framework is past its official support window, it is not receiving:

• patches
  
  
• audits
  
  
• security testing
  
  
• dependency updates
  
  
• design-level threat review
  
  

And that means your attack surface is growing, even if your code isn’t changing.

‍

This Is Exactly Why HeroDevs Exists

Most organizations can’t upgrade frameworks on command. When an Angular migration takes 18 months, or a React upgrade requires rewriting core architecture, or a breaking change hits mid-roadmap, teams realistically can’t drop everything to update.

But attackers don’t wait for upgrade cycles.

HeroDevs provides Never-Ending Support (NES) and Extended Lifecycles for EOL Frameworks.

‍

When a framework version goes out of official support, HeroDevs steps in to:

• deliver security patches for old versions
  
  
• backport fixes long after vendors stop doing so
  
  
• maintain compliance for regulated industries
  
  
• reduce migration pressure
  
  
• keep long-lived applications secure while you modernize on your schedule
  
  

In a world where vulnerabilities emerge suddenly—even in “quiet” ecosystems—this kind of sustained support isn’t a luxury. It’s risk management.

Your frameworks don’t stand still. Attackers don’t stand still. Your security posture can’t stand still either.