Next.js Middleware CVE-2025-29927: What Does it Mean for Sitecore Customers?

What’s in it for Me?

CVE-2025-29927, you heard it everywhere recently. You are a Sitecore customer using Next.js for your website(s) and you need to know what to do now. This article is for you. We will cover:

• What is CVE-2025-29927?
• What are the possible exploits for your Sitecore websites?
• Is your website vulnerable or not?
• How to protect your vulnerable website?

What is CVE-2025-29927?

CVE-2025-29927 is a critical vulnerability with a score of 9.1/10 in these versions of Next.js:

• 11.1.4
• 12.0.0 to 12.3.4
• 13.0.0 to 13.5.8
• 14.0.0 to 14.2.24
• 15.0.0 to 15.2.2

The vulnerability is in the Next.js middleware feature and how it handles middleware code that sends HTTP requests that could cause an infinite loop of calls.

The vulnerability has been fixed in these Next.js releases:

• 12.3.5
• 13.5.9
• 14.2.25
• 15.2.3

Possible Exploits

In general, the possible exploits caused by this vulnerability are:

• Authorization/Rewrite bypass.
  • If authorization/rewrite is handled via middleware.
• Content Security Policy (CSP) bypass.
  • If CSP is set via middleware.
• Denial of Service (DoS) via Cache-Poisoning.
  • In some cases with preconditions.

For Sitecore websites, we can add SXA redirects bypass to this list. This could allow access to pages that should not be publicly accessible at those URLs that should normally be redirected. For example:

• You have a /Home/old-page Sitecore page item that is still published.
• You have a SXA redirect in place to redirect /old-page to /new-page.
• By exploiting this vulnerability, someone could bypass the SXA redirects and get access to /old-page.

Is My Website Vulnerable?

First, your website is not vulnerable if:

• Your website is hosted on Vercel.
• Your website is hosted on Netlify.
  • Netlify's implementation of the Next.js runtime exports middleware into Netlify Edge Functions without this bypass in place.
• Your website is hosted elsewhere and deployed as static exports.
  • Middleware is not executed on static exports.

Your website is vulnerable if it meets all these criteria:

• It is not hosted on Vercel/Netlify and deployed as an application (next start).
• It is using middleware.
  • Especially if it relies on middleware for authentication, authorization, or security checks, which are not then validated later in your application.
• It is using a vulnerable version of Next.js.

Which Next.js Version is My Website Using?

To know which version of Next.js your website is using:

1. Open the project package-lock.json file.
2. Search for "node_modules/next" (with the double quotes).

The JSON object version property is your project Next.js version.

Example of a package-lock.json Next.js version:

{
  ...
  "packages": {
    ...
    "node_modules/next": {
      "version": "14.2.16",
      ...
    },
    ...
  }
}

My Website is Vulnerable, How Can I Fix it?

If your website is using Cloudflare as a proxy, one easy way to protect it is to turn on the new opt-in Web Application Firewall (WAF) rule specific to this vulnerability. The rule is opt-in as it could cause issues like failing requests, especially with sites that use auth middleware with third-party auth vendors. Make sure to test your website thoroughly after enabling the rule. Rollback and use another method if necessary.

It should be very rare, but if your website is using Next.js 11.1.4, there is no fixed Next.js release. It is then recommended that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application. This can be done using the Cloudflare method above or another way.

If your website is using a vulnerable Next.js 12.x, 13.x, 14.x, or 15.x version, a developer on your team can update Next.js to the latest patch for the major version you are using. This guide assumes you have a GitFlow release process with branches and environments for DEV, QA, and PROD. Adjust these steps for your specific solution.

1. From the DEV branch, create and checkout a new CVE-2025-29927 branch in your source control system.
2. To install the latest release with the issue fixed, run the npm update next command.
   • This will modify both the package.json and package-lock.json files.
3. Thoroughly test everything in your local development environment including, if relevant for you: The public website, Experience Editor, Pages Builder, Storybook, etc.
4. Fix issues, if any.
5. Commit both the package.json and package-lock.json files and any other files involved in fixed issues in the CVE-2025-29927 branch.

Then, deploy the changes to your DEV environment:

1. Create a pull request (PR) from the CVE-2025-29927 branch to the DEV branch.
2. Have the PR code reviewed by a peer.
3. Merge the PR into the DEV branch.
4. Deploy the DEV branch to the DEV environment.
5. Test in the DEV environment.

If the tests are going well, continue the release process to QA and PROD. Make sure to test in each environment.

Closing Thoughts on CVE-2025-29927

Not a lot of Sitecore headless websites will require a remediation action on your part as most of them are hosted on Vercel or Netlify. If that is not your case, I hope this article was valuable to understand and mitigate the issue.

Happy Sitecoring!

Sources

• https://github.com/advisories/GHSA-f82v-jwr5-mffw
• https://nextjs.org/blog/cve-2025-29927
• https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware
• https://x.com/Netlify/status/1903455739894472800
• https://developers.cloudflare.com/changelog/2025-03-22-next-js-vulnerability-waf/