On 3 November 2026 Vercel, the company that maintains Next.js, released security fixes for seven issues, one rated high and six rated medium. The fixes are in Next.js 16.4.5 and 15.5.29, and Vercel's post asks people to patch their Next.js dependencies.
Nothing in Vercel's announcement says any of the seven is being exploited, the post gives them no CVE numbers, and I found nothing for them in CISA's list of known exploited vulnerabilities when I checked on 5 November. That isn't a guarantee. Adobe said it knew of no exploitation of a Magento flaw, and CISA listed it six weeks later. My reading is that this one sits on the watch side of the line and not the alarm side.
First, does this apply to you?
Next.js is a framework, the code a developer builds a website on top of. It isn't something you log in to or install from a menu, so no screen on your site shows its version. If your site is on WordPress, Wix, Squarespace or Shopify, this one probably isn't yours, unless it also has a separate front end built on Next.js.
If a developer or an agency built your site in code, it might be, and the person who knows is whoever wrote it. The question for them is whether the site runs on Next.js, and which version. My own site is built on Next.js, and I moved it to 16.4.5 on 4 November, the day after the release.
What was fixed
Vercel's post lists seven. Three name Cache Components, a newer Next.js feature that stores the result of work so it doesn't have to be repeated, and a fourth concerns `use cache`, the directive that feature is built on. In plain terms, in the order Vercel gives them:
High, caching.
With Cache Components on, if the same public cached function is called both directly and from inside `unstable_cache`, an older Next.js caching function, and it reads a value such as a tenant identifier, a request can be handed another request's result. Where that value separates clients, the result can be another client's data.
Medium, nested caching.
With cached functions nested inside each other, if an inner one reads a value such as a tenant, site or locale and returns early while a slower value is still loading, and the outer one finishes without waiting, content made for one can be served to requests for another.
Medium, binary data in `use cache`. Different binary values can be treated as the same cache entry, so where an app passes security-significant binary values through `use cache` and shares the entries, one user can receive another's cached result.
Medium, shared page shell.
On a site a company runs on its own server with Cache Components on, an unauthenticated request with a crafted address can put the wrong content into a page shared by other addresses, giving visitors wrong content or persistent not-found pages. Vercel says it needs a particular shape of page.
Medium, response framing.
On a site run on its own server behind a proxy that queues requests on a shared connection, a response can be sent to the wrong visitor, if the app returns a response it fetched from an attacker-controlled source unchanged and an attacker can arrange requests on that connection.
Medium, edge cookies.
On edge routes, which are server endpoints that run close to the visitor, a cookie set the usual way can appear in a header that page script can read, even when it's marked as hidden from script.
Medium, image handling.
An image from a permitted source can slip past the setting that blocks SVG files, which raises exposure to resource exhaustion and flaws in image decoders.
What each one depends on
Vercel is careful about the limits, and so should a reader be. Three of the caching issues need Cache Components, and the binary-data one is tied to `use cache`. Two need the site run on its own server, and the response one needs that particular kind of proxy. The cookie issue needs a sensitive cookie plus an attacker's script already running on the same site, and Vercel says it isn't a way to run script by itself. The image issue doesn't on its own show a way to run code.
Whether any of the seven applies to a given site comes down to which features it uses, and that's a question the developer can answer in a sentence.
How to check
Vercel's post names two fixed versions: 16.4.5 for its current long-term support line and 15.5.29 for its maintenance line. It names no fixed version for other lines, so a site on another one is a question to put to the developer.
The exact questions are short. Does our site run on Next.js, and which version? Has the 3 November security release gone on? Does the site use Cache Components, `use cache`, edge routes or Next.js's image handling, or run on its own server?
Then sort yourself into one of these.
Version 16.4.5 or 15.5.29, the two Vercel names.
The fixes are in. My reading is that later releases carry them too, but Vercel's post doesn't say so.
An older version on either line.
The fixes aren't, and that's worth raising with whoever maintains the site.
A different line altogether.
Vercel's post doesn't say, so ask the developer what the plan is.
Nobody can say which version it runs.
That's a finding in itself, and it matters whatever the answers to the other questions turn out to be.
A version number is a record, not a guarantee
A developer chooses the framework version when they build the site, and in my experience it changes when someone changes it and builds the site again. That's my reading from how I work, and some sites let a range of versions float, so it's a question to put to the developer and not a rule.
A version number tells you which fixes are in. It doesn't tell you whether any of the seven was ever used against your site, and neither Vercel's post nor CISA's catalogue says any of them has been.
Who watches the framework?
I build with Next.js and with Astro, so I look at releases like this one for my own sites. Not every business has someone doing that, and there's nothing odd about it. It's a job that needs a name against it.
It can be the developer who built the site, an agency you already work with, or a care plan. I run a care plan, and that's a service I sell. Whether any plan covers framework releases is something to ask before relying on it, mine included.
What to read next
Is your WordPress site patched against CVE-2026-119977?
WordPress fixed a flaw in its own upgrade process on 28 October, and CISA listed it as exploited on 3 November. The question worth asking is which version your site runs, and who confirmed it.
Read articleAstro or Next.js for a business website?
My rule for choosing between Astro and Next.js, and what two of my own sites send on first load, measured with PageSpeed Insights on 25 October and 5 November 2026.
Read articleAre your iPhone, iPad and Mac covered by the fix for CVE-2024-27834?
Apple released the fix in May 2024, and CISA listed the flaw as exploited on 4 November 2026. The question worth asking is what software your business's Apple devices are running, and who knows.
Read articleAbout this notice
Published 2026-11-06 and accurate to the sources linked above as at that date. Security situations move, so check the vendor's own advisory before you act on anything here.
This is general information about a published vulnerability. It's not advice about your site, which nobody can give without looking at it, and nothing here should be treated as a substitute for your own provider or a security professional.
Questions local business owners usually ask next
Could you say what your website is built on?
If nobody can answer that within a day, that's worth fixing before the next release lands. Send me the address and I'll tell you what I can see from the outside.