Next.js November Security Release and Who Needs It

What Shipped on November 3

On November 3, 2026, the Next.js team published its scheduled November security release. Next.js 16.4.5, the Active LTS line, and 15.5.29, the Maintenance LTS line, fix seven advisories. One is rated High and six are rated Medium. None of them allows remote code execution, and the team announced the release a week in advance, so this is a routine monthly update of the kind the project has shipped since it formalised its security release programme in July.

The upgrade itself is a one-line dependency change and a redeploy. Most of the seven issues also need a specific feature or setup before they matter, and the largest group only affects applications that have turned on Cache Components. If your app has not, several of these do not apply to you, though the patch is still worth taking.

npm install next@16.4.5   # apps on 16.x
npm install next@15.5.29  # apps on 15.5

Which Versions Are Supported

Maintenance for Next.js 15 was due to end on October 21, 2026, and the Next.js team has extended security releases for it until January 31, 2027. That is a welcome three extra months, and it is also the date to plan the move to 16 around. Applications still on 14 or older get no fixes from this release or any later one.

The Four Cache Components Advisories

Cache Components is the newer caching model in Next.js, built on the use cache directive. It is opt-in through the cacheComponents setting in next.config. Four of the seven advisories live here, and all four are about cached content reaching the wrong audience.

• Cross-tenant disclosure with unstable_cache, rated High. When the same public use cache function is called both directly and from inside unstable_cache, and it reads a root parameter such as a tenant identifier, a concurrent request during a cold cache fill can receive another request's result. That result can then be stored and served to later callers. In a multi-tenant app that means one customer seeing another customer's data.
• Nested use cache functions. An inner cached function that reads a root parameter and returns an early value next to a slower one can let the outer entry be stored before its dependencies are recorded. Content generated for one tenant, site or locale can then be served for another.
• Binary arguments. Different binary arguments passed to a use cache function could produce the same cache identity. If those arguments identify users or accounts, one user can receive another's cached result, or push their own result to someone else.
• Shared shell poisoning when self-hosted. Apps running next start with Cache Components on and Partial Prefetching off can have a shared page shell poisoned by an unauthenticated request with a crafted URL. The result is wrong server-rendered content or persistent 404 responses. It needs a specific route shape with several dynamic parameters, and the Next.js team found that setups with Partial Prefetching enabled were not affected in its tests.

If your app does not enable Cache Components, none of these four applies to it.

The Other Three

• Response framing behind some reverse proxies. A self-hosted app that returns an attacker-controlled fetch response unchanged can forward the decompressed body with the original compressed response's headers. Behind an HTTP/1.1 proxy that queues pipelined requests from different clients on one backend connection, responses can then go to the wrong client. The Next.js team stresses that it needs that specific proxy behaviour and does not apply to every reverse proxy.
• Cookies in an internal header on Edge routes. Edge Route Handlers and Pages Router Edge API routes that set cookies with NextResponse.cookies.set() could expose the cookie value in the internal x-middleware-set-cookie header, which JavaScript on the same origin can read even when the cookie is HttpOnly. It only matters if an attacker already runs script on your origin, so it turns a cross-site scripting bug into a worse one rather than creating one. Node.js route handlers and cookies().set() were not affected.
• SVG slipping past the image optimiser. An image from a source your config already allows could be misclassified as AVIF and get past dangerouslyAllowSVG: false, reaching an SVG decoder you meant to exclude. The allowlist still applies, so this only concerns apps that optimise images from remote sources and use a native image backend that can decode SVG.

How to Tell Whether Your App Is Exposed

A few searches in the repository answer most of it. Run them from the project root.

npm ls next
grep -rn "cacheComponents" next.config.*
grep -rln "use cache" app src 2>/dev/null
grep -rn "runtime = ['\"]edge['\"]" app src pages 2>/dev/null
grep -n -A6 "images" next.config.*

The first line shows the installed version, including any copy pulled in by another package. If cacheComponents is not enabled and no file uses use cache, the four cache advisories are not yours. If nothing declares the Edge runtime, the cookie header issue is not either. If images has no remotePatterns or domains, the optimiser only processes your own files and the SVG issue needs an attacker to control one of them. The response framing issue depends on your proxy, and nginx, the most common choice in front of a self-hosted Next.js app, does not pipeline requests from different clients onto one upstream connection by default.

Even when every answer is no, upgrade anyway. Monthly releases are cumulative, and staying current keeps the next critical fix a small step. Falling behind turns it into a jump across several versions with their own changes.

Upgrading Without Surprises

Within a release line these are patch releases, so the change is small. Update the dependency, commit the lockfile, and rebuild.

npm install next@16.4.5
npm ls next
npm run build

A self-hosted app has to be rebuilt and redeployed for the fix to reach production. The standalone output and Docker images contain the version they were built with, so updating package.json on its own changes nothing that is running. After the deploy, check what is live, not what the repository says. Some apps expose the version in a health endpoint, and on others the fastest check is the build log of the image that is actually running.

If you are still on Next.js 15, take 15.5.29 now and plan the move to 16 before January 31, 2027. The jump from 15 to 16 is a major version with breaking changes listed in the official upgrade guide, so it deserves its own branch and a proper test pass, not a Friday afternoon.

If you are on 14 or older, there is no patched version to install. This release is a good reason to schedule the upgrade, because every monthly release from here on will add to the list of fixes that the old line does not have.

A Monthly Rhythm Worth Planning For

Since July 2026 the Next.js team has published its security fixes on a monthly schedule, announced about a week ahead, with out-of-band releases when an upstream dependency forces one. September closed with a scheduled release on the 30th, and October brought an out-of-band update on October 14 for two Critical and one High issues in upstream dependencies. We covered the two critical remote code execution fixes in 16.4.1 and 15.5.28 in Two Critical Next.js RCE Flaws and How to Patch Your App.

For teams that run Next.js in production, the practical answer is to treat the first week of each month as patch week. Read the pre-announcement when it lands, check the exposure questions above, and have the upgrade, build and deploy ready to go on release day. With a working CI pipeline and a staging environment, that is an hour of work a month.

What We Found on Our Own Site

This site runs on Next.js, self-hosted on Kubernetes, so we ran the same checks on it before writing this. It was on 16.4.2. The configuration does not enable Cache Components and no file in the code uses use cache, so the four cache advisories did not apply. Every route that sets a runtime uses Node.js, not Edge. The image optimiser has no remote sources configured, so it only ever processes our own files. And no route hands a fetched response back to the client unchanged, which rules out the framing issue whatever proxy sits in front.

None of the seven reached us. We upgraded to 16.4.5 anyway, in the same deploy that published this post. The lockfile change was ten packages, all of them Next.js itself and its platform binaries, and the build and the pages we checked behaved exactly as before. That is the typical picture for a content site or a single-tenant app, and it is why the upgrade is cheap enough to do every month without a debate.

What This Means for Your Team

Most teams can read this release as low risk and still apply it this week. Multi-tenant applications that use Cache Components should treat it as urgent, because the High advisory is exactly the kind of bug that leaks one customer's data to another without anything appearing in an error log.

If you would rather not track the Next.js release calendar yourselves, we run self-hosted Next.js applications on Kubernetes and keep them patched as part of our security and compliance work.

Sources

• Next.js November 2026 Security Release
• Upcoming Next.js November Security Release
• Next.js security news and advisories
• Next.js support policy
• GHSA-mfr8-8qww-v76h, cross-tenant cache disclosure
• GHSA-pc58-hwjq-p385, stale compressed response framing
• GHSA-f3mh-rxg3-f5g2, cookie values in an internal header
• GHSA-7qx7-33qx-rqx2, SVG rejection bypass