Concise answer
On 3 November 2026, Next.js released versions 16.4.5 and 15.5.29 to fix seven security vulnerabilities, one rated high severity and six medium. Not every Next.js website is exposed: most of the issues depend on specific features, such as the newer use cache and Cache Components caching, or on self-hosted and Edge setups. Ask your developer which version your website runs, whether it uses the affected features, and to confirm in writing that it has been updated to a patched version.
If your website was built with Next.js, there is a good chance you have never read a Next.js security advisory. That is normal. Advisories are written for developers, and they assume you know what a cache key or an Edge route handler is.
But the business owns the risk. If a vulnerability shows one customer's data to another, serves the wrong content, or exposes login cookies, the problem lands on your brand, not on the framework. This guide explains the November 2026 Next.js security update in plain language, helps you work out whether your website is affected, and gives you the questions to ask the people who maintain it.
What the Next.js team released on 3 November
On 27 October 2026, the Next.js team published an advance notice that a scheduled security release was coming. On 3 November, it published the November 2026 security release with patched versions and full details.
| Detail | What it means |
|---|---|
| Patched versions | 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS) |
| Number of issues | Seven vulnerabilities |
| Severity | One high, six medium |
| Main themes | Newer caching features, self-hosted setups, Edge routes, and image optimisation |
| Recommended action | Update to a patched version |
The advance notice described all seven issues as medium. When the full release was published, one was rated high. That is a useful reminder to read the final advisory, not just the early announcement.
Here are the seven issues in plain language:
| Issue | Severity | Who it can affect |
|---|---|---|
| Cached data shown across tenants when two caching methods are combined | High | Sites using Cache Components, where a cached function is called both directly and through unstable_cache, and reads a value such as a tenant or site ID |
| Cached content shown across sites, tenants or languages in nested cached functions | Medium | Sites using Cache Components with nested use cache functions that read a root value such as a tenant or locale |
| One user's cached result shown to another through certain binary arguments | Medium | Sites passing user- or account-specific binary data into use cache functions |
| Shared page shell "poisoned" by a crafted request | Medium | Self-hosted sites running next start with Cache Components enabled and a specific dynamic route setup |
| Responses sent to the wrong visitor through a reverse proxy | Medium | Self-hosted sites that pass fetched responses straight through, behind a particular kind of HTTP/1.1 reverse proxy |
| Cookie values exposed through an internal header | Medium | Edge Route Handlers or Edge API routes that set cookies with NextResponse.cookies.set() |
| SVG files slipping past a block setting in image optimisation | Medium | Sites using image optimisation with an image backend that can decode SVG, where SVGs are meant to be blocked |
None of the issues is described as letting an attacker take over the server. Most are about data or content being shown to the wrong person, or cached incorrectly. For a business, that can still mean leaked customer information, broken pages, or damaged trust.
Which websites are actually affected (and which are not)
A Next.js website is not automatically at risk just because it uses Next.js. Each vulnerability needs a particular combination of features, code patterns or hosting setup. Your developer can usually rule most of them in or out within an hour.
The four questions that decide exposure
| Question for your developer | If yes | If no |
|---|---|---|
Does the site use Cache Components or the use cache directive? | Four of the seven issues may apply, depending on how caching is written | Those four cache issues do not apply |
Is the site self-hosted with next start, for example on a VPS, AWS, DigitalOcean or a company server? | Two issues may apply, depending on caching and reverse-proxy setup | Those two self-hosted issues do not apply |
Does the site have Edge Route Handlers or Edge API routes that set cookies with NextResponse.cookies.set()? | The cookie exposure issue may apply | It does not apply |
| Does the site use Next.js image optimisation with SVG blocked and an image backend that can decode SVG? | The SVG issue may apply | It does not apply |
Some issues overlap. For example, the shared shell issue needs both self-hosting and Cache Components.
Websites more likely to be exposed
- Multi-tenant or multi-site platforms, such as a single codebase serving several brands, projects, franchises or language versions, where caching separates one tenant's data from another's.
- Websites with logged-in areas, such as customer portals, dashboards, or accounts, where cached content is meant to differ by user.
- Self-hosted builds, where the business or agency manages the server, proxy and caching layer directly.
- Recent builds using the newer caching features, because the cache-related issues are concentrated there.
Websites less likely to be exposed
- Marketing and brochure websites that do not use Cache Components or
use cache, have no logged-in areas, and do not use Edge cookie routes. - Websites not built with Next.js. Sites on WordPress, Shopify, Webflow or other platforms are not affected by this release, although they have their own updates to manage.
"Less likely" is not the same as "safe". The simplest and safest course is still to update to a patched version, even if your developer believes none of the issues applies. A patch within the same release line is usually a small, low-risk change.
Do not assume your host has handled it
The advisory asks teams to patch their Next.js dependencies. Next.js is part of your website's code, so updating it is normally the job of whoever maintains that code, not the hosting company. Ask your developer to confirm the update rather than assuming the platform has done it automatically.
How to check your site's Next.js version and update safely
You do not need to run these steps yourself, but knowing them helps you ask the right questions and recognise a proper answer.
Finding the version
The Next.js version is recorded in the website's code, in two files. package.json lists the version range the project accepts, for example "next": "^16.4.2". package-lock.json records the exact version actually installed. A developer can also run npm ls next in the project folder to see it directly.
Ask for the exact installed version, not the range. A range such as ^16.4.2 does not tell you whether the live website is on 16.4.2 or 16.4.5.
| Version your site runs | What to do |
|---|---|
| 16.4.5 or 15.5.29, or later in the same line | Patched for this release |
| An earlier 16.4.x or 15.5.x version | Update within the same line; usually a small, low-risk change |
| An earlier 16.x or 15.x line, such as 16.1 or 15.3 | Move to 16.4.5 or 15.5.29; this crosses more changes, so test carefully |
| 14.x or older | The advisory lists no patched versions for these lines; plan an upgrade to a supported version |
Updating safely
For a developer, the update itself is one command:
npm install [email protected] # for the 16.4 line
npm install [email protected] # for the 15.5 lineThe care is in what happens around it:
- Update on a separate branch, not directly on the live website.
- Build the project and fix any warnings or errors.
- Deploy to a preview or staging copy.
- Test the journeys that matter: homepage, key landing pages, enquiry and booking forms, logins, checkout, and any language or region versions.
- Pay extra attention to pages that use caching, and to any pages that show different content to different customers, brands or locations.
- Deploy to production, then confirm the live website is running the patched version.
- Clear or revalidate cached content if the website could have been affected before the update.
- Watch error logs, uptime monitoring and analytics for the next few days.
For most well-maintained websites, this is a few hours of work. If your developer says it will take much longer, that usually means the website has fallen behind on earlier updates, which is worth knowing in itself.
Why post-launch maintenance is part of website ownership
A website launch is the start of ownership, not the end of the project. The frameworks, libraries and servers underneath it keep receiving security fixes, and those fixes only protect your website once someone applies them.
The last few weeks show how often this happens. In October 2026, PHP shipped urgent fixes for critical vulnerabilities affecting WordPress and other PHP websites, and Node.js released its own security updates on the same day, as we covered in our PHP security alert. Now Next.js has followed with seven more. No technology choice removes the need for maintenance; it only changes what needs maintaining.
Who is responsible?
Many businesses assume the agency that built the website is still looking after it. Unless there is a maintenance agreement, that is often not true. The original project ended at launch, and no one is watching for advisories.
| Role | Usually responsible for |
|---|---|
| Business owner | Knowing who maintains the website, approving updates, and keeping account access in the business's name |
| Developer or agency on a maintenance plan | Watching advisories, applying updates, testing, deploying and monitoring |
| Hosting provider | The server or platform itself, but usually not your website's code or its Next.js version |
What good maintenance looks like for a Next.js website
- Watching Next.js, Node.js and dependency security advisories, including advance notices.
- Applying security patches within an agreed response time, with routine updates on a regular schedule.
- A preview or staging environment for testing updates before they go live.
- Automated dependency checks that flag known vulnerable packages.
- Uptime, error and performance monitoring, so problems after an update are caught quickly.
- A plan to move off unsupported versions before they stop receiving fixes.
- Code repository, hosting, domain and DNS accounts held in the business's own name.
For small and mid-sized businesses and D2C brands in India, website maintenance usually costs far less than responding to a data leak, a broken checkout, or a week of lost enquiries.
If you are not sure which Next.js version your website runs, or who is responsible for updating it, our analytics and ongoing support team can review your setup, apply this update safely, and put a maintenance plan in place so future advisories are handled before they become problems. For larger changes, such as moving an older Next.js website to a supported version, our custom web design and development team can plan the upgrade.
Questions to ask your web agency or developer
Send these questions this week and ask for written answers. A good developer will be able to answer most of them quickly.
- Which exact version of Next.js is our live website running?
- Has it been updated to 16.4.5, 15.5.29, or a later patched version? If not, when will it be?
- Does our website use Cache Components or
use cache? If yes, could any of the cache issues have affected our customers' data or content? - Is our website self-hosted with
next start, or hosted on a managed platform? Does our reverse proxy or CDN setup match the conditions in the advisory? - Do we have Edge routes that set cookies, and do we use image optimisation with SVG blocked?
- After updating, will cached content be cleared or revalidated?
- Was the update tested on a staging or preview copy, including forms, logins and checkout?
- If we are on Next.js 14 or older, what is the plan and cost to move to a supported version?
- Who watches for future security advisories, and how quickly will critical patches be applied?
- Are our code repository, hosting, domain and DNS accounts held in our business's name?
If the answers are vague, or no one is clearly responsible, that is the real risk to fix, whatever this particular release contains.
A quick summary
- On 3 November 2026, Next.js released 16.4.5 and 15.5.29 to fix seven vulnerabilities: one high severity, six medium.
- Four issues involve the newer caching features, Cache Components and
use cache; others affect self-hosted setups, Edge routes that set cookies, and image optimisation. - Not every Next.js website is exposed, but updating to a patched version is the simplest and safest step for all of them.
- Patching may not clear content that was already cached incorrectly, so affected sites should also clear or revalidate their cache.
- Next.js is part of your website's code, so updates are normally your developer's job, not your host's.
- A maintenance plan with a named owner is the best protection against the next advisory.
Frequently asked questions
What was in the November 2026 Next.js security update?
Next.js released versions 16.4.5 and 15.5.29 on 3 November 2026 to fix seven vulnerabilities. One was rated high severity and six medium. Most relate to the newer caching features, Cache Components and use cache; others affect self-hosted applications, Edge routes that set cookies, and image optimisation.
Is my Next.js website affected?
It depends on the features and hosting your website uses. The cache issues need Cache Components or use cache, two issues need self-hosting, one needs Edge routes that set cookies, and one needs image optimisation with an SVG-capable image backend. Your developer can check, but updating to a patched version is recommended either way.
How do I check which Next.js version my website uses?
The version is recorded in the website's code. package.json shows the accepted version range, and package-lock.json shows the exact installed version. A developer can also run npm ls next in the project. Ask for the exact installed version on the live website.
How do I update Next.js to the patched version?
A developer runs npm install [email protected] for the 16.4 line or npm install [email protected] for the 15.5 line, then builds, tests on a preview copy, and deploys. Moving from an older line, such as 15.3 or 16.1, may need more testing.
Is my website safe if it is hosted on Vercel?
The advisory asks teams to patch their Next.js dependencies and does not say any hosting platform patches websites automatically. Some issues apply only to self-hosted setups, so hosting on a managed platform may reduce exposure, but the safest course is still to update your website's Next.js version.
What is a cache poisoning vulnerability?
Cache poisoning happens when someone causes incorrect content to be stored in a website's cache, so later visitors receive it instead of the correct page. In this release, one issue allowed a crafted request to poison a shared page shell on certain self-hosted Next.js websites.
Does a Next.js update affect SEO?
A patch within the same release line should not change how pages render, so it should not affect rankings. A poisoned cache serving errors or wrong content could hurt both visitors and search visibility. Test key pages after the update and check Google Search Console for new errors.
What does website maintenance include for a Next.js site?
Good maintenance covers watching security advisories, applying patches promptly, testing on a staging copy, monitoring uptime and errors, planning upgrades before versions lose support, and keeping account access in the business's name.