What is the Next.js cache poisoning vulnerability (CVE-2025-49826) and how does it lead to Denial of Service (DoS) attacks?

Table of Contents

• What Happened in Next.js?
• Key Takeaways
• How the Vulnerability Works (Simple Explanation)
• What Makes This Dangerous?
• Risk Matrix
• Remediation: How to Fix It
• What If You're Using Vercel?
• Security Best Practices for Next.js Developers
• Conclusion
• Frequently Asked Questions (FAQs)

A critical vulnerability in Next.js, the popular React-based web framework, has raised serious concerns across the developer and cybersecurity community. Identified as CVE-2025-49826, this cache poisoning flaw allows attackers to create Denial of Service (DoS) conditions by delivering blank pages to all users.

Let’s break down what happened, how it works, who’s affected, and what you should do next.

 What Happened in Next.js?

Versions 15.1.0 to 15.1.8 of Next.js contain a bug in how they handle HTTP 204 (No Content) responses. Under specific circumstances, this bug lets attackers poison the cache with an empty response. This means users visiting static pages could be served blank pages, effectively taking parts of the site offline.

 Key Takeaways

How the Vulnerability Works (Simple Explanation)

The vulnerability targets how Next.js handles cached HTTP 204 responses under specific setups involving:

1. Incremental Static Regeneration (ISR) using cache revalidation (in next start or standalone deployments).

2. Server-Side Rendering (SSR) combined with a CDN that caches 204 responses.

3. A shared response object used by Next.js that allows a race condition to occur.

 Step-by-Step of the Attack

1. An attacker sends a request during cache revalidation.

2. Due to the race condition, the app incorrectly caches an HTTP 204 status (meaning “no content”).

3. That empty response gets stored in the cache.

4. Every other user requesting that page is now served a blank page, causing a Denial of Service.

 What Makes This Dangerous?

• A DoS attack that doesn’t crash servers—but makes pages invisible.

• Impacts high-traffic websites using ISR for performance.

• May go unnoticed during development unless tested under real CDN configurations.

 Risk Matrix

 Remediation: How to Fix It

The Next.js team patched this issue in version 15.1.8, with the following changes:

• Removed the faulty logic that allowed 204 responses to be cached.

• Refactored how Next.js handles shared responses in the cache pipeline.

• Ensured that race conditions in the cache don’t lead to inconsistent states.

 What You Should Do

• Update to version 15.1.8+ immediately.

• Test your ISR and SSR routes, especially those using cache revalidation.

• Review your CDN settings to avoid caching 204 responses.

• Monitor application logs for unusual 204 response spikes.

What If You're Using Vercel?

Good news: Vercel-hosted applications are not affected. Their internal CDN and ISR logic prevent this type of cache poisoning attack, according to their security advisory.

 Security Best Practices for Next.js Developers

Conclusion

This cache poisoning vulnerability in Next.js highlights how complex features like ISR, SSR, and CDN caching can introduce new attack vectors—even in popular frameworks. While the vulnerability is patched, it serves as a strong reminder to:

• Test how your app handles different status codes.

• Watch out for shared resource race conditions.

• Stay current with framework updates, especially for production deployments.