Next.js September 2026 security release: what to patch and who is exposed

Two security posts landed from the Next.js team in the last ten days. The September 22 out-of-band update fixed a critical upstream issue. Today's September 2026 security release ships the planned batch of seven fixes. The current patched versions are 16.3.8 (Active LTS) and 15.5.27 (Maintenance LTS).

bash

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

Most of these issues depend on a specific feature or hosting setup, so the useful question is which ones apply to you.

The out-of-band fix: `ImageResponse` on Node.js

On September 22 the team published releases 16.3.6 and 15.5.26. They bump upstream dependencies, including Satori, to close a critical remote code execution issue (advisory GHSA-vcvr-r3jv-pc5j).

It affects the Node.js ImageResponse implementation in next/og.
Next.js >=16.2.0 <16.3.6 is affected.
Improper escaping in SVG output generated by Satori could, under specific conditions, lead to RCE because of vulnerabilities in other upstream dependencies.
The Edge ImageResponse implementation is not affected.
15.5.26 includes related hardening, but 15.x is not affected by the RCE itself.

If you generate OG images in a Node.js route handler, this is your priority. Landing on 16.3.8 or 15.5.27 covers it, since both are later than the fixed versions.

The September batch, grouped by exposure

Per the release post, the batch is one high, five medium and one low severity issue. Grouping them by the precondition you need to have met makes triage quick.

You use `next/image` with remote images

SSRF in Image Optimization (high, CVE-2026-94483). An attacker-controlled URL that is on the allow-list can lead to server-side request forgery during image optimization, for example against private IP ranges. The post states that if images.remotePatterns is not configured, you are not affected.

// next.config.ts — this is the setting that determines exposure
const config = {
    images: {
        remotePatterns: [{ protocol: "https", hostname: "cdn.example.com" }],
    },
};
export default config;

A configured allow-list is what makes you vulnerable here, so audit it. Any entry that points at a host where users can influence content, or that resolves to something internal, deserves a second look even after patching.

You self-host the Pages Router with SSG or ISR

Two medium-severity cache poisoning issues:

CVE-2026-94543: a page's cache entry can be replaced with content from a different route, so every visitor gets the wrong content until revalidation. This applies to self-hosted Pages Router apps with SSG/ISR. The post says Vercel deployments are not affected.
CVE-2026-94484: a root-level catch-all page combined with SSG or ISR routes lets a single unauthenticated, crafted request poison the shared response cache, with cross-user content substitution and persistent denial of service as the outcomes.

The second one is about the route shape rather than the hosting: look for a root-level catch-all such as pages/[...slug].tsx next to statically generated routes.

You use Cache Components or `use cache`

Two medium-severity issues, both in the newer caching model:

Nested use cache and root params (GHSA-h694-7cp9-m8p3). With Cache Components on, a 'use cache' function that calls another 'use cache' function reading a root param can get the wrong key. The outer function's key omits the root param, so content made for one value can be served for another. The post notes the leaked values cannot be attacker controlled.
Draft Mode leak (CVE-2026-94544). Pending use cache fills are shared across requests for the same key without separating Draft Mode from regular requests. A normal request overlapping an editor's draft request can receive unpublished content with no authentication. If that request prerenders a page, the draft content can be persisted and served to 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.

The Draft Mode one is the most realistic production risk in the batch for a CMS-backed site. The trigger is a timing overlap between an editor preview and a public request, which is exactly the kind of bug that never shows up in testing.

You build with webpack and use metadata image routes

CVE-2026-94485 (medium). In App Router apps built with webpack, opengraph-image and twitter-image routes ignore the dynamicParams segment option. Someone can request metadata image URLs for dynamic segments that you deliberately left out of generateStaticParams(). Turbopack builds are not affected.

// app/posts/[slug]/page.tsx
export const dynamicParams = false; // intended to 404 unknown slugs

export function generateStaticParams() {
    return [{ slug: "public-post" }];
}
// Before the fix (webpack only), opengraph-image for an unlisted slug could still respond.

This matters when unlisted slugs are unlisted for a reason, such as unpublished posts whose titles end up in a generated OG image.

You run `next dev`

MCP endpoint information disclosure (low, CVE-2026-94486). The development server exposes a Model Context Protocol endpoint that does not check which website a request originates from. A malicious page visited by the developer could read the project's location on disk, source snippets from error reports, the route inventory and development logs. Only next dev is affected; production does not serve the endpoint.

The severity is low, but the threat model is worth noting. The attack surface is your browser, not your server. Any tab you have open while the dev server runs can probe localhost. The same reasoning applies to other dev-time tooling that exposes local endpoints, including AI-assisted development tooling.

Practical upgrade notes

Upgrade first, triage second. Both lines have fixed releases, and the post lists no breaking changes, so a patch bump is the cheap path. I did not see migration notes in either post, so check your lockfile and run your normal CI before shipping.
Clear caches after patching if you were exposed. The cache poisoning issues persist bad entries until revalidation. The advisory text says affected pages keep serving wrong content until then, so if you self-host and ran a vulnerable version, purge your ISR/data cache rather than waiting.
Check both branches. If you are on 15.x, the target is 15.5.27, not 16.x. If you are on an older 16.x, go to 16.3.8.
Do not treat "not affected" as permanent. Several items are conditional on a setting (remotePatterns, webpack vs Turbopack, Cache Components). A later config change can move you into the affected group if you are still on an old version.

Trade-offs and caveats

I am summarizing the release post, not the individual GitHub advisories, so check the linked GHSA pages for exact affected-version ranges before deciding that an older deployment is safe. The release post only gives ranges for the ImageResponse issue.
The post says a fix for one critical and one high severity issue was postponed due to upstream dependency delays. Its impact section lists one high-severity item and no critical one, so follow the team's channels for anything further.
Self-hosters carry more of the exposure here than Vercel-hosted apps, at least for the Pages Router cache poisoning issue, where the post explicitly exempts Vercel deployments.