CVE-2024-46982

What it actually does

This vulnerability allows cache poisoning of affected Next.js Pages Router applications. In vulnerable versions of Next.js 13.5.1 through 14.2.9, a crafted HTTP request to a non-dynamic server-side rendered Pages Router route can cause Next.js to treat a normally non-cacheable SSR response as cacheable and emit `Cache-Control: s-maxage=1, stale-while-revalidate`. If an upstream CDN, reverse proxy, or shared cache honors that response header, the poisoned response may be stored and served to later users. The App Router is not affected, dynamic Pages Router routes are not the described affected case, and deployments on Vercel are reported as unaffected.

Why it matters to the business

An attacker may be able to cause pages that should be generated privately or freshly for each request to be cached and delivered to other users. Depending on what the affected SSR pages render, this can lead to exposure of user-specific content, incorrect account state, stale business data, broken workflows, or reputational damage from users seeing content intended for someone else. The issue has a high CVSS score and a high EPSS score, indicating meaningful exploitation likelihood, although it is not currently listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns.

How an attack unfolds

An attacker first identifies a public Next.js application running an affected version and using the Pages Router with non-dynamic server-side rendered routes. They then select an SSR route that should not be cached, such as an authenticated dashboard or account page, and send a specially crafted HTTP request using headers or request characteristics that trigger the vulnerable caching behavior. The vulnerable Next.js server responds with cache directives such as `Cache-Control: s-maxage=1, stale-while-revalidate`, even though the route should remain non-cacheable. If a CDN or reverse proxy in front of the application respects that header, it may store the response. Subsequent users requesting the same route can then receive the cached poisoned response instead of a freshly rendered page, potentially exposing private or user-specific content or causing incorrect page rendering.

How to fix it

Upgrade Next.js to a fixed release outside the affected range. For source-based tracking, apply the upstream fix commit `681d59f76004734c98d5e4e257b75870b50c2402`; in package-managed deployments, use a Next.js release that contains that fix, such as 14.2.10 or later, and update any maintained 13.x branch to a patched version where applicable. Prioritize applications using the Pages Router with non-dynamic SSR routes. As defense in depth, configure CDN and reverse-proxy rules so authenticated or user-specific routes are never cached, strip untrusted internal/prefetch-related request headers at the edge where appropriate, and enforce explicit `Cache-Control: private, no-store` or equivalent headers on sensitive SSR pages. Applications using only the App Router and deployments on Vercel are reported as unaffected, but version upgrades are still recommended for consistency and future security fixes.

How to confirm the fix worked

Confirm the installed Next.js version using package manifests and dependency lockfiles, such as `package.json`, `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`, and verify it is not between 13.5.1 and 14.2.9 unless the fix commit has been backported. Inventory whether the application uses the Pages Router and contains non-dynamic SSR routes. In a staging environment, send normal and crafted requests to representative SSR Pages Router routes and verify that sensitive or user-specific pages do not return `Cache-Control: s-maxage=1, stale-while-revalidate` and are not stored by the CDN. Check CDN cache-status headers before and after testing to confirm the route is bypassing shared cache. After remediation, repeat the tests and verify that cache behavior remains non-cacheable for authenticated and personalized routes.

Typical attack path

1. Fingerprint the target as a Next.js application and infer or confirm that it uses an affected version between 13.5.1 and 14.2.9.
2. Identify non-dynamic Pages Router SSR routes, especially routes that render user-specific or sensitive content.
3. Send crafted HTTP requests to the target route that manipulate Next.js request handling and cause an unexpected cacheable response.
4. Observe whether the response includes `Cache-Control: s-maxage=1, stale-while-revalidate` or similar shared-cache directives on a route that should not be cacheable.
5. Rely on an upstream CDN, reverse proxy, or shared cache to store the response.
6. Trigger or wait for later requests to the same route so other users receive the cached response.

How to detect it

Review CDN, reverse-proxy, WAF, load balancer, and application access logs for suspicious requests to non-dynamic SSR Pages Router routes followed by unexpected cache hits. Focus on routes that should be private or uncacheable but returned `Cache-Control: s-maxage=1, stale-while-revalidate`, especially when paired with unusual prefetch, middleware, or internal Next.js request headers. Examine CDN cache analytics for sensitive paths showing `HIT`, `STALE`, `REVALIDATED`, or equivalent statuses. Look for sudden changes in cacheability, multiple users receiving identical HTML for authenticated pages, complaints about seeing another user's page state, or response bodies containing personalized data served from cache. If exploitation is suspected, preserve edge logs, application logs, CDN cache metadata, and representative cached objects where legally and operationally appropriate, then purge affected cache keys.

• Cache-Control: s-maxage=1, stale-while-revalidate
• x-middleware-prefetch
• Next-Router-Prefetch
• Purpose: prefetch
• Sec-Purpose: prefetch
• x-nextjs-data
• x-now-route-matches
• CDN-Cache-Status: HIT
• CF-Cache-Status: HIT
• X-Cache: HIT
• X-Cache: Hit from cloudfront
• Age:

What your security team should do

• Immediately inventory Next.js applications and identify any running versions 13.5.1 through 14.2.9 with Pages Router SSR routes.
• Prioritize patching internet-facing applications and applications that render authenticated, personalized, financial, operational, or otherwise sensitive content through non-dynamic Pages Router routes.
• Upgrade to a Next.js version containing fix commit `681d59f76004734c98d5e4e257b75870b50c2402`, preferably 14.2.10 or later where compatible.
• Review CDN, WAF, and reverse-proxy caching policies and ensure authenticated or user-specific paths are explicitly excluded from shared caching.
• Add monitoring for unexpected `Cache-Control: s-maxage=1, stale-while-revalidate` responses on SSR routes that should not be cacheable.
• Purge CDN and intermediary caches for affected routes after patching, especially if sensitive pages may have been cached.
• Search historical web, CDN, and application logs for crafted prefetch or internal-routing headers sent to SSR HTML routes.
• Document which applications use only the App Router or are deployed on Vercel, as these are reported unaffected by this specific issue.