Next.js 16.3.8 Security Update: Upgrade and Verify

Next.js 16.3.8 is the September 2026 security release for the Active LTS line. It fixes seven disclosed issues: one high-severity server-side request forgery vulnerability, five medium-severity cache or information-disclosure vulnerabilities, and one low-severity development-server disclosure.

Install the patch even if the first exposure review suggests the application does not use the affected features. The review decides incident priority and follow-up, while the version update removes vulnerable code and keeps the project on the supported line.

This guide maps each advisory to concrete Next.js features, upgrades npm, pnpm, Yarn, and monorepo projects, rebuilds deployment artifacts, handles cache invalidation, and verifies the version actually running in production.

The short answer

Applications on Next.js 16.3 should upgrade to exactly 16.3.8 or a later patched 16.x release approved by the team. Applications intentionally remaining on the supported 15.5 line should use 15.5.27 or later.

npm install next@16.3.8
npm run build
npm test

Then complete the operational work:

1. Find every deployed Next.js application and installed version.
2. Identify exposure to the seven feature-specific issues.
3. Update the direct dependency and lockfile with one package manager.
4. Build from a clean install and run security-focused regression tests.
5. Deploy a new immutable artifact.
6. Replace or invalidate potentially poisoned cache entries.
7. Confirm the production artifact contains Next.js 16.3.8.
8. Review logs and cached output when an exposed feature handled untrusted traffic.

The official September 2026 security release provides the patched commands and impact summaries. Do not wait for a public exploit or a scanner finding before updating an internet-facing application.

What the release contains

The release addresses these vulnerabilities:

Severity	Area	Exposure condition
High	Image Optimization SSRF	An attacker-controlled remote URL is allow-listed through images.remotePatterns
Medium	Self-hosted SSG/ISR cache poisoning	Pages Router SSG or ISR on self-hosted Next.js
Medium	Catch-all SSG/ISR cache poisoning	Root catch-all page combined with SSG or ISR routes
Medium	Metadata image disclosure	App Router metadata image route, dynamicParams, and webpack build
Medium	Root-param cache leak	Nested 'use cache' functions with Cache Components
Medium	Draft Mode cache leak	Cache Components or experimental use-cache behavior with draft-dependent data
Low	Development MCP disclosure	A developer runs next dev and visits a malicious website

This is a prioritization map, not a reason to remain on a vulnerable version. A repository may enable a feature indirectly, a deployment may differ from local configuration, and future changes can activate dormant code paths.

Two supported release lines received patches

Next.js 16.3.8 is the Active LTS patch. Next.js 15.5.27 is the Maintenance LTS patch. The Next.js support policy lists 16.x as Active LTS and 15.x as Maintenance LTS; 14.x and earlier are unsupported under the normal policy.

If an application is still on 14 or an older major, the security response is not to search indefinitely for a matching backport. Plan an urgent move to a supported line, using 15.5.27 when the lower-change Maintenance LTS path is appropriate or 16.3.8 when the application is ready for Active LTS.

Find every installed and deployed version

Inspect the repository and package graph

Start with the manifest and installed tree:

node -p "require('./package.json').dependencies?.next ?? require('./package.json').devDependencies?.next"
node -p "require('next/package.json').version"
npm ls next --all

For pnpm or Yarn:

pnpm why next
yarn why next

The manifest may contain ^16.3.0 while the lockfile and node_modules resolve an older patch. Conversely, a local install may be new while the committed lockfile still builds the vulnerable release in CI.

Search monorepos and deployment definitions:

rg -n '"next"\s*:' --glob 'package.json'
rg -n 'next@|next/package.json|NEXT_VERSION' \
  Dockerfile* .github infra apps packages 2>/dev/null

Record each workspace, lockfile, deployed service, hosting target, and artifact owner. Include preview environments, internal dashboards, white-label builds, and dormant applications that remain reachable.

Verify the production artifact

Source state does not prove deployment state. Use an SBOM, artifact manifest, container inspection step, or startup metadata to record the installed package version. In a container build, a verification step can fail closed:

RUN node -e "const v=require('next/package.json').version; \
  if (v !== '16.3.8') throw new Error('unexpected Next.js version: ' + v)"

If the organization permits later patched releases automatically, replace the equality check with a policy implemented by the dependency scanner. Avoid a home-grown version comparison that treats semver strings lexically.

Understand the high-severity image SSRF issue

The GitHub advisory for CVE-2026-94483 describes server-side request forgery during Image Optimization. An attacker-controlled, allow-listed remote URL can lead the optimizer to private IP ranges. The advisory gives a CVSS 4.0 score of 8.3.

The application is not affected by this specific issue when no images.remotePatterns are configured. If patterns exist, inspect them immediately:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'media.example.com',
        pathname: '/public/**',
      },
    ],
  },
}

export default nextConfig

A narrow pathname does not fix an untrusted hostname. Confirm who controls DNS, redirects, object storage, and upload behavior for every allow-listed host. Wildcards deserve extra scrutiny because one abandoned subdomain can widen the trust boundary.

Treat the image optimizer as a network client

When the server fetches a remote image, it uses the application's network position. A self-hosted container may reach metadata endpoints, internal control planes, or private services that a public browser cannot.

After upgrading, review outbound-network policy. Limit the runtime's access to internal destinations where the platform supports egress controls. Framework validation and network segmentation protect different layers; use both for high-value environments.

Inspect logs for unusual /_next/image requests, allow-listed hosts resolving unexpectedly, redirects, private-range destinations in egress telemetry, and spikes in optimizer errors. Preserve relevant logs before rotating caches if an investigation is open.

Review the two SSG and ISR cache-poisoning issues

Self-hosted Pages Router cache substitution

CVE-2026-94543 affects self-hosted applications using the Pages Router with SSG or ISR. A page's cache entry can be replaced with content from a different route, and visitors may receive the wrong content until revalidation.

The advisory explicitly says Vercel deployments are not affected by this particular issue. That hosting-specific statement does not cover the other six vulnerabilities.

Self-hosted teams should inventory:

• Pages Router files with getStaticProps;
• routes using revalidate or on-demand revalidation;
• shared filesystem, Redis, CDN, or adapter caches;
• multiple application versions writing to one cache namespace;
• custom cache handlers and reverse proxies.

Root catch-all cache poisoning

The second SSG/ISR issue, CVE-2026-94484, involves a root-level catch-all page together with statically generated or incrementally regenerated routes. A single unauthenticated crafted request can poison the shared response cache, causing cross-user content substitution or persistent denial of service.

Search for root catch-all routes in both router styles:

pages/[...slug].tsx
pages/[[...slug]].tsx
app/[...slug]/page.tsx
app/[[...slug]]/page.tsx

Confirm which routes are static, which use ISR, and which cache handler stores their output. Do not test exploit payloads against production. Build regression tests that assert one route cannot replace another route's cached body.

Replace potentially poisoned entries after patching

Installing 16.3.8 changes future behavior. It may not remove response bodies already stored by a vulnerable runtime in an external cache.

For an exposed self-hosted deployment:

1. Preserve cache metadata and request logs needed for investigation.
2. Stop vulnerable instances from writing new entries.
3. Deploy the patched immutable artifact.
4. move to a fresh cache namespace or invalidate affected SSG/ISR entries;
5. warm only trusted routes through controlled requests;
6. verify content hashes or high-value page markers;
7. restore normal traffic gradually.

The exact invalidation operation depends on the adapter and CDN. Avoid deleting an entire shared cache when unrelated applications use the same namespace.

Check metadata image routes built with webpack

CVE-2026-94485 affects App Router metadata image routes such as opengraph-image and twitter-image. In webpack builds, those routes can ignore the dynamicParams segment option and serve metadata images for dynamic segments deliberately omitted from generateStaticParams().

Turbopack builds are not affected by this specific issue, according to the release post. Still upgrade both build modes.

Search for affected conventions:

rg -n 'dynamicParams|generateStaticParams|opengraph-image|twitter-image' app

Pay attention when excluded slugs represent unpublished products, private tenants, embargoed campaigns, or deleted accounts. Test that an unknown or excluded parameter returns the intended not-found response for both the page and its metadata image URL.

Do not assume an unlinked URL is private. Authorization must live in the data access path when the content is sensitive.

Audit Cache Components and nested 'use cache'

Root parameter values can be omitted from an outer key

GHSA-h694-7cp9-m8p3 concerns a cached function that calls another cached function reading a root parameter. The outer cache key can omit that root parameter, allowing output produced for one root value to be served for another. The advisory notes that the leaked values cannot be attacker-controlled.

Search for nested cached calls and parameter-dependent data:

rg -n "['\"]use cache['\"]|cacheComponents|experimental\.useCache" .

Map root parameters such as tenant, locale, account, region, site, or catalog. Write a test that renders two distinct parameter values in alternating order and confirms their output never crosses.

A cache key is an authorization boundary when cached output differs by user or tenant. Even after applying the framework fix, make those dependencies explicit in application tests.

Draft Mode fills can escape into ordinary responses

CVE-2026-94544 affects sites using Cache Components, or the earlier experimental use-cache option, when Draft Mode previews call cached functions that return draft-dependent content.

A normal request overlapping the editor's Draft Mode request can receive unpublished content. If that request prerenders a page, the content can persist and reach later visitors until revalidation.

Inventory preview routes, CMS draft queries, cached data functions, and publishing hooks. Test concurrent draft and public requests for the same content key. After patching, invalidate cache entries for pages previewed during the vulnerable period when logs can identify them; otherwise choose a broader cache namespace rotation proportionate to the risk.

Keep draft state explicit in data access. A cached function should not discover preview authorization through ambient request state unless the framework's documented cache model accounts for it.

Patch developer machines for the MCP disclosure

The low-severity CVE-2026-94486 affects the MCP endpoint served by next dev. The endpoint did not verify the requesting website's origin, allowing a malicious site visited by the developer to read development information including the project path, source snippets from error reports, route inventory, and logs.

Production deployments do not serve this endpoint. Developer workstations, cloud development environments, shared test hosts, and training machines still need the patch.

Until every environment is updated:

• bind development servers to loopback unless remote access is required;
• avoid exposing next dev directly to a shared network;
• close unused development servers;
• review browser and endpoint isolation on shared workstations;
• do not use a production secret set in local development;
• rotate a secret if evidence shows it appeared in exposed logs or error snippets.

This is an information review, not an automatic secret-rotation event for every project. Rotate credentials based on evidence and the sensitivity of the development environment.

Upgrade with the repository's package manager

npm

npm install --save-exact next@16.3.8
npm ls next --all
npm ci
npm run build
npm test

Use --save-exact when the repository's policy pins framework patches. If the project intentionally uses a semver range, ensure the lockfile resolves 16.3.8 and is committed.

pnpm

pnpm add --save-exact next@16.3.8
pnpm why next
pnpm install --frozen-lockfile
pnpm build
pnpm test

Yarn

yarn add --exact next@16.3.8
yarn why next
yarn install --immutable
yarn build
yarn test

Do not run more than one package manager in the same repository. Review the lockfile diff for unrelated dependency churn, registry changes, and unexpected workspace resolutions.

Keep React packages compatible

Do not upgrade or downgrade React blindly in the same command. Start from the versions already supported by the application's Next.js line, then act on peer-dependency errors with the official release documentation. A focused framework security patch is easier to validate than a mixed React migration.

Test the security boundaries after the build

The production build is necessary but insufficient. Add regression checks for the features the application uses:

• remote images still load only from approved hosts and paths;
• redirects from image hosts do not cross the intended trust boundary;
• two SSG/ISR routes cannot exchange cached bodies;
• root catch-all routes preserve their own cache identities;
• excluded dynamic parameters keep metadata images unavailable;
• two tenants or locales do not share nested cached output;
• Draft Mode content never appears in an ordinary session;
• the development server is not reachable from untrusted network interfaces;
• authentication and authorization still run before protected data access.

Our earlier guide to the August 2026 Next.js critical fixes explains why framework patching also needs native dependency and image-processing awareness. Version 16.3.8 supersedes older 16.3 patches and should be the new minimum on that line.

Deploy without carrying stale build state

Use a clean dependency install from the committed lockfile. Rebuild .next, standalone output, server functions, containers, and edge bundles. Do not copy a pre-patch .next directory into the new image.

For a multi-stage container:

FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN node -e "console.log(require('next/package.json').version)"
RUN npm run build

Pin the base image according to the organization's supply-chain policy. The example focuses on the clean install and version evidence.

Create a new artifact digest, deploy it to a canary, and verify:

• framework version in the SBOM or artifact manifest;
• startup and health checks;
• route inventory and build mode;
• cache namespace and revalidation behavior;
• image optimization success and egress;
• error rate, latency, CPU, and memory;
• preview and Draft Mode workflows;
• high-value page content after cache warming.

Our Next.js hosting comparison can help identify which cache, image, and runtime responsibilities belong to the platform and which remain with the application. The advisory itself is the authority for vulnerability impact.

Decide whether incident response is required

An affected version alone requires patching. Incident response priority depends on exposure and evidence.

Open a focused investigation when one or more conditions apply:

• remotePatterns trusts a host or wildcard outside firm control;
• image egress telemetry shows private destinations or unusual redirects;
• a self-hosted Pages Router deployment uses shared SSG/ISR caches;
• users reported incorrect pages or persistent cache anomalies;
• a root catch-all serves static or revalidated content;
• metadata images exist for excluded or sensitive dynamic parameters;
• nested cached functions vary by tenant, account, locale, or region;
• Draft Mode previews ran while ordinary traffic accessed the same keys;
• a development server was reachable from untrusted origins or networks.

Preserve request logs, cache metadata, deployment IDs, artifact digests, image optimizer logs, revalidation events, preview activity, and relevant egress records. Avoid collecting full response bodies or source snippets unless the investigation needs them and access is controlled.

The goal is to answer what was reachable, what was served, and for how long. Patch deployment and evidence preservation can proceed in parallel when ownership is clear.

Keep the investigation tied to explicit trust boundaries. For image optimization, that boundary covers the browser-supplied URL, the configured remote pattern, redirects, DNS resolution, outbound network policy, and the final destination. For cached pages, it covers every value that should separate one route, tenant, locale, preview session, or user from another. Documenting those boundaries makes the review repeatable and gives test authors something concrete to assert after the upgrade. Our website security essentials guide covers the surrounding controls for access, monitoring, dependency maintenance, and incident readiness. Those controls do not replace the framework patch, but they reduce the chance that one library defect becomes an unobserved, long-lived exposure.

Roll back safely

A security patch should not roll back to a vulnerable artifact after a routine application regression. Prepare two paths:

1. Fix or disable the regressing application feature while keeping Next.js 16.3.8.
2. If an emergency framework rollback is unavoidable, isolate the service from public traffic or disable the exposed feature until the patched build returns.

For cache-related regressions, preserve the fresh cache namespace so rollback does not reconnect the patched service to suspect entries. Document which cache generation belongs to which artifact.

Security changes make “last known good” more precise: the artifact must be functionally known good and above the minimum secure framework version.

Prevent the version from returning

After rollout, add a dependency policy:

• fail CI when next resolves below 16.3.8 on the 16.3 line;
• enable automated dependency updates with security priority;
• scan container and serverless artifacts as well as manifests;
• record framework versions in the software inventory;
• subscribe to Next.js security announcements;
• schedule regular LTS reviews;
• reject unsupported major versions in new services;
• keep preview and developer environments within patch policy.

The Next.js support policy recommends production applications use the latest Active or Maintenance LTS release. Patch cadence is part of operating the framework, especially for applications that rely on server rendering, shared caches, image processing, and development tooling.

A release-day checklist

• Every repository and deployed application has an owner.
• Installed, locked, and deployed Next.js versions are recorded separately.
• Next.js 16.3 resolves to 16.3.8 or a later approved secure release.
• Next.js 15.5 resolves to 15.5.27 or a later approved secure release.
• Unsupported Next.js majors have an urgent upgrade plan.
• images.remotePatterns hosts, wildcards, redirects, and DNS control are reviewed.
• Self-hosted Pages Router SSG/ISR caches are identified.
• Root catch-all routes and cache behavior are tested.
• Metadata image routes honor excluded dynamic parameters.
• Nested cached functions keep tenant and root parameters isolated.
• Draft Mode cannot seed public cached output.
• Developer machines and shared dev environments receive the patch.
• The lockfile diff contains no unexplained dependency churn.
• A clean install, production build, and full test suite pass.
• The deployment creates a new immutable artifact and cache generation.
• Production evidence confirms the running framework version.
• Exposed features receive a proportionate log and cache review.
• Rollback never restores public traffic to a vulnerable artifact.
• CI blocks the vulnerable version from returning.

Next.js 16.3.8 is a patch release, but its operational scope crosses image egress, route caches, metadata images, Cache Components, Draft Mode, and developer tooling. A package update closes the code defect. A complete response proves which features were exposed, replaces stale artifacts and cache entries, and confirms the patched version reached every environment.

Upgrade first, then investigate according to the feature matrix. Keep the evidence specific, avoid speculative compromise claims, and make 16.3.8 the enforced minimum for the 16.3 line.

---