The Patch I Did Not Expect to Be Writing About
I spend most of my working life inside WordPress and Elementor. Next.js is not my daily driver, and I will not pretend otherwise. But I pay attention to what happens in the wider web development world, because the same mistakes keep showing up in every stack — and this week, Next.js gave us a textbook example.
On November 3, 2026, Vercel shipped Next.js 16.4.5 and 15.5.29, fixing seven vulnerabilities — one High, six Medium — and most of them are caching bugs: under the right conditions, a cached result computed for one user, tenant, or locale could be served to somebody else entirely.
If you run a WordPress site, that should sound familiar. We live and die by caching too — page caches, object caches, CDN edge caches. The technology is different, but the failure mode is identical: a cache entry stored under the wrong identity.
What Actually Shipped on November 3
Next.js 16.4.5 and 15.5.29 both reached npm on November 3, 2026, and npm's latest tag now points at 16.4.5. The 16.4.5 release notes list seven advisories; the 15.5.29 notes list three of them, because the other four only affect the newer 16.x line and its Cache Components system. Every advisory carries a severity rating, a CVSS 4.0 score, and a CVE identifier on GitHub. None of the seven is rated Critical. But "not Critical" and "not a problem" are very different things, and the High-severity one is serious enough that the advice is unambiguous: if the conditions apply to your app, patch today.
This release also follows a much scarier one. On October 14, 2026, Vercel shipped an out-of-band update — 16.4.1 and 15.5.28 — fixing two critical unauthenticated remote code execution flaws, including CVE-2026-96889, rated CVSS 9.5. Patch releases are cumulative, so upgrading to 16.4.5 or 15.5.29 also picks up those October fixes. And if you are still on Next.js 14 or older, there is no patched release for these advisories at all — the only fix is to move up to a patched line.
The Seven Fixes, in Plain Language
Four of the seven issues live in Cache Components, the newer caching system in Next.js 16 built around the use cache directive. They all share one failure mode: a cache entry gets stored under an identity that is missing something that should have separated it from other entries.
1. Cross-tenant cache disclosure when mixing unstable_cache and use cache (High, CVE-2026-119790). This is the serious one. If a public use cache function reads a root parameter — a tenant ID, a site, a locale — and that same function is also called from inside unstable_cache, a concurrent cold cache fill could return another request's result without checking the root parameter. In plain English: a multi-tenant SaaS app could serve one tenant's cached data to another tenant. The CVSS 4.0 score is 6.3, and it affects 16.3 and later with Cache Components enabled.
2. Cross-root-parameter disclosure in nested use cache functions (Medium, CVE-2026-119351). The outer cache entry could be stored before the inner function's root-parameter dependencies were recorded, so content generated for one tenant, site, or locale could be reused for another.
3. Cross-user cache disclosure and poisoning through binary use cache arguments (Medium, CVE-2026-119349). Different binary arguments could produce the same cache key — two inputs, one cache identity — so one user's result can be served to another user, and an attacker can deliberately poison the entry.
4. Shared fallback shell cache poisoning on self-hosted apps (Medium, CVE-2026-119350). This affects next start deployments with Cache Components on and Partial Prefetching off or unset. One request can poison a fallback shell that a whole family of routes shares.
The other three fixes affect both the 16.x and 15.x lines, which is why 15.5.29 carries them. 5. Cross-client response injection through stale compressed response framing (Medium, CVE-2026-119348) affects self-hosted apps that return a fetched Response unchanged, behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared connection. 6. HttpOnly cookie values exposed on Edge routes (Medium, CVE-2026-119346): a cookie set on an Edge route could be copied into the internal x-middleware-set-cookie header, readable by same-origin JavaScript — though exploiting it needs attacker-controlled JavaScript already running on the same origin. 7. SVG rejection bypass in Image Optimization (Medium, CVE-2026-119347): with images.dangerouslyAllowSVG set to false, an image from an allowed remote source could be misclassified as AVIF and decoded as SVG anyway. The bypass does not by itself demonstrate cross-site scripting or remote code execution — but a security control that can be walked around is a control you cannot rely on.
Who Is Affected — and Who Is Not
Not every Next.js app needs to panic, and the release is refreshingly specific about who does. You are in the affected group if you run Cache Components with a public use cache function that reads a root parameter and is called both directly and inside unstable_cache — that is the High-severity one. You are also affected if you self-host with next start, set cookies in Edge routes, or optimise remote images. Multi-tenant apps have the most to lose, because the worst bugs here are precisely the ones that cross tenant boundaries.
If you are on Vercel or Netlify, hosted platforms generally roll these fixes out for you — Netlify published a platform notice alongside the release. Self-hosted apps have to move themselves.
The upgrade itself is simple. On the 16.x line, run npm install [email protected]. On the 15.x line, run npm install [email protected]. Then redeploy, and — this is the part people forget — empty any cache that survives a deploy. A patched application serving stale poisoned cache entries is still serving poisoned content. And one more time, because it matters: 16.4.4, the bug-fix patch from the day before, fixes none of these. If you updated on November 2 and felt current, you are not. The security fixes landed on November 3.
Why This Belongs on a WordPress and Elementor Site
Fair question. I do not run Next.js in production, and most of my readers do not either. But I have spent enough years debugging WordPress sites to know that the bug class matters more than the framework.
WordPress is a caching-heavy platform. A typical Elementor site I build has a page cache plugin, an object cache, a CDN with edge caching, and often a host-level cache on top of that — four layers, each with its own idea of what makes two requests "the same." Every one of those layers can make the exact mistake Next.js just fixed: keying a cached response on too little information.
Think about the WordPress equivalents. A page cache that does not vary on login state can serve a logged-in user's dashboard fragment to a stranger. A cache that ignores query parameters can serve one customer's filtered shop results to another. A CDN edge rule that caches a personalised page can show my name to your visitor. I have seen all three in the wild, on real client sites, and each one was a configuration choice somebody made without thinking about identity.
The Next.js release is useful precisely because it names the pattern. Two of the four cache bugs drop the root parameter from the key. Translated into WordPress terms: the cache forgot to include the thing that makes this request different from that one. Whenever you configure caching — in a plugin, on a host, or at the CDN — ask the same question: what varies this response, and does the cache key include all of it? Logged-in state, user role, language, currency, locale, query string. If any of those change the output and are not in the key, you have a bug waiting for traffic.
There is another reason this story belongs here. We have just lived through the same movie ourselves. On November 3, 2026 — the very same day as this Next.js release — CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue: a time-of-check time-of-use race condition in WordPress Core, being exploited in the wild during the very update process meant to fix things. WordPress had already fixed it in 7.1.4, released October 28. I verified both of my own WordPress sites were on 7.1.4 before the November 6 deadline. If you have not checked yours yet, do it tonight: Dashboard, Updates, and look at the version number. If it says anything below 7.1.4, update now, then clear every cache layer you run.
What I Would Do Tonight
Here is my honest checklist, whether you run Next.js, WordPress, or both.
First, check your versions. Next.js apps should be on 16.4.5 or 15.5.29. WordPress sites should be on 7.1.4 or later. This takes two minutes and it is the single highest-value action in this entire article.
Second, if you patched, clear the caches. Not one cache — all of them. The persistent cache directory, the object cache, the CDN edge cache. Poisoned entries do not expire just because the code changed.
Third, audit what your cache keys include. On WordPress, check your caching plugin's settings for how it handles logged-in users, query strings, and cookies, and check your CDN's cache rules for the same. If your host offers a "cache everything" page rule, make sure your dynamic pages — cart, checkout, account, anything personalised — are excluded. Elementor sites with WooCommerce are the classic case: a cached cart page is a data leak waiting to happen.
Fourth, stop mixing caching layers without a map. The High-severity Next.js bug happened at the boundary between two caching APIs — use cache and unstable_cache — used together. WordPress has the same hazard at the boundary between plugins: a page cache plugin and an object cache and a CDN that each assume the others are handling identity correctly. If you cannot draw your caching layers on a whiteboard and say what each one keys on, you do not have a caching strategy. You have a hope.
Conclusion
The Next.js November 2026 security release fixes seven vulnerabilities — one High and six Medium — most of them in the Cache Components caching layer, where entries could be stored under identities that forgot a tenant, a locale, or a user. Upgrading to 16.4.5 or 15.5.29 closes them, and clearing your caches after the deploy makes the fix real. The same week reminded WordPress owners of the same lesson, with an actively exploited core flaw fixed in 7.1.4. The deeper lesson is a design one: every cache is a promise that a stored answer is correct for every future request matching its key, and the moment the key is wrong the breakage is silent — the wrong person just quietly gets the right-looking page with somebody else's data in it. Patch your Next.js apps, check your WordPress sites are on 7.1.4, and take ten minutes to look at what your cache keys actually include. The next vulnerability in this family is already being written. The question is whether your site will be on the patched side of it.
FAQ
Do I need to update if my Next.js app does not use Cache Components?
Yes, if you are on the 15.x or 16.x line. Three of the seven fixes — response injection, the Edge cookie header, and the SVG bypass — affect apps that never touch Cache Components. Update to 16.4.5 or 15.5.29 either way.
What version should I be on after this release?
Next.js 16.4.5 on the 16.x Active LTS line, or 15.5.29 on the 15.x Maintenance LTS line. There is no patched release for Next.js 14 or older, so those apps need to move up to a patched line.
Does this affect my WordPress or Elementor site directly?
No — these are Next.js vulnerabilities, not WordPress ones. But the bug class is identical to WordPress caching mistakes, and the same week saw an actively exploited WordPress core flaw fixed in 7.1.4. Check your WordPress version and your cache configuration while you are thinking about it.
Should I clear my cache after upgrading?
Yes. A patched application can still serve stale or poisoned cache entries stored before the upgrade. Clear the persistent cache, the object cache, and the CDN edge cache as part of the deploy.
