CVE-2025-29927 - Next.js

A recently identified vulnerability, CVE-2025-29927, affects the Next.js framework, a popular choice for building React-based web applications. This critical security flaw, assigned a CVSS score of 9.1, enables attackers to bypass authorization mechanisms implemented via Next.js middleware, potentially granting unauthorized access to sensitive resources.

This vulnerability impacts the following Next.js : Versions from 11.1.4 through 13.5.6, 14.x before 14.2.25, and 15.x before 15.2.3 are vulnerable.

The root cause of this issue lies in the handling of the x-middleware-subrequest header by Next.js.

• This header is internally used by Next.js to prevent infinite request loops.

• Attackers can manipulate this header to bypass security middleware, allowing requests to reach protected routes without proper authorization checks.

• By injecting this header into a malicious request, an attacker can exploit the system's reliance on middleware-based authorization.

However, identifying and verifying this vulnerability can be particularly tricky.

Why? Because the vulnerability only affects applications that rely solely on middleware-based authorization. This is a very specific configuration from developer or system operators. Most of all, If additional security layers are in place, the exploit may not be immediately visible.

To detect the real exploitability of the vulnerability, a deep understanding of the application and how it has been built is needed. The specific configuration and installation of all NextJS framework needs to be analyzed, the detection of pages protected by NextJS security mechanism needs to be automated, and all results need to be analyzed with accuracy.

This, of course, cannot be performed by classic security scanners, EASM or ratings solutions. This only could be done in one shot by a Pentester or Hunters. Patrowl is the only solution allowing our customers to check this vulnerability at scale, with precision, on all your assets exposed continuously!

To identify vulnerable applications, we relied on a funnel approach:

• Exclude applications not using the Next.js framework

• Exclude applications running on a non-vulnerable version

• Extensively crawl the remaining applications to find endpoints

• Test exploitation payloads on these endpoints

Trying to skip the first steps and trying to send payloads on random paths on every single application we monitored would be infeasible, very verbose and inefficient.

Identifying next.js applications

Multiple criteria could help to identify next.js applications:

• Some servers respond with a verbose header: X-Powered-By: Next.js

• By default, assets generated by next.js (e.g. js and css files) are stored in the /_next/static directory:

• next.js applications expose a global next JavaScript object in the browser. This object contains a version field that returns the next.js version used by the application:

Combining these techniques, we achieved to find, with a strong confidence, next.js applications running on a vulnerable version.

Further analysis

At this point, any client exposing a next.js application running on a vulnerable version has been alerted for them to quickly update their products.

However, running on a vulnerable version does not mean that the vulnerability could be exploited on the application. Indeed, we still have not confirmed that the faulty middleware is used and we have not identified any vulnerable path.

First of all, we need a way to check if a given path is vulnerable. A good Nuclei template has been released by Project Discovery:

https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2025/CVE-2025-29927.yaml

While this template is good, it will only return results if you run it on a path protected by the auth middleware.

Finding such paths is tricky. Indeed, relying purely on a crawling strategy appears to be pretty inefficient. First of all, many next.js applications are SPA (Single Page Applications) and crawling SPA is known to be challenging because it often requires to rely on a headless browser, which is very resource-intensive and slow. Moreover, potentially vulnerable paths are, by design, protected by an authorization mechanism and are unlikely to be found by an anonymous crawler.

We still tried to run the detection template on paths identified by crawling the applications and, as expected:

But we can do way better!

At Patrowl, we are used to finding hidden entrypoints, especially for SPA applications. The idea is that pretty much all paths of an SPA could be found in the JavaScript files it loads. Therefore, by performing source code analysis on these files, we can retrieve hidden paths that could not be found by crawling the app.

For this technique, we have developed a tool that uses TreeSitter with custom queries and a custom variable resolution mechanism to be as precise as we could given the complexity of the minified JavaScript content we analyze. It allows us to analyze this kind of patterns:

Running our tool on this JS content will return:

So, finally, using our understanding on the vulnerability and the way to find entry points, we simply automate it for each potentially vulnerable application:

• Fetch all .js files loaded by the application

• Analyze them to find entrypoints using our JS analyzer tool

• Run the detection template on these entrypoints

This approach is efficient, avoids stressing out our clients’ applications, scalable and easily automated! All our customers now know, in the most accurate way, if they are vulnerable or not.

Now how to patch this vulnerability (if you don’t have Patrowl yet)

Upgrade Next.js to a patched version:

• For Next.js 15.x, update to version 15.2.3 or later.

• For Next.js 14.x, update to version 14.2.25 or later.

• For Next.js 13.x, update to version 13.5.9 or later.

• For Next.js 12.x, update to version 12.3.5 or later.

These versions contain fixes that address the vulnerability.

You can also implement temporary mitigation if immediate patching isn’t feasible:

• Configure your web server, WAF or proxy to block or unset the x-middleware-subrequest header from external requests.

• monitor for any suspicious requests containing this header (brute force on specific paths like explained in this article for example.

Recommendations:

• Prioritize updating Next.js to the latest patched version to fully remediate the vulnerability.

• Review your application’s middleware configurations to ensure that authorization checks are robust and not solely reliant on potentially vulnerable components.

• Monitor official Next.js communications for any further updates or advisories related to this vulnerability.

• Or, the best one : contact us if you want your assets to be continuously protected by Patrowl!