In the process of remediating CVE-2025-29927, we looked at other possible exploits of Middleware. We independently verified this low severity vulnerability in parallel with two reports from independent researchers.

Summary

To mitigate CVE-2025-29927, Next.js validated the x-middleware-subrequest-id which persisted across multiple incoming requests:

 const randomBytes = new Uint8Array(8) 
 crypto.getRandomValues(randomBytes) 
 const middlewareSubrequestId = Buffer.from(randomBytes).toString('hex') 
 ;(globalThis as any)[Symbol.for('@next/middleware-subrequest-id')] = 
   middlewareSubrequestId 

However, this subrequest ID is sent to all requests, even if the destination is not the same host as the Next.js application.

 init.headers.set( 
   'x-middleware-subrequest-id', 
   (globalThis as any)[Symbol.for('@next/middleware-subrequest-id')] 
 ) 

Initiating a fetch request to a third-party within Middleware will send the x-middleware-subrequest-id to that third party.

Impact

While the exploitation of this vulnerability is unlikely due to an attacker requiring control of the third-party, we want to be proactive. We were already planning on removing this recursion prevention logic from Middleware—it was not supported in newer updates to Middleware to support the Node.js runtime—this disclosure expedited our efforts to bring parity between runtimes.

Vercel customers are protected with mitigations already implemented within our platform environment. We still encourage teams to update to the latest Next.js patch version or their chosen backport. Other infrastructure providers which host Next.js applications are not impacted by this, as it is specific to Vercel's implementation of recursion protection.

Remediation

This advisory was published in alignment with our new internal process for disclosure of vulnerabilities within OSS packages, based on our postmorten of CVE-2025-29927. We’ve patched 15.x, and offered backports for versions 12.x through 14.x, making an exception to our newly published LTS policy.

We’ve also worked proactively with new partners to Next.js for early disclosure. If you are an infrastructure provider and want to work with us, please email partners@nextjs.org.

Credit

Thank you to Jinseo Kim (kjsman) and ryotak for the responsible disclosure. These researchers were awarded as part of our bug bounty program.

Verified webhook providers—including Stripe and PayPal—are now automatically allowed in Attack Challenge Mode, ensuring uninterrupted payment processing. Well-behaved bots from major search engines, such as Googlebot, and analytics platforms are also supported.

Vercel Cron Jobs are now exempt from challenges when running in the same account. Like other trusted internal traffic, they bypass Attack Challenge Mode automatically.

To block specific known bots, create a custom rule that matches their User Agent. Known bots are validated to be authentic and cannot be spoofed to bypass Attack Challenge Mode.

Learn more about Attack Challenge Mode and how Vercel maintains its directory of legitimate bots.

Vercel now caches dependencies for projects using Yarn 2 and newer, reducing install times and improving build performance. Previously, caching was only supported for npm, pnpm, Bun, and Yarn 1.

To disable caching, set the environment variable VERCEL_FORCE_NO_BUILD_CACHE with a value of 1 in your project settings.

If you're using Yarn 4, enable Corepack, as recommended by Yarn.

Visit the Build Cache documentation to learn more.