What is the Next.js cache poisoning vulnerability (CVE-2025-49826) and how does it lead to Denial of Service (DoS) attacks?
A serious security flaw (CVE-2025-49826) was discovered in Next.js versions 15.1.0 to 15.1.8, allowing attackers to poison the cache and serve blank pages to users. This vulnerability impacts sites using Incremental Static Regeneration (ISR) with cache revalidation and Server-Side Rendering (SSR) where CDNs are configured to cache 204 HTTP responses. The issue arises due to a race condition with shared response objects, leading to persistent blank-page Denial of Service (DoS). The Next.js team has fully patched the bug in version 15.1.8. Immediate updates are strongly advised to prevent exploitation.
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
Insight | Detail |
---|---|
CVE ID | CVE-2025-49826 |
Impacted Versions | Next.js 15.1.0 to 15.1.8 |
Impact | Cache poisoning leads to DoS (blank pages for all users) |
Exploit Conditions | Affected version + ISR with revalidation + SSR with CDN caching 204 responses |
CVSS Score | 7.5 (High Severity) |
Fixed In | Next.js 15.1.8 and above |
How the Vulnerability Works (Simple Explanation)
The vulnerability targets how Next.js handles cached HTTP 204 responses under specific setups involving:
-
Incremental Static Regeneration (ISR) using cache revalidation (in
next start
or standalone deployments). -
Server-Side Rendering (SSR) combined with a CDN that caches 204 responses.
-
A shared response object used by Next.js that allows a race condition to occur.
Step-by-Step of the Attack
-
An attacker sends a request during cache revalidation.
-
Due to the race condition, the app incorrectly caches an HTTP 204 status (meaning “no content”).
-
That empty response gets stored in the cache.
-
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
Category | Details |
---|---|
Affected Versions | 15.1.0 to 15.1.8 |
Trigger | SSR + ISR + CDN caching 204 |
Root Cause | Race condition with shared response caching |
Consequence | Cached blank pages = DoS |
Exploitability | Remote, low complexity, high impact |
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
Best Practice | Why It Matters |
---|---|
Keep your Next.js version updated | Vulnerabilities are frequently patched in minor versions. |
Avoid caching 204 responses | They may be seen as “no content” by browsers and CDNs. |
Use independent response objects | Prevent race conditions. |
Test production-like deployments | Many bugs only appear under CDN and ISR behavior. |
Monitor for DoS symptoms | High traffic + blank pages may signal cache poisoning. |
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.
FAQs
What is CVE-2025-49826 in Next.js?
CVE-2025-49826 is a cache poisoning vulnerability in Next.js versions 15.1.0 to 15.1.8 that allows attackers to serve blank pages to users through a Denial of Service condition.
How does the cache poisoning attack work in Next.js?
It involves exploiting a race condition that caches HTTP 204 (No Content) responses, which then get served to all users as blank pages.
Which versions of Next.js are affected?
All versions from 15.1.0 to 15.1.8 are affected.
What is a 204 HTTP response?
It’s a response with no content. When cached incorrectly, it causes users to see a blank page.
What is Incremental Static Regeneration (ISR) in Next.js?
ISR allows pages to be updated in the background while serving static content. It's commonly used for performance optimization.
Does this issue affect SSR pages too?
Yes, the issue impacts Server-Side Rendering (SSR) routes with cache revalidation and CDN caching enabled.
What is the risk level of CVE-2025-49826?
It has a CVSS score of 7.5, which is considered high severity.
What’s the recommended fix for this vulnerability?
Update to Next.js version 15.1.8 or higher immediately.
Is this a remote or local vulnerability?
It is remotely exploitable through crafted requests that trigger cache poisoning.
Can Vercel-hosted applications be affected?
No, applications hosted on Vercel are not affected due to its unique deployment infrastructure.
What does cache poisoning mean?
It means inserting malicious or incorrect data into a cache, causing wrong content to be delivered to users.
Why is a race condition dangerous in this context?
It causes the cache to store an incorrect response (e.g., 204) due to timing issues in shared response handling.
Can this lead to server crashes?
No, it doesn’t crash servers but causes a Denial of Service by serving blank pages to users.
Is there a way to detect if my app is affected?
Yes, look for unusual spikes in HTTP 204 responses and complaints of blank pages from users.
Should CDNs cache 204 responses?
No, caching 204 responses is not recommended as they contain no content and may lead to unexpected behavior.
How does Next.js handle cache normally?
Next.js caches rendered pages using ISR and SSR depending on configuration and uses shared response objects to optimize performance.
How was the vulnerability fixed?
The patch removed the buggy code path and changed the caching architecture to avoid using shared responses.
How soon should I apply the update?
Immediately—especially if you use ISR and SSR in production.
Can this be exploited without user interaction?
Yes, it can be triggered through backend conditions and specific route timing without the user knowing.
How does this impact SEO or site traffic?
Blank pages delivered to search engines and users can harm SEO rankings and increase bounce rates.
What tools can help detect this vulnerability?
Application performance monitoring (APM) tools and custom logging can help detect anomalies in response codes.
Is CVE-2025-49826 specific to Next.js?
Yes, it’s specific to how Next.js handles ISR/SSR caching with shared responses.
What kind of sites are most at risk?
High-traffic websites using static regeneration with SSR and CDN caching.
Can security headers help mitigate this issue?
They help in general, but won’t prevent cache poisoning caused by internal framework bugs.
Is manual testing enough to catch this bug?
Not always. It requires real-time traffic and cache behavior to reproduce reliably.
Does disabling ISR solve the problem?
Disabling ISR may reduce exposure, but updating to the patched version is the correct solution.
Should dev teams audit CDN settings?
Yes, ensure 204 responses are not cached and investigate how the CDN handles content negotiation.