Cloudfest Conference 2025

Use code HH20 for 20% off an event ticket!

Yesterday's Top Poster

CVE-2025-32421

  • Thread starter Thread starter Ty Sbano
  • Start date Start date
A low severity cache poisoning vulnerability was discovered in Next.js.

Summary​


This affects versions [B]>14.2.24[/B] through <15.1.6 as a bypass of the previous CVE-2024-46982. The issue happens when an attacker exploits a race condition between two requests — one containing the?__nextDataRequest=1 query parameter and another with the x-now-route-matches header.

Some CDN providers may cache a 200 OK response even in the absence of explicit cache-control headers, enabling a poisoned response to persist and be served to subsequent users.

Affected Versions​


  • Next.js versions [B]>14.2.24[/B] through <15.1.6

Impact​


This vulnerability allows an attacker to poison the CDN cache by injecting the response body from a non-cacheable data request (?__nextDataRequest=1) into a normal request that retains cacheable headers, such as Cache-Control: public, max-age=300.

No backend access or privileged escalation is possible through this vulnerability.

This issue was verified using automated tooling that repeatedly triggers the race condition. Successful exploitation depends on precise timing and the presence of a vulnerable CDN configuration. A Python-based proof of concept script was shared by the reporter and used to validate this behavior on live targets prior to the patch.

Patches​


This issue was patched in 15.1.6 and 14.2.24 by stripping the x-now-route-matches header from incoming requests.

Vercel Platform Mitigation​


Applications hosted on Vercel's platform are not affected by this issue, as the platform does not cache responses based solely on 200 OK status without explicit cache-control headers.

Workarounds​


For self-hosted Next.js deployments unable to upgrade immediately, you can mitigate this vulnerability by:


  • Stripping the x-now-route-matches header from all incoming requests at your CDN


  • Setting cache-control: no-store for all responses under risk

We strongly recommend only caching responses with explicit cache-control headers.

Credit​


Thank you to Allam Rachid (zhero;) for the responsible disclosure. They were awarded as part of our bug bounty program.

Read more

Continue reading...
 
Back
Top