
The SonicWall Capture Labs threat research team became aware of an authorization bypass vulnerability in Next.js, assessed its impact, and developed mitigation measures. Next.js is a react framework designed to simplify building web applications, focusing on performance, SEO, and ease of use. It provides features like server-side rendering (SSR), static site generation (SSG), and automatic code splitting, making it a popular choice for building fast and scalable web applications.
Affected versions of Next.js allow unauthenticated attackers to circumvent authorization checks within a Next.js application, provided the authorization check occurs in middleware, which allows a developer to run code before a request is completed and modify the response based on the incoming request. Considering the publicly available technical details and ease of exploitation, users are strongly encouraged to upgrade their instances to the latest fixed version, as mentioned in the vendor advisory.
Next.js has its own middleware and is widely used among developers. According to its creators, the effective use cases of middleware are redirects, path rewrites, and adding/modifying headers. However, it is not a good fit for slow data fetching and session management, i.e., to handle authentication and authorization. However, many Next.js applications are using middleware for authorization purposes despite not being a recommended method to grant access.
This vulnerability arises due to a flaw in how Next.js decides whether to apply middleware or not using an internal header – x-middleware-subrequest. As seen in Figure 1, the code separates the list of subrequests from the header by splitting the values by column (:) and then verifies if the list contains the value of middlewareInfo.name - the path where the middleware is located. If a request includes the expected value of middlewareInfo.name in the x-middleware-subrequest header, it would be forwarded to the destination, bypassing middleware checks.

Interestingly, the value of middlewareInfo.name, which indicates the path of middleware.js or middleware.ts, is predictable. The possible paths for middleware in different Next.js versions are as follows:
Before version 12.2
The middleware file was named _middleware and can be placed at any level of subdirectory which is being accessed. For instance, to access /admin/dashboard, the middleware can be placed inside any of the following directories /pages/admin/dashboard/, such as pages/_middleware or pages/admin/_middleware. Therefore, if the middleware is placed inside the admin directory, the header value to bypass the middleware can be set as follows.
x-middleware-subrequest: pages/admin/_middleware
From version 12.2 to 13
The path of middleware has been fixed to the root of the project or in the /src directory, and naming conventions were changed to middleware.js/middleware.ts. Hence, the header values to bypass middleware are fixed as follows.
x-middleware-subrequest: middleware OR
x-middleware-subrequest: src/middleware
Version 13 onwards
The logic was changed slightly to detect and prevent recursion. As seen in Figure 2, the code separates the list of subrequests from the header by splitting the values by column (:). Then, if the list contains items equal to or greater than MAX_RECURSION_DEPTH (5), it bypasses the middleware functionality. Hence, the header values to bypass middleware would be as follows:
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware OR
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Exploiting this vulnerability allows the remote threat actor to bypass authorization checks of the protected paths, provided the checks are implemented in middleware. Exploitation is straightforward. As seen in Figure 3, remote threat actors can bypass authorization controls using a malicious x-middleware-subrequest header.
Figure 3: Exploit in action
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature (Informational) has been released. However, considering the nature of vulnerability and the possibility of false positives (FPs) due to potential legitimate usage of the x-middleware-subrequest header, customers are advised to enable the signature after doing the due diligence by determining the usage of the said header to eliminate FPs.
Given the ease of exploitation, SonicWall sensors are observing a large number of exploitation attempts. Additionally, considering the prevention signature's FP-prone nature, Next.js users are strongly encouraged to update their instances to the latest version, as mentioned in the vendor advisory.
Share This Article

An Article By
An Article By
Security News
Security News