Vulnerability Name: React / Next.js React Server Components Denial of Service
CVE ID: CVE-2025-67779
Vulnerability Type: Denial of Service (DoS)
Severity: High
CVSS Score: High (impact-based; availability focused)
Exploitability: Yes – Remotely exploitable via crafted requests, no authentication required

What’s happening ?

This situation started with a Denial of Service bug in React Server Components, which are heavily used by Next.js for server-side rendering. That original issue was tracked as CVE-2025-55184, and many teams patched their apps as soon as fixes were released.

The problem is that the fix didn’t fully solve it.

After more testing and real-world use, it became clear that certain edge cases were still causing applications to crash or become unresponsive. Because of that, a new CVE – CVE-2025-67779 – was assigned around 14-15 December 2025 to track the remaining vulnerability.

So this isn’t a brand-new bug. It’s the same underlying problem that wasn’t fully closed the first time.

What actually goes wrong inside the app

At a high level, the issue lives in how server-side rendering handles certain inputs and component states. Under specific conditions, React Server Components can end up doing far more work than expected.

When that happens:

• CPU usage spikes
• Memory usage climbs quickly
• Requests take longer and longer to finish
• Eventually the Node.js process crashes or restarts

From the outside, it just looks like the site goes down.

No data is stolen. No code is injected. But availability is lost — and for production apps, that’s enough to cause real damage.

Why the first fix wasn’t enough

The initial patch focused on the most obvious failure paths. That helped in many cases, but it didn’t cover every way a request could trigger excessive rendering or recursion.

In real deployments:

• Apps use custom components
• Routing logic varies
• Some requests are malformed or unexpected
• Some pages mix static and dynamic rendering in complex ways

Those combinations exposed gaps in the original fix, which is why crashes were still happening even on “patched” systems.

How this can be abused (or triggered accidentally)

This vulnerability doesn’t require special access.

A request hitting the wrong route, with the wrong structure, can:

• Trigger repeated server-side renders
• Lock up the event loop
• Cause the app to stop responding

An attacker could intentionally send repeated requests like this to knock a site offline. But it can also happen accidentally — for example:

• A crawler hitting unexpected URLs
• A broken client repeatedly retrying
• A bad deployment exposing unstable routes

Either way, the result is the same: denial of service.

Who is most affected

You’re more exposed if:

• You use Next.js with React Server Components
• You rely heavily on server-side rendering
• Your app is public-facing
• You already patched once and assumed you were done

Apps that are fully static are less likely to hit the issue, but many real-world Next.js apps are a mix of static and dynamic rendering, which puts them back in scope.

Versions that actually fix it

To fully address the issue, Next.js needs to be updated again, even if you already patched earlier this month.

The safe versions currently are:

• Next.js 14.2.35 or newer
• Next.js 15.1.11 or newer

Anything below those may still be vulnerable, even if it includes the earlier fix.

How teams are noticing the problem

This issue often doesn’t show up as a clear security alert. Instead, teams see symptoms like:

• Random crashes under load
• Sudden spikes in CPU or memory
• Pages that hang or never finish loading
• Containers restarting repeatedly
• Health checks failing for no obvious reason

Because it looks like “instability,” it’s easy to misdiagnose.

What to watch for right now

If you can’t upgrade immediately, keep an eye on:

• SSR routes with unusually long response times
• Requests that consistently trigger crashes
• Restart loops in Node or container logs
• Error rates rising without code changes

Even simple monitoring around response time and restarts can help surface this.

What actually fixes it

The only real fix is upgrading to the latest Next.js releases mentioned above.

Temporary mitigations can reduce impact but won’t fully solve it:

• Rate-limiting public SSR routes
• Adding stricter request timeouts
• Reducing dynamic rendering where possible
• Blocking obviously malformed requests

These help keep things stable, but they’re not substitutes for patching.

Why this situation matters beyond this bug

This is a good example of a broader pattern:

• Framework bugs can have massive reach
• A CVE being “fixed” doesn’t always mean “done”
• Dependency updates need verification, not blind trust
• Availability issues can be just as damaging as data breaches

Teams did the right thing by patching early — the problem is that the fix itself needed another round.

Bottom line

CVE-2025-67779 exists because the original fix for a React Server Components DoS issue didn’t cover all real-world cases. If you run Next.js and rely on server-side rendering, you need to upgrade again, even if you already patched recently.

This isn’t about panic or blame. It’s about avoiding unexpected outages caused by a problem that looked solved but wasn’t.