Next.js 16.3.8: seven fixes and a self-hosting question

Next.js 16.3.8 and 15.5.27 landed on 30 September 2026 and close seven vulnerabilities between them: one high, five medium, one low. Two more that Vercel pre-announced a week earlier — one critical, one high — did not make the release. Upgrading this week leaves you better off than you were, and not finished.

The list is the least interesting part. Almost every issue here is scoped by something your deployment or your build already decided on your behalf: whether you configured a remote image host, whether you bundle with webpack or Turbopack, whether the response cache in front of your pages belongs to you or to your platform. None of these needs a clever attacker. They need a default.

What Next.js 16.3.8 fixes, and what it does not

The fixes ship in two lines — 16.3.8 on Active LTS and 15.5.27 on Maintenance LTS — and the September 2026 security release notes set out all seven.

Identifier	What it does	Who is affected
CVE-2026-94483 (High)	SSRF during Image Optimization via an attacker-controlled allow-listed remote URL, including to private IP ranges	Apps with images.remotePatterns configured. Not affected if none are set
CVE-2026-94543 (Medium)	A page's cache entry is replaced with content from a different route, serving wrong content to every visitor until revalidation	Self-hosted apps on the Pages Router using SSG or ISR. Vercel deployments not affected
CVE-2026-94484 (Medium)	Shared response cache poisoned by a single unauthenticated crafted request; cross-user content substitution and persistent denial of service	Apps with a root-level catch-all page alongside SSG or ISR routes
CVE-2026-94485 (Medium)	opengraph-image and twitter-image routes ignore dynamicParams, so segments excluded from generateStaticParams() can still be requested	App Router apps built with webpack. Turbopack builds not affected
GHSA-h694-7cp9-m8p3 (Medium)	A 'use cache' function calling another that reads a root param is keyed without that param, so one root param's content can be served for another	Apps with Cache Components enabled. Leaked values are not attacker-controlled
CVE-2026-94544 (Medium)	Pending 'use cache' fills do not distinguish Draft Mode from regular requests, so unpublished content can reach anonymous visitors and be persisted into a prerendered page	Apps with Cache Components or experimental.useCache that also serve Draft Mode previews
CVE-2026-94486 (Low)	The next dev Model Context Protocol endpoint does not verify request origin, exposing the project's path on disk, source snippets, route inventory and dev logs	Only processes running next dev. Production deployments do not serve the endpoint

Seven of nine: a critical fix is still outstanding

Upgrading to 16.3.8 does not close everything Vercel has disclosed. The pre-announcement published on 23 September was updated on the day of release: "This release now addresses seven vulnerabilities instead of nine. The remaining two (one critical, one high) are pending upstream coordination and will be addressed in a later Next.js release." The release notes describe the same two as postponed "due to upstream dependency delays".

So a critical issue in Next.js is known, publicly flagged and unpatched as of 30 September 2026. Patch to 16.3.8, and then keep the next release on your calendar rather than closing the ticket — this release is an instalment, not a conclusion.

16.3.7 is not a patched version

The same pre-announcement records that Next.js 16.3.7, published on 29 September 2026, contains a bug fix and none of the September security fixes, which landed in 16.3.8 the following day. "Upgrade to the latest release" was the wrong instruction that week.

Check the exact number rather than the recency. A project on 16.3.7 took the newest version available on 29 September, passes a casual glance at the dependency list, and is unpatched against all seven issues.

The hosting-model finding, and where the advisory stops short

The sentence worth reading twice appears under the first cache-poisoning entry: "Applications deployed on Vercel are not affected." It is unambiguous, and it changes what this release means depending on where your app runs. For a self-hosting team, CVE-2026-94543 is an exposure. For a Vercel-hosted team it is reading material.

Popular framing of this release goes further than the advisory does, and it is worth being precise: that exemption is stated for CVE-2026-94543 only. CVE-2026-94484, the catch-all cache poisoning, is described by configuration shape rather than by host, and the other cache issues are scoped by whether you have Cache Components or Draft Mode in play. The only other hosting statement is that production deployments do not serve the dev server's MCP endpoint, which is true everywhere.

Our reading of why the self-hosted case is named at all is architectural rather than legal. When you self-host, the response cache, its keys and its revalidation behaviour are infrastructure you assembled — a CDN, a reverse proxy, a shared disk or Redis-backed ISR cache — and a bug in how Next.js keys an entry propagates into a cache you own. A managed platform supplies that layer itself and can fix or compensate for it without your involvement. The same logic explains why cache keying for personalised pages is where so many framework-level cache bugs end up: whoever owns the key owns the blast radius.

That is a real cost of portability, and the honest counter-argument is that it is a cost worth paying. Teams self-host to control egress, residency and spend, and to avoid being told which runtime they may use. Nothing in this release argues against that. It argues for knowing which parts of your stack you are now the maintainer of — the point we made about running Next.js outside its default platform applies in reverse here. If you took the cache, you took the cache bugs.

Which configurations are already exempt

Four of the seven issues carry an explicit "not affected" condition, and checking them is faster than scheduling an upgrade window.

• No images.remotePatterns means the Image Optimization SSRF does not apply. The GitHub advisory for CVE-2026-94483, which scores it 8.3 (High), asks you to audit allow-listed remote URLs "for hosts that may not be trusted with their DNS entries" — the attack needs a host you already allow-listed to resolve somewhere you did not intend.
• Turbopack builds are not affected by CVE-2026-94485. The dynamicParams bypass in metadata image routes is specific to webpack builds, which is an unusually direct example of the bundler you picked changing your security exposure.
• No Cache Components and no experimental.useCache rules out GHSA-h694-7cp9-m8p3 and CVE-2026-94544. The Draft Mode leak needs a second condition as well: cached functions whose output depends on draft content, behind a preview route an editor actually uses.
• App Router without Pages Router SSG or ISR rules out CVE-2026-94543, and a project with no root-level catch-all route rules out CVE-2026-94484.

Read the other way, the configuration most exposed by this release is an unremarkable one: a self-hosted marketing or catalogue site with statically generated pages, a catch-all route for slugs from a CMS, remote images from an asset host, and a webpack build inherited from a project started before Turbopack was the default.

How to upgrade both LTS lines

The release notes give one command per line:

npm install next@15.5.27  # for 15.5
npm install next@16.3.8   # for 16.3

Pin the exact version rather than trusting a range. A dependency recorded as ^16.3.0 resolves to whatever your lockfile already pinned, so the only answer that counts comes from the installed tree:

npm ls next
npm why next   # when a dependency pulls in its own copy

Teams on 15.x should resist the temptation to fold this into a major upgrade. Maintenance LTS exists so that a security patch is a patch: 15.5.27 is a version bump, while 15 to 16 is a migration with its own test cycle. We run Next.js across client web work and treat the two as separate changes for exactly this reason — bundling them is how a one-hour patch becomes a sprint, and how it quietly slips.

A website you visit can read your source: CVE-2026-94486

The lowest-severity item in the release is the one most teams have never modelled. next dev exposes a Model Context Protocol endpoint — the interface coding agents use to query a running project — and before 16.3.8 it did not verify which website a request came from. A malicious page you open in the same browser can read the project's location on disk, source code snippets from error reports, the route inventory and development logs. The advisory scores it 2.3 (Low) because it needs you to visit the page, and the data is development data rather than production data.

The score is defensible and the category is not well covered by anyone's threat model. A dev server is a long-running HTTP service, bound on your machine, with no authentication and — in this case — no origin check, and the browser that your localhost tooling trusts is the same browser you use to read a Stack Overflow answer. Local tooling has been picking up agent endpoints quickly over the past year, and each one is a new unauthenticated listener on a developer laptop that holds source, credentials in .env.local and access to internal hosts.

Patching fixes this instance. The habit worth forming is to treat every port your tooling opens as a service that needs an origin or auth model, and to notice when a convenience feature turns your laptop into a server. That reasoning is the same one behind prioritising vulnerabilities by exposure rather than by score: a 2.3 on a machine with repository access can matter more than a 9.8 on a host nobody can reach.

How to work out your own exposure

This is a config inventory, not an audit, and it takes about ten minutes for one application.

1. Get the version you actually run. npm ls next in the deployed lockfile's tree, not the version in package.json. Anything on 16.3.7 or below, or 15.5.26 or below, is unpatched.
2. Grep the config. images.remotePatterns present in next.config puts CVE-2026-94483 in scope; list every allow-listed host and ask who controls its DNS.
3. Name your bundler. A webpack build puts CVE-2026-94485 in scope. Check your build script rather than assuming the framework default for your version.
4. Find your static pages. A pages/ directory with getStaticProps, or any revalidate, means SSG or ISR is in play. Add a root-level catch-all route and CVE-2026-94484 applies too.
5. Check for Cache Components and Draft Mode. cacheComponents or experimental.useCache plus draftMode() behind a CMS preview is the combination CVE-2026-94544 needs.
6. Write down who owns the cache. If the answer is a proxy, a CDN config or a Redis instance in your account, you are the maintainer of the layer the two cache-poisoning CVEs act on.

Keep that answer in the repository next to the deployment notes. The reason this release is a larger event for self-hosted teams than the changelog suggests is not that the bugs are worse; it is that the exemptions are properties of configuration, and most teams cannot state their own configuration without going to look. Next time an advisory lands with a "not affected if" clause, the difference between a ten-minute check and a two-day scramble is whether that file exists — which is the sort of thing we set up alongside the web applications we build and maintain. The two postponed fixes mean the next advisory is already scheduled, even if its date is not.