Next.js's November 2026 security release patches seven bugs — one rated High, six Medium — in versions 16.4.5 and 15.5.29. Most of them touch caching behavior and self-hosted deployments, not Vercel-only infrastructure. If you run Next.js on your own VPS instead of Vercel's managed platform, this one's on you to patch. Nobody does it for you.
What did Next.js patch in its November 2026 security release?#
Vercel's Next.js team shipped this Next.js security release on 3 November 2026, fixing seven vulnerabilities across versions 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS). One is rated High — a cross-tenant cache disclosure bug that shows up when unstable_cache and use cache get combined.
The other six are Medium: more cache poisoning and disclosure issues, a cookie-exposure bug in Edge routes, a response-injection flaw tied to compressed responses, and an SVG filter bypass in Image Optimization. Next.js's own advisory names no CVEs, only GitHub Security Advisory IDs, and gives no CVSS scores.
We flagged a Next.js critical vulnerability back in September — that one was a 9.5 CVSS remote-code-execution bug in the OG image generator. This release is a different animal. Lower severity on paper, but it sits in caching behavior a lot of sites use without ever thinking about it.
Does this affect self-hosted Next.js sites?#
Yes, and more directly than most Next.js advisories do. Two of the seven bugs are explicitly scoped to self-hosted deployments. One lets an unauthenticated request poison a shared page shell on sites running next start with Cache Components on and Partial Prefetching off or unset.
The other involves a self-hosted app forwarding an attacker-controlled fetched response unchanged, behind what the advisory calls "an HTTP/1.1 reverse proxy that queues pipelined requests on a shared backend connection." It doesn't name which proxies, so I can't tell you definitively whether a standard PM2-plus-Nginx setup sits inside that description.
At WebEpex, we self-host every client site on our own VPS stack rather than Vercel's managed platform, so this kind of advisory is always our problem to solve, not someone else's. My read: check it anyway, because the advisory's own hedge — "it does not apply to every reverse-proxy configuration" — isn't the same as a clearance.
If you're on Vercel, several of these were likely already handled on their end before the public post went up. That's part of what the managed platform is for. Confirm it with them instead of assuming it.
Who can skip this one#
Skip it, for now, if:
- You don't use
unstable_cache,use cache, or Cache Components anywhere in the app - You're not running Edge Route Handlers (the cookie-exposure bug doesn't touch standard Node.js routes)
- You're fully on Vercel's managed platform, and you've confirmed that with them rather than assumed it
If any of those don't apply — you're running Cache Components in production, or you're behind a reverse proxy you didn't configure yourself — this is worth an afternoon. Not a fire drill. An afternoon.
The honest trade-offs here#
The good: Vercel named the self-hosted scope explicitly instead of burying it, which is more than a lot of frameworks bother to do. For most sites, the fix is a version bump, not a configuration rewrite.
The not-so-good: no CVSS scores, no CVE numbers, no stated deadline. That makes it harder to triage by severity than, say, PHP's PHP2Shell bugs last month, which came with hard numbers attached from day one.
There's also a small typo in Vercel's own install instructions — the comment on one upgrade command reads "for 16.5" while the command itself installs 16.4.5. Minor, but it's exactly the kind of detail that makes me double-check a security post before copying commands straight out of it.
The real unknown: whether the reverse-proxy bug touches Nginx specifically. Vercel didn't say either way, and I'm not going to guess at a security boundary just to sound more certain than I am.
How we're handling it#
WebEpex pulled the version list against every client Next.js deployment on November 3, the day the release landed, and checked which ones actually touch Cache Components — most didn't, which narrowed the work fast.
For the handful that do, we ran the version bump through our usual staging-then-production sequence on PM2: patch staging, watch it for a day, then push to production. It's the same rollout order we used for n8n's own security release in September.
We've also already rewritten the deploy checklist for every self-hosted client, as of this week, to flag Cache Components usage specifically. The next advisory like this one should take minutes to triage instead of an afternoon.
What I'd tell a client asking about this#
Check whether your app uses unstable_cache, use cache, or Cache Components. If it doesn't, update when convenient — this week is fine, there's no fire here. If it does, update now; it's a version bump, not a migration.
If you're not sure which caching features your own site uses, that's a five-minute question for whoever built it. If the honest answer is "I don't know," that's worth flagging on its own, separate from this advisory.
If you're on Vercel, get it confirmed directly rather than assuming it's handled. "Probably already patched" isn't the same sentence as "confirmed."
Seven bugs, one patch, mostly caching. If you want me to check what your own site is actually running, send me the Next.js version and I'll tell you in two minutes whether this one touches you — cal.com/webepex/growth-review.
