A vulnerability affecting Next.js has been addressed. It impacted versions 15.0.4 through 15.1.8 and involved a cache poisoning bug leading to a Denial of Service (DoS) condition. Under certain conditions, this issue may allow a HTTP 204 response to be cached for static pages, leading to the 204 response being served to all users attempting to access the page More details: CVE-2025-49826
A cache poisoning issue in Next.js App Router >=15.3.0 and < 15.3.3 may have allowed RSC payloads to be cached and served in place of HTML, under specific conditions involving middleware and redirects. This issue has been fixed in Next.js 15.3.3. Users on affected versions should upgrade immediately and redeploy to ensure proper caching behavior. More details: CVE-2025-49005
A low-severity vulnerability in Next.js has been fixed in version 15.2.2. This issue may have allowed limited source code exposure when the dev server was running with the App Router enabled. The vulnerability only affects local development environments and requires the user to visit a malicious webpage while npm run dev is active. Because the mitigation is potentially a breaking change for some development setups, to opt-in to the fix, …
Summary We received a responsible disclosure from Allam Rachid (zhero) for a low-severity race-condition vulnerability in Next.js. This issue only affects the Pages Router under certain misconfigurations, causing normal endpoints to serve pageProps data instead of standard HTML. Learn more here Credit Thank you to Allam Rachid (zhero) for the responsible disclosure. This research was rewarded as part of our bug bounty program.
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.