CVE-2026-94543 in Next.js
Summary
by MITRE • 10/02/2026
Next.js is a React framework for building full-stack web applications. From 15.0.0 until 15.5.27 and 16.3.8, self-hosted applications using the Pages Router with statically generated or Incremental Static Regeneration pages can key a response cache entry without sufficiently binding it to the source route. A request can replace one page's cache entry with content from a different route, causing the affected page to serve incorrect content to every visitor until revalidation. Applications deployed on Vercel are not affected. This issue is fixed in versions 15.5.27 and 16.3.8.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified within Next.js frameworks, specifically affecting self-hosted deployments utilizing the Pages Router between version 15.0.0 and 15.5.27 as well as versions up to 16.3.8, represents a critical flaw in how static content caching is managed during request processing. This issue stems from an insufficient binding mechanism that fails to adequately associate response cache entries with their originating source routes. In standard web application architecture, particularly those employing Incremental Static Regeneration or statically generated pages, the system relies on precise mapping between incoming requests and cached responses to ensure data integrity and consistency. When this association is weakened or missing, the caching layer becomes susceptible to manipulation where a request intended for one specific route can inadvertently overwrite or replace the cache entry designated for a completely different route. This architectural weakness allows an attacker to inject malicious content into the cache of unrelated pages by crafting requests that exploit the loose coupling between the URL path and the cached response metadata.
From a technical perspective, this flaw aligns with CWE-20 Improper Input Validation as it involves the failure to properly validate or bind input parameters to their expected context within the caching subsystem. Furthermore, because the vulnerability allows an attacker to manipulate what content is served to users without direct authentication in many scenarios, it falls under the ATT&CK technique of T1498 Network Denial of Service via Logic Errors if used for disruption, but more critically relates to data integrity violations similar to CWE-352 Cross-Site Request Forgery principles where trust boundaries are bypassed. The core issue lies in the server-side logic that generates cache keys; instead of including unique identifiers or strict route mappings that prevent cross-route contamination, the implementation uses a method that allows one page's dynamic content generation process to overwrite another page's static assets. This means that if an attacker can trigger the regeneration or caching mechanism for a specific endpoint with malicious payloads embedded in headers or query parameters, those payloads may be stored and subsequently served as legitimate content from unrelated pages.
The operational impact of this vulnerability is severe due to its potential for widespread misinformation and security compromise across all visitors accessing the affected application until cache revalidation occurs. Since self-hosted applications are directly responsible for managing their own caching infrastructure without the protective abstractions provided by managed platforms like Vercel, they lack the additional safeguards that might mitigate such logic errors in cloud environments. Users visiting any page on the site could be served content intended for a different route, leading to potential exposure of sensitive data if administrative pages are affected or delivery of malicious scripts if script-heavy routes are targeted. This effectively creates a persistent cross-site scripting vector or information disclosure channel depending on how the cached response is rendered by the browser client. The persistence of this incorrect state until revalidation means that even after the initial attack request ceases, victims continue to receive compromised content, amplifying the blast radius significantly beyond the immediate moment of exploitation.
Mitigation strategies must prioritize upgrading to patched versions immediately if operating on self-hosted infrastructure using the Pages Router with static generation capabilities. For organizations unable to upgrade instantly due to compatibility constraints or testing requirements, implementing a reverse proxy layer such as Nginx or Apache can provide an additional control plane by enforcing strict URL-to-backend routing rules that prevent ambiguous cache key resolution at the edge level. Additionally, developers should review their caching configurations to ensure that cache keys explicitly include route identifiers and path segments in a manner that prevents collision between distinct endpoints. Disabling Incremental Static Regeneration for sensitive routes or switching to client-side data fetching patterns where appropriate can also reduce the attack surface by removing reliance on server-side static caches vulnerable to this specific logic flaw until permanent remediation is deployed through version updates to 15.5.27 or 16.3.8 and beyond.