Security changelog

Impact

With Cache Components enabled (cacheComponents: true), a 'use cache' function that calls another 'use cache' function that reads a root param can be keyed incorrectly when the inner call is served from an existing entry: the enclosing function’s cache key then omits that root param.

Impact

Crafted requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive CPU usage blocking processing of further requests in the same process.

Workarounds

No workaround exists besides upgrading. Applications using Pages Router or not using Server Actions are not vulnerable.

Impact

A vulnerability in applications using App router with Cache Component can lead to remote code execution. The application needs to have a use cache function that returns multiple typed arrays.

Workaround

There is no known workaround for affected applications with such use cache functions. You should upgrade immediately even if your application does not have similar functions.

Impact

A memory-related vulnerability has been discovered in an upstream library used for Image Optimization can lead to possible remote code execution (RCE) when Next.js runs on glibc-based Linux.

Workaround

Ensure the version of sharp used by Next.js is greater than or equal to 0.35.5. Fresh installs automatically get a fixed version of sharp. Upgrading Next.js to the patched versions will ensure package managers automatically provide a fixed version of sharp to Next.js.

Next.js applications that use a root-level catch-all page together with statically generated or Incremental Static Regeneration routes can have their shared response cache poisoned by a single unauthenticated crafted request.

Self-hosted Next.js applications that use the Pages Router with statically generated (SSG) or incrementally regenerated (ISR) pages can have a page’s cache entry replaced with content from a different route, causing the affected page to serve wrong content to every visitor until the entry is revalidated. Applications deployed on Vercel are not affected.

In Next.js App Router applications built with webpack, metadata image routes such as opengraph-image and twitter-image ignore the dynamicParams route segment option. An attacker can request metadata image URLs for dynamic segments that were deliberately excluded from generateStaticParams().

The Next.js development server (next dev) exposes a Model Context Protocol endpoint that does not verify which website a request originates from, allowing a malicious website visited by the developer to read sensitive development data — including the project’s location on disk, source code snippets from error reports, the route inventory, and development logs. Only applications run with next dev are affected. Production deployments do not serve this endpoint.

Impact

An attacker-controlled, allow-listed remote URL can lead to server-side request forgery (e.g. to private IPs) during Image Optimization.

Workaround

Audit allow-listed remote URLs in images.remotePatterns (see https://nextjs.org/docs/app/getting-started/images#remote-images) for hosts that may not be trusted with their DNS entries. If no images.remotePatterns are configured, your app is not affected.

Pending use cache fills are shared across requests for the same key without distinguishing Draft Mode requests from regular requests. When two such requests overlap, the second request receives the first request’s fill:

• A regular request that overlaps an editor’s Draft Mode request receives unpublished content, without any authentication.
• A Draft Mode request that overlaps a regular request receives published content instead of the draft.

Impact

The Node.js ImageResponse implementation from next/og is affected by an upstream vulnerability. This can lead to remote code execution.

A vulnerability in the underlying libheif library used by sharp which Next.js uses for image optimization can lead to remote code execution when AVIF files are optimized.

Until a fix has propagated, optimization of AVIF files is disabled.

Impact

A vulnerability in applications using Pages and App router without Cache Component can lead to remote code execution when the server is hosted on machines using a Windows filesystem.

Workaround

There is no known workaround for affected windows-hosted applications. You should upgrade immediately if your server is hosted on Windows.

Impact

A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST’s response body would then leak to unauthorized requests. Though the request itself will not be deduped.

This only applies to fetch calls with a request that has a different init than the one passed to fetch. Safe: fetch(new Request(init), init) Unsafe: fetch(new Request(init), aDifferentInit)

Impact

A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST’s response body would then leak to unauthorized requests. Though the request itself will not be deduped.

This is only an issue when receiving request bodies with a content type charset other than UTF-8. For example, the UTF-16 byte sequences for 삃삃 and 섄섄 in the request body would share the same cache.

Impact

Crafted requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive CPU usage blocking processing of further requests in the same process.

Workarounds

No workaround exists besides upgrading. Applications using Pages Router or not using Server Actions are not vulnerable.

Impact

When self-hosting Next.js with the default image loader, the Image Optimization API can optimize remotely hosted images if configured (not enabled by default). If those images contain malicious content, they can cause CPU exhaustion in /_next/image endpoints.

• If you are using config.images.remotePatterns, only the patterns in that array are impacted.
• If you are using config.images.unoptimized: true, you are NOT impacted.

Impact

Crafted requests targeting Next.js applications using App Router built with Turbopack and a single entry in config.i18n.locales can bypass middleware/proxy based authentication.

Workarounds

If you cannot upgrade immediately, enforce authorization in the page’s server-side data path instead of relying solely on middleware.

Impact

A rewrites() or redirects() rule that builds its external destination hostname from request-controlled input can be pointed at an arbitrary hostname, regardless of the rule’s hostname suffix. For a rewrite, Next.js proxies the request to that arbitrary host and serves the response from the application’s origin, leading to Server-Side Request forgery. A redirects() rule configured this way is vulnerable to an Open Redirect.

Impact

When a Server Action forwards or redirects a request, an attacker can cause the server to send that outbound request to a malicious host (Server-Side Request Forgery). This requires the attacker’s request to control Host-associated headers. In some configurations, it’s also possible to obtain internal values that weaken middleware/proxy authorization.

Applications that use Server Actions are affected when the incoming host header is not fixed to a trusted value.

Impact

In Next.js applications using App Router, Server Actions (use server) or use cache endpoints can be disclosed bypassing any authentication on the pages where these endpoints are usually used.

Server Action IDs can be disclosed to unauthenticated users via publicly served client artifacts (for example, static chunks containing action references).

Affected users are applications using App Router + Server Actions.

Impact

Requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive memory consumption if that Server Actions uses the Edge runtime

Workarounds

If you cannot upgrade, ensure your hosting provider limits the request’s body size. 5 MiB should be allowed at max by your hosting provider.

Impact

When self-hosting Next.js with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker could cause out-of-memory conditions by requesting large local assets from the /_next/image endpoint that match the images.localPatterns configuration (by default, all patterns are allowed).

• If you are using images.localPatterns, only the patterns in that array are impacted.

Impact

App Router applications that rely on middleware or proxy-based checks for authorization can allow unauthorized access through transport-specific route variants used for segment prefetching. In affected configurations, specially crafted .rsc and segment-prefetch URLs can resolve to the same page without being matched by the intended middleware rule, which can allow protected content to be reached without the expected authorization check.

Impact

It was found that the fix addressing CVE-2026-44575 did not apply to middleware.ts with Turbopack. Refer to CVE-2026-44575 for further details.

References

• CVE CVE-2026-44575

Impact

Applications using the Pages Router with i18n configured and middleware/proxy-based authorization can allow unauthorized access to protected page data through locale-less /_next/data/<buildId>/<page>.json requests. In affected configurations, middleware does not run for the unprefixed data route, allowing an attacker to retrieve SSR JSON for protected pages without passing the intended authorization checks.

Impact

Applications that use beforeInteractive scripts together with untrusted content can be vulnerable to cross-site scripting. In affected versions, serialized script content was not escaped safely before being embedded into the document, which could allow attacker-controlled input to break out of the intended script context and execute arbitrary JavaScript in a visitor’s browser.

Impact

Applications using React Server Components can be vulnerable to cache poisoning when shared caches do not correctly partition response variants. Under affected conditions, an attacker can cause an RSC response to be served from the original URL and poison shared cache entries so later visitors receive component payloads instead of the expected HTML.

Impact

React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the _rsc cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL.

Impact

Applications using Partial Prerendering through the Cache Components feature can be vulnerable to connection exhaustion through crafted POST requests to a server action. In affected configurations, a malicious request can trigger a request-body handling deadlock that leaves connections open for an extended period, consuming file descriptors and server capacity until legitimate users are denied service.

A vulnerability affects certain React Server Components packages for versions 19.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23870.

A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage.

Impact

Next.js uses the x-nextjs-data request header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.

When that happened, the middleware/proxy could treat the request as a data request and replace the standard Location redirect header with the internal x-nextjs-redirect header.

A vulnerability affects certain React Server Components packages for versions 19.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23869. You can read more about this advisory our this changelog.

Summary

When Next.js rewrites proxy traffic to an external backend, a crafted DELETE/OPTIONS request using Transfer-Encoding: chunked could trigger request boundary disagreement between the proxy and backend. This could allow request smuggling through rewritten routes.

Impact

An attacker could smuggle a second request to unintended backend routes (for example, internal/admin endpoints), bypassing assumptions that only the configured rewrite destination/path is reachable.

Summary

In next dev, cross-site protections for internal development endpoints could treat Origin: null as a bypass case even when allowedDevOrigins is configured. This could allow privacy-sensitive or opaque browser contexts, such as sandboxed documents, to access privileged internal dev-server functionality unexpectedly.

Summary

origin: null was treated as a “missing” origin during Server Action CSRF validation. As a result, requests from opaque contexts (such as sandboxed iframes) could bypass origin verification instead of being validated as cross-origin requests.

Impact

An attacker could induce a victim browser to submit Server Actions from a sandboxed context, potentially executing state-changing actions with victim credentials (CSRF).

Summary

The default Next.js image optimization disk cache (/_next/image) did not have a configurable upper bound, allowing unbounded cache growth.

Impact

An attacker could generate many unique image-optimization variants and exhaust disk space, causing denial of service. Note that this does not impact platforms that have their own image optimization capabilities, such as Vercel.

Summary

A request containing the next-resume: 1 header (corresponding with a PPR resume request) would buffer request bodies without consistently enforcing maxPostponedStateSize in certain setups. The previous mitigation protected minimal-mode deployments, but equivalent non-minimal deployments remained vulnerable to the same unbounded postponed resume-body buffering behavior.

A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the Next-Resume: 1 header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:

A vulnerability affects certain React Server Components packages for versions 19.0.x, 19.1.x, and 19.2.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23864.

A DoS vulnerability exists in self-hosted Next.js applications that have remotePatterns configured for the Image Optimizer. The image optimization endpoint (/_next/image) loads external images entirely into memory without enforcing a maximum size limit, allowing an attacker to cause out-of-memory conditions by requesting optimization of arbitrarily large images.

It was discovered that the fix for CVE-2025-55184 in React Server Components was incomplete and did not fully mitigate denial-of-service conditions across all payload types. As a result, certain crafted inputs could still trigger excessive resource consumption.

A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55183.

A malicious HTTP request can be crafted and sent to any App Router endpoint that can return the compiled source code of Server Functions.

A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55184.

A malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU.

A vulnerability affects certain React packages¹ for versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55182.

Fixed in: React: 19.0.1, 19.1.2, 19.2.1 Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7, 15.6.0-canary.58, 16.1.0-canary.12+

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as Cookie or Authorization), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.

All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. The issue allowed attacker-controlled external image sources to trigger file downloads with arbitrary content and filenames under specific configurations. This behavior could be abused for phishing or malicious file delivery.

All users relying on images.domains or images.remotePatterns are encouraged to upgrade and verify that external image sources are strictly validated.

A vulnerability in Next.js Middleware has been fixed in v14.2.32 and v15.4.7. The issue occurred when request headers were directly passed into NextResponse.next(). In self-hosted applications, this could allow Server-Side Request Forgery (SSRF) if certain sensitive headers from the incoming request were reflected back into the response.

All users implementing custom middleware logic in self-hosted environments are strongly encouraged to upgrade and verify correct usage of the next() function.

Summary

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

Summary

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

Summary

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.

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.

Summary

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.

Impact

It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.

Patches

• For Next.js 15.x, this issue is fixed in 15.2.3
• For Next.js 14.x, this issue is fixed in 14.2.25
• For Next.js 13.x, this issue is fixed in 13.5.9
• For Next.js 12.x, this issue is fixed in 12.3.5
• For Next.js 11.x, consult the below workaround.

Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.

Impact

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.

Impact

If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.

Patches

This issue was patched in Next.js 14.2.15 and later.

If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.

Workarounds

There are no official workarounds for this vulnerability.

Impact

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.

Patches

This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.

Impact

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 all of the following must apply:

• Next.js between 13.5.1 and 14.2.9

Impact

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.

Patches

This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.

Workarounds

There are no official workarounds for this vulnerability.

Credit

• Thai Vu of flyseccorp.com

Impact

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.

Prerequisites

• Next.js (<14.1.1) is running in a self-hosted* manner.
• The Next.js application makes use of Server Actions.

Impact

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.

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. Cloudflare considers these requests cacheable assets.

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

Next.js is a React framework. Starting with version 10.0.0 and prior to version 12.1.0, 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.

Impact

Vulnerable code could allow a bad actor to trigger a denial of service attack for anyone running a Next.js app at version >= 12.0.0, and using i18n functionality.

• Affected: All of the following must be true to be affected by this CVE
  • Next.js versions above v12.0.0
  • Using next start or a custom server
  • Using the built-in i18n support
• Not affected:

Next.js is a React framework. In versions of Next.js prior to 12.0.5 or 11.1.3, invalid or malformed URLs could lead to a server crash. In order to be affected by this issue, the deployment must use Next.js versions above 11.1.0 and below 12.0.5, Node.js above 15.0.0, and next start or a custom server. Deployments on Vercel are not affected, along with similar environments where invalid requests are filtered before reaching Next.js. Versions 12.0.5 and 11.1.3 contain patches for this issue.

Impact

• Affected: All of the following must be true to be affected
  • Next.js between version 10.0.0 and 11.1.0
  • The next.config.js file has images.domains array assigned
  • The image host assigned in images.domains allows user-provided SVG

Impact

• Affected: Users of Next.js between 10.0.5 and 10.2.0

Impact

• Affected: Users of Next.js between 9.5.0 and 9.5.3
• Not affected: Deployments on Vercel (https://vercel.com) are not affected
• Not affected: Deployments using next export

We recommend everyone to upgrade regardless of whether you can reproduce the issue or not.

Patches

https://github.com/vercel/next.js/releases/tag/v9.5.4

References

https://github.com/vercel/next.js/releases/tag/v9.5.4

Recommendation

Upgrade to version 5.1.0.

Impact

• Not affected: Deployments on ZEIT Now v2 (https://zeit.co) are not affected
• Not affected: Deployments using the serverless target
• Not affected: Deployments using next export
• Affected: Users of Next.js below 9.3.2

We recommend everyone to upgrade regardless of whether you can reproduce the issue or not.

Patches

https://github.com/zeit/next.js/releases/tag/v9.3.2

References

https://github.com/zeit/next.js/releases/tag/v9.3.2

Next.js 7.0.0 and 7.0.1 has XSS via the 404 or 500 /_error page.

Next.js 4 before 4.2.3 has Directory Traversal under the /_next request namespace.

Next.js before 2.4.1 has directory traversal under the /_next and /static request namespace, allowing attackers to obtain sensitive information.