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. Learn more here.
It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.
A Denial of Service (DoS) attack allows attackers to construct requests that leaves requests to Server Actions hanging until the hosting provider cancels the function execution. Note: Next.js server is idle during that time and only keeps the connection open. CPU and memory footprint are low during that time. Deployments without any protection against long running Server Action invocations are especially vulnerable. Hosting providers like Vercel or Netlify set a …
If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.
The image optimization feature of Next.js contained a vulnerability which allowed for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption. Not affected: The next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value. The Next.js application is hosted on Vercel.
By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well. To be potentially affected …
A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server. This vulnerability can affect all Next.js deployments on the affected versions.
Inconsistent interpretation of a crafted HTTP request meant that requests are treated as both a single request, and two separate requests by Next.js, leading to desynchronized responses. This led to a response queue poisoning vulnerability in the affected Next.js versions. For a request to be exploitable, the affected route also had to be making use of the rewrites feature in Next.js.
A Server-Side Request Forgery (SSRF) vulnerability was identified in Next.js Server Actions by security researchers at Assetnote. If the Host header is modified, and the below conditions are also met, an attacker may be able to make requests that appear to be originating from the Next.js application server itself.
Next.js before 13.4.20-canary.13 lacks a cache-control header and thus empty prefetch responses may sometimes be cached by a CDN, causing a denial of service to all users requesting the same URL via that CDN.
Next.js is a React framework that can provide building blocks to create web applications. All of the following must be true to be affected by this CVE: Next.js version 12.2.3, Node.js version above v15.0.0 being used with strict unhandledRejection exiting AND using next start or a custom server. Deployments on Vercel (vercel.com) are not affected along with similar environments where next-server isn't being shared across requests.
Impact When specific requests are made to the Next.js server it can cause an unhandledRejection in the server which can crash the process to exit in specific Node.js versions with strict unhandledRejection handling. Affected: All of the following must be true to be affected by this CVE Node.js version above v15.0.0 being used with strict unhandledRejection exiting Next.js version v12.2.3 Using next start or a custom server Not affected: Deployments …
Next.js is vulnerable to User Interface (UI) Misrepresentation of Critical Information. In order to be affected, the next.config.js file must have an images.domains array assigned and the image host assigned in images.domains must allow user-provided SVG. If the next.config.js file has images.loader assigned to something other than default, the instance is not affected. As a workaround, change next.config.js to use a different loader configuration other than the default.
Next. one must use next start or a custom server and the built-in i18n support. Deployments on Vercel, along with similar environments where invalid requests are filtered before reaching Next.js, are not affected. A patch has been released, next@12.0.9, that mitigates this issue. As a workaround, one may ensure /${locale}/_next/ is blocked from reaching the Next.js instance until it becomes feasible to upgrade.
Next handling invalid or malformed URLs could lead to a server crash. Deployments on Vercel are not affected, along with similar environments where invalid requests are filtered before reaching Next.js.
Next is vulnerable to XSS.
Next.In general, this redirect does not directly harm users although can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain.
Next.js is vulnerable to an Open Redirect. Specially encoded paths could be used with the trailing slash redirect to allow an open redirect to occur to an external site. In general, this redirect does not directly harm users although can allow for phishing attacks by redirecting to an attackers domain from a trusted domain.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in next.
Next.js contains a directory traversal vulnerability. Attackers could craft special requests to access files in the dist directory (.next). This does not affect files outside the dist directory (.next). In general, the dist directory only holds build assets unless your application intentionally stores other assets under this directory.
Next.js suffers from XSS via the /_error pages.
Next.js has Directory Traversal in the /_next request namespace.
Next has directory traversal under the /_next and /static request namespace, allowing attackers to obtain sensitive information.