The Next.js November 2026 security release is a caching release. Of the seven advisories Vercel published on November 3, four describe use cache entries leaking between tenants, locales or users, and a fifth lets one crafted URL poison a shared page shell. If you run one Next.js codebase behind several storefronts, markets or logged-in accounts, this patch is about data isolation, not just a version bump. The fixed versions are 16.4.5 and 15.5.29.
What the November 2026 release fixes
Next.js 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS) close seven advisories, and five of them sit in the caching layer introduced with Cache Components. The Vercel release post rates one issue High and six Medium; the GitHub advisory database currently lists all seven as medium. The headline item, GHSA-mfr8-8qww-v76h, covers a public cached function that reads a root parameter such as a tenant ID and is called both directly and through unstable_cache. During a cold fill, one request can pick up another request's result, and that wrong entry is then served until it is revalidated or evicted.
Three more caching bugs follow the same theme. Nested cached functions can store an outer entry before the inner function records which root parameter it depended on. Distinct binary arguments, such as typed arrays carrying an account key, can collapse to the same cache identity. And self-hosted next start apps with Cache Components on and Partial Prefetching off can have a fallback shell poisoned by an unauthenticated request, producing wrong content or sticky 404s for other URLs.
The last two are outside the cache. Edge route handlers that set cookies through NextResponse.cookies.set() can echo the value in an internal x-middleware-set-cookie header that same-origin scripts can read, even for HttpOnly cookies. And an image from an allowed remote host can be mislabelled as AVIF and reach the SVG decoder despite dangerouslyAllowSVG: false.
Who is actually exposed
You are exposed if one deployment serves more than one audience and relies on use cache to keep their data apart. That describes most serious headless commerce builds we see: one Next.js app fronting several country stores, a B2B portal with per-company price lists, or a marketplace with seller subdomains. Root parameters are exactly how those apps express "which tenant is this", so a cache that ignores them for a few milliseconds during a cold fill is a cross-tenant disclosure, not a cosmetic bug.
You are probably not exposed if Cache Components is off, if your cached functions never read root params, or if every tenant runs its own deployment. Single-market brochure sites on static export are out of scope entirely. Vercel's own notes are careful here. The cookie issue needs attacker JavaScript already running on your origin, and the response-framing issue needs an HTTP/1.1 proxy that pipelines requests from different clients over one backend connection. Neither is a remote takeover on its own.
Self-hosted vs Vercel: who carries the risk
Self-hosted teams carry more of this release than Vercel-hosted ones. Two of the seven advisories only apply to self-hosting: the shared shell poisoning under next start, and GHSA-pc58-hwjq-p385, where a route that returns a fetched response unchanged can forward decompressed bytes with compressed framing headers. Behind the wrong reverse proxy, that mismatch can hand one shopper's response to another.
The cache disclosure bugs apply everywhere, because they live in how cache keys are built, not in the platform. Hosting on Vercel buys you managed proxies and image infrastructure. It does not buy you correct cache keys. We covered the broader hosting trade in our self-hosted vs Vercel security note, and this release reinforces it: self-hosting is fine, but it means owning the proxy layer as part of your security surface.
What we would change this quarter
Patch first, then audit the cache boundaries the patch cannot see. Upgrade to 16.4.5 or 15.5.29 this week, then purge every persisted cache entry after deploy. A fix stops new bad entries from being written; it does not evict the ones already stored, and a poisoned shell can sit in a shared cache handler until revalidation.
Next, grep for every use cache function that reads a root param, cookie-derived value or account identifier, and ask one question of each: is the tenant part of the cache key explicitly, or only implicitly through a root param? We now pass the tenant or market as a plain string argument even where the root param already carries it. It costs one extra argument and turns an implicit dependency into an explicit one. Avoid wrapping a use cache function in unstable_cache; pick one caching model per function. Never key a cache on raw binary data. Hash it to a string you control first.
For self-hosted stacks, check whether your proxy pipelines HTTP/1.1 requests from different clients over a shared upstream connection, and turn that off or move to HTTP/2 upstream. Any route that proxies a third-party response, such as a PIM image or a payment status call, should rebuild the response instead of returning it unchanged. Move sensitive cookies out of Edge handlers and into Node.js route handlers, which the advisory says were not affected in testing. And keep remotePatterns as narrow as your actual asset hosts.
Put the next date in the calendar too. Node.js has announced security releases for November 11, 2026, so self-hosted storefronts face a second runtime patch within eight days. Batch both into one maintenance window if your release process allows it.
This is the kind of work we fold into headless commerce builds and ongoing e-commerce engagements: a written cache-key policy per tenant boundary, reviewed every time Cache Components changes. Multi-market stores are where caching pays off most, and where a leak costs the most trust.