Next.js September 2026 security release: Key updates_

The Next.js September 2026 security release is out, and it is not a release you can skip. It patches seven vulnerabilities across Image Optimization, the SSG and ISR response cache, 'use cache', App Router metadata routes, and the next dev server.

The Next.js team pre-announced the security release a week earlier. Two additional fixes, for one critical and one high-severity vulnerability, were postponed because of upstream dependency delays. The seven fixes covered here are available in v16.3.8 (Active LTS) and v15.5.27 (Maintenance LTS).

Most of these issues affect commonly used Next.js features, including remote images, statically generated pages, Draft Mode previews, and Cache Components. One of the vulnerabilities specifically affects self-hosted Next.js applications, while others depend on features such as SSG, ISR, Cache Components, Draft Mode, or Image Optimization.

Here is what each vulnerability does, how to tell if your app is affected, and how to patch it.

Next.js September 2026 security release at a glance

Upgrade to next@16.3.8 if you are on the 16.3 line, or next@15.5.27 if you are on 15.5. The release fixes one high severity Server-Side Request Forgery (SSRF), five medium severity cache poisoning and information disclosure bugs, and one low severity dev server issue.

Which Next.js versions are patched

The fixes ship on the two supported LTS lines. If you are on an older major or minor, the safe path is to move onto one of these.

To patch, install the version for your release line:

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

If you use pnpm, Yarn, or Bun, run the equivalent command and commit the updated lockfile. A dependency bump that never reaches your lockfile never reaches production.

High severity: SSRF in Next.js Image Optimization

CVE-2026-94483 / GHSA-cjq9-62q9-8jv4

This is the most serious issue in the release. During Image Optimization, an attacker-controlled remote URL that matches your allow-list can trigger Server-Side Request Forgery, including requests to private IP ranges.

SSRF matters because the request comes from your server, not the attacker's browser. That means it can reach internal services, metadata endpoints, and admin interfaces that are never exposed to the public internet. The OWASP SSRF reference covers why this class of bug is so often used as a pivot into internal networks.

Are you affected?

• Yes, if your next.config sets images.remotePatterns.
• No, if you do not configure images.remotePatterns.

While you patch, tighten your patterns. Wildcard hostnames and broad path globs widen the set of URLs an attacker can route through your optimizer. Allow only the exact hosts and paths you actually serve images from.

Medium severity: Next.js cache poisoning in SSG and ISR

Two of the medium severity issues target the response cache that powers statically generated (SSG) and Incremental Static Regeneration (ISR) pages. Cache poisoning is worse than a one-off bad response because a single request can change what every later visitor sees.

Cache poisoning of SSG and ISR pages in self-hosted apps

CVE-2026-94543 / GHSA-4jqv-mc3x-m676

Self-hosted Next.js apps using the Pages Router with SSG or ISR pages can have a page's cache entry replaced with content from a different route. The affected page then serves the wrong content to every visitor until the entry is revalidated.

Self-hosted Next.js applications using the Pages Router with SSG or ISR are affected by CVE-2026-94543. The Next.js advisory specifically states that applications deployed on Vercel are not affected by this vulnerability.

Cache poisoning through a root-level catch-all page

CVE-2026-94484 / GHSA-mcj8-r9mp-w47p

Apps that combine a root-level catch-all page with SSG or ISR routes can have their shared response cache poisoned by a single unauthenticated, crafted request. The result is cross-user content substitution and a persistent denial of service until the cache is cleared or revalidated.

Root catch-alls are common in CMS-driven sites, where one [...slug] route renders every marketing page. If that describes your app, prioritize this patch.

Medium severity: Next.js information disclosure and cache leaks

The remaining medium severity bugs are about content reaching people who should not see it.

Metadata image routes ignore dynamicParams

CVE-2026-94485 / GHSA-f87g-xv8r-7p7x

In App Router apps built with webpack, metadata image routes such as opengraph-image and twitter-image ignore the dynamicParams route segment option. An attacker can request metadata images for dynamic segments you deliberately left out of generateStaticParams().

If you use dynamicParams = false to prevent dynamic segments outside generateStaticParams() from being generated, affected metadata image routes could still be requested for those excluded segments.

Cache leak across root param values in nested use cache

GHSA-h694-7cp9-m8p3

With Cache Components enabled, a 'use cache' function that calls another 'use cache' function which reads a root param can be keyed incorrectly. The outer function's cache key omits that root param, so content generated for one value can be served for another, whether the page is prerendered or dynamic.

The Next.js team notes that the leaked values cannot be attacker controlled. It still matters for apps that use root params for locale or tenant routing, which became easier with the Root Params API in Next.js 16.3.

Draft Mode content leaks through pending use cache fills

CVE-2026-94544 / GHSA-3w37-wq28-93x7

Pending use cache fills are shared across requests for the same key, without separating Draft Mode requests from regular ones. A regular visitor whose request overlaps with an editor's preview can receive unpublished content without authentication.

If that overlapping request prerenders a page, the draft content can be persisted into the generated page and served to all later visitors until revalidation. You are affected if you enable Cache Components (or experimental.useCache) and serve Draft Mode previews whose cached functions return draft-dependent content. For a CMS-backed site, this could potentially expose unpublished or embargoed content before its intended publication.

Low severity: Next.js dev server MCP endpoint

CVE-2026-94486 / GHSA-39w2-rjm5-chcv

next dev exposes a Model Context Protocol (MCP) endpoint for AI coding agents. It does not verify which website a request comes from, so a malicious site the developer visits can read development data, including:

• The project's location on disk
• Source code snippets from error reports
• The route inventory
• Development logs

Production deployments do not serve this endpoint. The risk is to developer machines, so update local environments too, not just your deployed apps.

Patching Next.js apps on Appwrite Sites

Appwrite Sites runs Next.js in a container-based Node.js runtime with full SSR support, rather than translating it into serverless functions. That gives you full Next.js server behavior, including ISR and Image Optimization, without adapters.

To patch a Next.js app on Appwrite Sites:

1. Run npm ls next to confirm which version is installed.
2. Update next to 16.3.8 or 15.5.27 and commit the lockfile.
3. Run your test suite, focusing on ISR, Draft Mode, and remote images.
4. Push to your connected branch. Git deployments build and activate the new version automatically.
5. Use preview deployments to verify ISR, Draft Mode, and image routes before merging.
6. After deployment, revalidate or purge cached pages so any previously poisoned entries are replaced.
7. Update local environments so next dev also picks up the MCP fix.

If anything regresses, instant rollbacks let you switch back to a previous ready deployment with zero downtime while you investigate.

Getting started with secure Next.js deployments on Appwrite

Patch first. Every app on an unpatched Next.js version should move to 16.3.8 or 15.5.27 today, with immediate priority for apps that configure images.remotePatterns or self-host ISR pages.

If you are setting up a new project or moving an existing one, the Next.js quick start for Appwrite Sites takes you from create-next-app to a live URL with Git deployments, previews, and instant rollbacks in place. That way the next security release is a commit and a push, not an incident.

Resources