Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
75 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 16.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. The enclosing entry is written once and reused for all root param values, so a response for one root param value can serve content produced for a different value — whether the page is prerendered at build time or at runtime, or rendered dynamically. Shared cache headers let downstream caches redistribute the content further. What values are leaked cannot be attacker controlled. Which value's content is served depends only on which invocation wrote the entry first. Workarounds There are no known workarounds. Apps should upgrade to the patched version as soon as possible.
Recommended action: Upgrade to 16.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 10.0.0, <= 15.5.27; >= 16.0.0, <= 16.4.0
Fixed in
16.4.115.5.28· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.4.1 or 15.5.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, <= 15.5.27; >= 16.0.0, <= 16.4.0
Fixed in
16.4.115.5.28· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.4.1 or 15.5.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. If the overlapping regular request prerenders a page — for example an on-demand prerender of a route that was not prerendered at build time — the unpublished content can be persisted into the generated page and served to all later visitors of that route until the page is revalidated. Since cached functions can be shared across routes, the poisoned page does not need to be the page the editor is previewing. Sites are affected if they enable Cache Components (or experimental.useCache) and serve Draft Mode previews whose cached functions return…
Recommended action: Upgrade to 16.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 15.0.0, < 15.5.27; >= 16.0.0, < 16.3.8
Fixed in
15.5.2716.3.8· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.3.8 or 15.5.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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().
Recommended action: Upgrade to 16.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 16.0.0, < 16.3.8; >= 15.0.0, < 15.5.27
Fixed in
15.5.2716.3.8· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.3.8 or 15.5.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Node.js ImageResponse implementation from next/og is affected by an upstream vulnerability. This can lead to remote code execution. Affected applications pass attacker-controlled values into SVG content, attributes, or styles during image generation: Applications using the Edge ImageResponse implementation, or applications that do not pass attacker-controlled values into SVG content, attributes, or styles, are not affected. Workaround If upgrading is not immediately possible, do not pass attacker-controlled values into SVG content, attributes, or styles rendered by the Node.js ImageResponse implementation from next/og.
Recommended action: Upgrade to 16.3.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 10.0.0, < 15.5.24; >= 16.0.0, < 16.3.3
Fixed in
16.3.315.5.24· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.3.3 or 15.5.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.4.0, < 15.5.24; >= 16.0.0, < 16.3.3
Fixed in
16.3.315.5.24· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.3.3 or 15.5.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 14.1.1, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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. This typically occurs on custom servers, or on deployments not behind a proxy that pins the host. Managed hosting pins the host upstream and is not affected; next start and standalone output do the same from version 14.2 onward. Workarounds If you cannot upgrade, ensure clients do not control the host header your application receives. Pin or validate Host and X-Forwarded-Host at your edge or proxy. On version 14.2.0 and later, you can additionally set the NEXTPRIVATEORIGIN environment variable to your deployment's real…
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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) Workarounds No workaround exists besides upgrading. Applications using Pages Router are not vulnerable.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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. Workarounds If you cannot upgrade, consider only making fetch requests with UTF-8 bodies (default in Next.js). Applications using Pages Router are not vulnerable.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 12.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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. This affects any destination that puts a dynamic segment in the hostname, whether from the path: or from a has capture: Workarounds If you cannot upgrade immediately, do not build the hostname of an external rewrites() or redirects() destination from user-controlled input. If a dynamic subdomain is required, constrain the value to hostname-safe characters: value: '(?<region[a-z0-9-]+)'.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 15.5.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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. - If you are using config.images.loader: 'custom', you are NOT impacted. - If you are using Vercel, you are NOT impacted. Workarounds If you cannot upgrade immediately, you can avoid the expensive work by setting config.experimental.imgOptSkipMetadata : true.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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. By itself, this disclosure is typically a recon/enumeration primitive; however, it can increase risk when combined with other weaknesses. Workarounds Never assume any authentication claims at the use cache or use server boundary. Always authenticate within the boundary.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.0.0, < 15.5.21; >= 16.0.0, < 16.2.11
Fixed in
15.5.2116.2.11· Vendor fix available
Issue
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.
Recommended action: Upgrade to 16.2.11 or 15.5.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 15.2.0, < 15.5.18; >= 16.0.0, < 16.2.6
Fixed in
15.5.1816.2.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 16.2.6 or 15.5.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 12.2.0, < 15.5.16; >= 16.0.0, < 16.2.5
Fixed in
16.2.515.5.16· Vendor fix available
Issue
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. Browsers do not follow x-nextjs-redirect, so the response became an unusable redirect for normal clients. If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a Location header, causing a denial of service for that redirect path until the cache entry expired or was purged. Affected scenarios This affects applications that: - use middleware or proxy redirects - are…
Recommended action: Upgrade to 16.2.5 or 15.5.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
npm next >= 13.4.0, < 15.5.16; >= 16.0.0, < 16.2.5
Fixed in
16.2.515.5.16· Vendor fix available
Issue
Impact App Router applications that rely on CSP nonces can be vulnerable to stored cross-site scripting when deployed behind shared caches. In affected versions, malformed nonce values derived from request headers could be reflected into rendered HTML in an unsafe way, allowing an attacker to poison cached responses and cause script execution for later visitors. Fix We now reject or ignore malformed nonce values before they are embedded into HTML and apply stricter nonce sanitization so request-derived nonce data cannot break out of the intended attribute context. Workarounds If you cannot upgrade immediately, strip inbound Content-Security-Policy request headers from untrusted traffic.
Recommended action: Upgrade to 16.2.5 or 15.5.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.