Next.js fixes seven issues in its November 2026 security release

On November 3, 2026, Next.js published a security release that fixes seven issues. Each one has its own GitHub advisory. The blog post says updates are available in 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS).

Fixed versions and severity

Take the fixed versions from the blog post. Most of the GitHub advisory records list no patched version, and GHSA-vc7v-qv4w-wrv8 lists 16.4.2.

The blog post rates GHSA-mfr8-8qww-v76h High and the other six Medium. The GitHub advisory records rate all seven Moderate.

Only three of the seven list 15.x versions as affected: GHSA-pc58-hwjq-p385, GHSA-f3mh-rxg3-f5g2, and GHSA-7qx7-33qx-rqx2. The four issues that involve Cache Components or use cache list only 16.x versions.

Only apps using Cache Components or use cache

GHSA-mfr8-8qww-v76h (CVE-2026-119790). The blog rates it High. It needs Cache Components and a public use cache function that reads a root parameter, such as a tenant ID. The same function has to be called both directly and from inside unstable_cache. During a cold cache fill, a concurrent unstable_cache call can get another request's result. That result can be stored and served to later callers until it is revalidated or evicted. If root parameters separate tenants, it can contain another tenant's data. The advisory says the unstable_cache request has to arrive while the function's first fill after a process start is still running. Outside that window, the nesting already throws 'use cache' inside unstable_cache() is unsupported. Not nesting the function is a complete workaround. GitHub lists next 16.3.0 and later as affected.

GHSA-vc7v-qv4w-wrv8 (CVE-2026-119351). The blog rates it Medium. It involves nested public use cache functions with Cache Components. An inner cached function reads a root parameter and returns an early value along with a slower async value. The outer entry can be stored before the inner function's root parameter dependencies are recorded. Content for one root parameter value, such as a tenant, site, or locale, can then be served for another. The attacker does not choose or inject that content. The advisory calls this a variant of GHSA-h694-7cp9-m8p3 that the earlier fix does not cover. That earlier issue has its own item: a nested use cache can serve one root param's content for another. GitHub lists 16.2.0 and later as affected.

GHSA-rhh4-g77r-r9qj (CVE-2026-119349). The blog rates it Medium. Different binary arguments passed to a use cache function, such as a Uint8Array or a Blob, can produce the same cache identity. If your app uses those arguments to tell users apart, a caller can get another user's cached result, or have their own result served to another user. It does not give access to unrelated cache entries. GitHub lists 16.0.0 through 16.4.2 as affected.

Only self-hosted apps

GHSA-vvgp-ww4w-46vf (CVE-2026-119350). The blog rates it Medium. Its section there is titled "Shared shell cache poisoning in self-hosted applications" and does not show the GHSA ID. It affects apps served with next start and built with cacheComponents: true, with Partial Prefetching unset or false. One unauthenticated request with a crafted URL can poison a shared fallback shell. Other URLs can then get the wrong server-rendered content or keep returning 404. The advisory says no markup or script can be injected and no data is disclosed. Its workaround is to set partialPrefetching: true in next.config. GitHub lists 16.4.0 and later as affected.

GHSA-pc58-hwjq-p385 (CVE-2026-119348). The blog rates it Medium. It affects self-hosted apps that return an attacker-controlled fetched Response unchanged. The app can forward the decompressed body with the original compressed response's framing headers. Behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared backend connection, responses can go to the wrong clients. An attacker can inject a response for another client or receive another client's response. The blog says this needs that proxy behavior and does not apply to every reverse proxy setup. GitHub's affected ranges cover every version.

GHSA-7qx7-33qx-rqx2 (CVE-2026-119347). The blog rates it Medium. The GitHub advisory says it applies on self-hosted deployments. An attacker-controlled image from a source your app allows can be misread as AVIF. That gets it past images.dangerouslyAllowSVG: false and into an SVG parser the app meant to exclude. Your image source allowlist still applies. It needs a native image backend that can decode SVG. The blog says it increases exposure to SVG parser resource exhaustion or decoder vulnerabilities, and does not by itself show cross-site scripting or remote code execution. GitHub lists 15.0.0 through 15.5.28 and 16.0.0 through 16.4.2 as affected.

Only Edge runtime routes

GHSA-f3mh-rxg3-f5g2 (CVE-2026-119346). The blog rates it Medium. It affects App Router Edge Route Handlers and Pages Router Edge API routes that set cookies with NextResponse.cookies.set(). The cookie can show up in the internal x-middleware-set-cookie response header. JavaScript on the same origin can read that header, even for an HttpOnly cookie. Harm needs a sensitive cookie set on an affected response and attacker-controlled JavaScript on the same origin. It is not a way to run JavaScript on its own. The blog says the leak it reproduced did not affect Node.js Route Handlers or routes that set cookies through cookies().set(). GitHub lists 15.0.0 through 15.5.28 and 16.0.0 through 16.4.2 as affected.