Nine Next.js vulnerabilities in October: when self-hosted sites are affected and which version to upgrade to

Since October 7, npm audit has been reporting "high" for next. Your site loads images from an external CMS, serves article pages with Pages Router ISR, and editors preview drafts with Draft Mode. If you run a Next.js site like that on your own servers or containers, several of the advisories published in October may apply.

October's advisories came out in two rounds. The six registered in the GitHub Advisory Database on October 7 (UTC) are fixed in 16.3.8 and 15.5.27, which were published to npm on September 30. But on October 14, vercel/next.js published three more: two CRITICAL remote code execution (RCE) issues and one HIGH denial of service (DoS) issue, and 16.3.8, 16.4.0 and 15.5.27 are also affected by these three. The fixed versions are 16.4.1 and 15.5.28, and the 16.3 line has no fixed release.

Our article on the September Next.js vulnerabilities, which had recommended upgrading to 16.3.8, was also corrected on October 16 with a new upgrade target. This article helps you decide, condition by condition, whether the nine advisories affect your site, which version to upgrade to, and what to check after upgrading.

Upgrade to 16.4.1 or later, or 15.5.28 on the 15 line

On the 16.x line, the three October 14 advisories cover every version up to 16.4.0. There is no 16.3.9 on npm, so there is no way to fix this while staying on the 16.3 line. Sites on 16.x should move to 16.4.1 or later (as of October 16, npm's latest is 16.4.2), and sites on 15.x should move to 15.5.28, which carries the backport tag. According to the release notes, 16.4.1 fixes these three, and 15.5.28 fixes two of them, excluding the one that affects only the 16 line.

The fixes for the six October 7 advisories are also in 16.4.0. Those six cover versions "below 16.3.8," and in the repository history, commits with the same titles as the fixes in 16.3.8 (#99477, #99478, #99479, #99480 and #99482) were included in the 16.4.0 tag. Upgrading to 16.4.1 or later gives you the fixes for all nine.

14.x and earlier are not off the hook either. The six October 7 advisories all start at 15.0.0, but among the October 14 advisories, the image optimization one covers 10.0.0 and later and the Server Actions one covers 13.0.0 and later. No new fixed releases have shipped for 13.x or 14.x (npm's next-14 tag still points to 14.2.35, published in December 2025), so fixing them requires a major upgrade to 15.5.28 or the 16.4 line.

Conditions for the nine advisories

These are the conditions and affected ranges stated in the advisories. First, the three from October 14.

Next, the six from October 7.

The "affected versions" in the tables and diagram express each advisory's range (for example, below 16.3.8) using the last published version. For the image optimization advisory, the range for the 16 line is written as "later than 16.0.0, up to and including 16.4.0."

Checking your site condition by condition

From here on, this is our editorial team's guide to where in your repository to check each advisory's conditions. For the two Critical advisories from October 14, however, proceed with the upgrade without waiting for these checks to finish.

use cache: are you using Cache Components?

GHSA-673q states that in an App Router app with Cache Components enabled, a 'use cache' function that returns multiple typed arrays (such as Uint8Array) can lead to unauthenticated RCE. What to check is cacheComponents: true in next.config and the return values of functions marked with 'use cache'. However, the advisory says there is no workaround and asks you to upgrade immediately even if you have no similar function. If you use Cache Components, upgrade before checking.

Image optimization: do you run on glibc Linux, and which sharp version?

GHSA-2464 states that a memory issue in an upstream library used by image optimization can lead to RCE when Next.js runs on glibc-based Linux. Its title refers to cases where SVG files are used. The same CVE (CVE-2026-96889) was also published on the sharp side on September 30 as a "librsvg vulnerability," fixed in sharp 0.35.5. The advisory says nothing about musl-based environments (such as Alpine), so this article makes no judgment about them.

According to the Next.js documentation, SVG is not optimized by default and is allowed with images.dangerouslyAllowSVG. However, the advisory does not exclude anything based on this setting, so our editorial team recommends upgrading regardless of the setting.

The workaround is to make sure the sharp used by Next.js is 0.35.5 or later. 16.4.1 raises its sharp range to ^0.35.5. The range in 15.5.28 is ^0.34.3 || ^0.35.5, which still accepts the 0.34 line. As a result, on 15.x the sharp from an old lockfile may remain (see the test below). If your own code uses sharp directly, bring it to 0.35.5 or later as well.

If you cannot upgrade right away, the sharp advisory lists a workaround of stopping SVG loading with sharp.block({ operation: ["VipsForeignLoadSvg"] }). It also notes that avoiding RCE requires a node built as a PIE (position-independent executable), and that the official Node.js binaries are not built that way.

Are you using Server Actions?

GHSA-p3m5 is an issue where sending crafted requests to an App Router app with at least one Server Action exhausts the CPU and stalls subsequent processing in the same process. The only remedy is to upgrade; apps that use only the Pages Router and apps that do not use Server Actions are not affected. Searching for 'use server' tells you whether you have Server Actions.

Image optimization: what do you allow in remotePatterns?

The High-severity GHSA-cjq9 is an issue in which next/image optimization can be made to send requests from an allow-listed remote URL to an internal network (such as private IPs). As a workaround, it asks you to review the hosts allowed in images.remotePatterns for any whose DNS records cannot be trusted. It also states clearly that "if no remotePatterns are configured, your app is not affected."

What to check is the images setting in next.config.js (or .mjs / .ts). If you allow your CMS's image delivery domain or a storage bucket, you are affected. If you use only the deprecated images.domains, the advisory does not mention it and our editorial team cannot judge; prioritize upgrading.

Do you self-host Pages Router SSG or ISR?

GHSA-4jqv affects sites that have Pages Router pages using getStaticProps (SSG) or returning revalidate (ISR) and run outside Vercel. According to the advisory, one page's cache can be replaced with another route's content, and every visitor sees the wrong content until it is regenerated. Searching for getStaticProps in pages/ lists the affected pages. Setups that run next start or standalone output on your own servers or containers are affected.

Do you have a catch-all page at the root?

GHSA-mcj8 affects sites that place a catch-all page at the root, such as pages/[...slug].js, and also have SSG or ISR routes. This advisory does not limit itself to the Pages Router or App Router, or to self-hosting, so check directly under both pages/ and app/. It does not say whether the optional [[...slug]] falls under this condition, but our editorial team recommends including it in your checks.

Do you use Draft Mode together with Cache Components?

GHSA-3w37 affects 16.3.0 and later. It states that on sites that enable cacheComponents: true (or experimental.useCache) in next.config and whose 'use cache' functions return content that changes with drafts, the following can happen when an editor's preview overlaps with regular browsing:

• Regular visitors receive unpublished content without any authentication
• If that request generates a page, the unpublished content is saved and served to everyone until regeneration
• Because cached functions are shared across routes, the poisoned page is not necessarily the one being previewed

On sites that use CMS previews, check this early, as it can leak information before publication.

OG image routes built with webpack, and development machines

GHSA-f87g affects App Router apps built with next build --webpack. According to the documentation, Turbopack is the default in Next.js 16, and webpack is used when you add --webpack. If your build script includes --webpack, and a route that narrows the generated pages with generateStaticParams and sets dynamicParams = false has opengraph-image or twitter-image, images can be requested for URLs that should have been excluded.

GHSA-39w2 has nothing to do with production and affects developers' PCs running next dev. If a developer opens a malicious site during development, the project's location, source snippets included in errors, the list of routes and development logs may be read. Ask contractors to update their development environments as well.

Which version to upgrade to

On 16.x, use 16.4.1 or later. There is no patch release in the 16.3 line, so even sites on 16.3.8 move up a minor version to the 16.4 line. As of October 16, latest is 16.4.2, and according to the release notes the changes since 16.4.1 are Turbopack fixes and documentation updates. Our editorial team suggests upgrading to 16.4.2 and checking behavior in staging before releasing to production.

On 15.x, use 15.5.28, which carries the backport tag. Lines older than 15.5, such as 15.3, are also within the affected range, so upgrade them to 15.5.28. As noted above, 13.x and 14.x have no fixed release, so plan a major upgrade to 15.5.28 or the 16.4 line.

If you self-host and use a custom cache handler (cacheHandler) that stores the ISR cache in Redis or similar, check it before upgrading. The fix commit for GHSA-4jqv and mcj8 included from 16.3.8 and 15.5.27, "Scope response cache keys to their source route," adds a SHA-256 hash of the source route to cache keys, and the documentation was updated to say that "a key is not a request pathname" and that "handlers that previously interpreted keys as pathnames must account for this namespace." Upgrading from 16.3.7 or earlier to the 16.4 line also crosses this change. If you have custom logic that extracts URLs from keys to delete or revalidate entries, verify that it works before releasing to production.

What to check after upgrading

Do not rely on npm audit showing zero

In our test environment, we created a setup for each version whose only dependencies were next and react / react-dom (19.2.0), and ran npm audit --json. The results on October 10 (Linux, Node.js v22.22.0, npm 10.9.4) and October 16 (macOS, Node.js v22.19.0, npm 10.9.3) are below; for versions run on both days, the results were the same.

next 16.3.7  : high 1件。next の項目に6件（GHSA-cjq9 / 4jqv / mcj8 / 3w37 / f87g / 39w2）
next 16.3.8  : 0件
next 16.4.0  : 0件
next 16.4.1  : 0件（10月16日のみ）
next 16.4.2  : 0件（10月16日のみ）
next 15.5.26 : GHSA-4jqv / mcj8 の2件（ほかに同梱の postcss の指摘）
next 15.5.27 : Next.js 本体の指摘なし（同梱の postcss の指摘は残る）
next 15.5.28 : Next.js 本体の指摘なし（同上、10月16日のみ）

As of October 16, the three October 14 advisories are not included in the GitHub Advisory Database and do not appear in npm audit. Zero findings on 16.3.8, 16.4.0 or 15.5.27 does not mean you are outside the scope of those three. The postcss findings that remain on 15.5.27 and 15.5.28 are the same ones we confirmed in our September Next.js article, and npm audit points to the major update 16.4.2.

What to check is the version actually running. Run npm ls next sharp inside the deployed artifact and confirm that next is 16.4.1 or later (15.5.28 or later on 15.x) and sharp is 0.35.5 or later.

Did sharp move up to 0.35.5?

To reproduce an old lockfile, we pinned the sharp version, then removed the pin and upgraded only next (October 16, npm install --package-lock-only).

Because 15.5.28 accepts the sharp 0.34 line, sharp does not move up if 0.34 remains in your lockfile. On 15.x sites, check the version with npm ls sharp after upgrading, and if it is below 0.35.5, upgrade it with something like npm install sharp@^0.35.5. Also check that moving to the sharp 0.35 line does not change image processing in your own code.

Did the ISR cache location change?

We built a minimal app with only Pages Router ISR pages (/ and /posts/[slug]) on 16.3.7 and 16.3.8 and opened it with next start (October 10, Linux). On 16.3.7 the cache was written to .next/server/pages/ as before, while on 16.3.8 it was written to a per-route location such as .next/server/route-cache/PAGES/<ハッシュ>/$/posts/hello.html. The hashes for /posts/hello and /posts/world both matched the SHA-256 of the string /posts/[slug]. When we tried the same app on 16.4.1 on October 16 (macOS), the cache was written to the same location with the same hash as on 16.3.8.

If you self-host, the presence of the route-cache directory on the upgraded server is one sign that the fix is working. If you use a custom cache handler, check whether the keys written to Redis or similar contain the same kind of namespace.

Draft Mode previews

On sites using Cache Components, after upgrading, keep a preview open in an editor's browser, open the same page from a different browser, and confirm that the draft content does not appear. This is our editorial team's suggestion and was not tried in our test environment. We covered how to decide who updates the site and when in Abandoned React2Shell sites and reviewing maintenance contracts.

Scope of verification

On October 10, 2026, we directly retrieved and checked the JSON for the six advisories in github/advisory-database (commit 4f4dc0a), the vercel/next.js tags v16.3.7, v16.3.8, v16.4.0, v15.5.26 and v15.5.27 and the fix commits, the source of the 16.3.8 documentation, and npm registry publication dates. On October 16, we read the three vercel/next.js advisories, the release notes for v16.4.1, v15.5.28 and v16.4.2, the sharp advisory GHSA-wq5f-xc86-pv6w, and the source of the v16.4.1 image documentation through the GitHub API, and checked npm publication dates and sharp's dependency ranges with npm view (desk research). We also ran npm audit on minimal setups (October 10 and 16), compared the cache location of a minimal Pages Router ISR app built and started on 16.3.7 and 16.3.8 (Linux) and on 16.4.1 (macOS), and checked sharp's version when upgrading next from an old lockfile (hands-on testing). We did not reproduce the vulnerabilities, and did not check behavior with use cache, Server Actions, SVG image optimization, Draft Mode, remotePatterns, catch-all routes or webpack builds, custom cache handlers, builds on 15.5.28, compatibility when moving from the 16.3 line to the 16.4 line, or app behavior on 14.x and earlier. We could not open nextjs.org or NVD, so they remain unchecked.

For update plans for sites built with Next.js, or for reviewing caching in self-hosted environments, please contact us through consultation on development, AI, and automation.

References

• GHSA-673q-mjm6-r5xr: Unauthenticated Remote Code Execution in use cache functions returning typed arrays（vercel/next.js）
• GHSA-2464-fhr4-w9xw: Unauthenticated Remote Code Execution in Image Optimization API when SVG files are used（vercel/next.js）
• GHSA-p3m5-59mp-jv5r: Denial of Service in App Router using Server Actions（vercel/next.js）
• GHSA-wq5f-xc86-pv6w: Vulnerability in librsvg dependency CVE-2026-96889（lovell/sharp）
• Next.js v16.4.1 release notes (vercel/next.js)
• Next.js v15.5.28 release notes (vercel/next.js)
• GHSA-cjq9-62q9-8jv4: Next.js has Server-Side Request Forgery in Image Optimization（github/advisory-database）
• GHSA-4jqv-mc3x-m676: cache poisoning of SSG and ISR pages in self-hosted applications（github/advisory-database）
• GHSA-mcj8-r9mp-w47p: cache poisoning in SSG/ISR rendering（github/advisory-database）
• GHSA-3w37-wq28-93x7: Pending use cache fill can leak Draft Mode content（github/advisory-database）
• GHSA-f87g-xv8r-7p7x: metadata image routes via dynamicParams bypass（github/advisory-database）
• GHSA-39w2-rjm5-chcv: development server’s Model Context Protocol endpoint（github/advisory-database）
• vercel/next.js — commit 719e4c6（Scope response cache keys to their source route、16.3.x）
• vercel/next.js — commit e002ad6（Pin DNS resolution when fetching external images）
• vercel/next.js — commit bd9214f（Fix draft mode leaks through cross-request ‘use cache’ deduplication）
• vercel/next.js — incrementalCacheHandlerPath.mdx（v16.3.8）
• vercel/next.js — image.mdx（v16.4.1、dangerouslyAllowSVG）
• next — npm registry