Next.js November security release: 3 Nov, then 31 Jan 2027

The Next.js November security release lands on Tuesday 3 November 2026 with seven medium-severity fixes, and the version you are on decides whether you get them. 16.x and 15.x are both still receiving security patches; 14.x has not had one all year. The date that matters more than Tuesday is 31 January 2027.

What the Next.js November security release actually covers

Vercel pre-announced it on 27 October, six days ahead: seven medium-severity vulnerabilities in one release on Tuesday 3 November. No time of day, no timezone, no CVE identifiers, no patched version numbers. The post commits only to publishing the full advisories alongside the release, including impact, affected versions and upgrade instructions.

That is deliberately thin, and it is the point of a pre-announcement. You get six days to decide what you will do, not six days to prepare a specific patch. Seven mediums is also a quiet month by this year's standard: the 30 September release carried one high, five medium and one low, and the 14 October out-of-band release carried two criticals and a high.

Where the three live release lines stand as of 1 November 2026:

Line	Status on the support policy	Security fixes committed until
16.x	Active LTS	No announced end date
15.x	Maintenance LTS	31 January 2027
14.x and older	Unsupported	No commitment

Next.js has not said which lines Tuesday's patches will land on. Every security release this autumn went to exactly two: 16.3.6 and 15.5.26 on 22 September, 16.3.8 and 15.5.27 on 30 September, and 16.4.1 and 15.5.28 on 14 October. Set that against a written commitment to keep publishing 15.x security releases, and a 15.5.x patch on Tuesday is the reasonable expectation. It is not a promise, and you should not write a change ticket that assumes a version number nobody has published.

Every end-of-life tracker says Next.js 15 died on 21 October. The policy says 31 January

Check this before you fund anything. Search for Next.js 15's end-of-life date and you get 21 October 2026 — a date already in the past — from endoflife.ai, from vendor blogs and from firms selling post-EOL support contracts. The official support policy says something else, in a callout box on the same page as the version tables:

To give teams more time to upgrade, Maintenance LTS for Next.js 15 has been extended beyond its original end date of Oct. 21, 2026. We'll continue publishing security releases for Next.js 15 through Jan. 31, 2027.

The trackers are not wrong so much as stale. The same policy page states that each major version remains in Maintenance LTS for two years following its initial release, and 15.0 shipped on 21 October 2024. Apply the rule and you get 21 October 2026. The extension is prose next to the rule, and the rule is what got scraped.

The practical consequence is narrow and worth acting on. If your internal upgrade dashboard, your security review or an automated dependency report draws its dates from one of these trackers, it is currently telling you that a production app is running unsupported framework code. It is not. As of 1 November 2026 you have thirteen weeks of committed security patches left on 15.x, which is enough to plan an upgrade and not enough to defer one past the next planning cycle.

Do not read the extension as a pattern, either. Vercel is collecting upgrade blockers in a GitHub discussion linked from the policy page, opened on 27 October, and as of 1 November it had three participants. The two blockers commenters actually named were NextAuth v4 being incompatible with Next.js 16 while v5 is still beta, and a team waiting for Next.js 17 rather than migrate twice. That is a small sample to build a second extension on.

Will Next.js 14 get the November security fixes?

Almost certainly not. On the support policy, 14.x appears in exactly one place: a row in the Unsupported Versions table, release date 26 October 2023, with no end date and no prose anywhere else on the page. There is one escape clause — in rare circumstances, depending on the severity of the underlying bug, Vercel will patch versions outside the LTS policy — and seven medium-severity issues is not what that sentence is for.

The record agrees. None of the three security releases between 22 September and 14 October patched any 14.x version, and that includes 14 October, which fixed two unauthenticated remote code execution bugs. If two criticals did not trigger the rare-circumstances clause, seven mediums will not.

So on Tuesday a Next.js 14 app gets the advisories and nothing to install. The advisories are still worth reading closely, because several of this year's have been far narrower than their severity implies. In the September set, the image-optimisation SSRF affected only apps with images.remotePatterns configured; the metadata-route bug affected webpack builds and not Turbopack; and one cache-poisoning issue was Pages Router and self-hosted only, with Vercel-hosted apps explicitly not affected. That last carve-out does not generalise — the October criticals carried no such exemption — but it does mean the answer to "are we exposed" is sometimes no, for a reason you can check in your own config.

Dependency-level mitigation sometimes exists too. October's critical SVG remote code execution lived in sharp, and the advisory's own stopgap was to ensure the sharp version Next.js resolves is 0.35.5 or later. A 14 app can do that. It cannot do it seven times a month indefinitely.

What upgrading to 16 actually costs on a self-hosted app

The version 16 upgrade guide, last updated 15 October 2026, is written for one journey: 15 to 16. The floor is Node.js 20.9, with Node 18 no longer supported, and TypeScript 5.1 — so if you have been picking a Node line to target, Next.js 16 makes that decision for you. Browser support moves to Chrome, Edge and Firefox 111 and Safari 16.4.

The change most likely to break a self-hosted build is Turbopack becoming the default for both next dev and next build. A custom webpack config now makes next build fail outright unless you pass --webpack. Teams that bolted a loader or a plugin onto the build to make self-hosting work will hit this on the first CI run, not in review. After that the list is mechanical but long: synchronous access to cookies, headers, draftMode and params is gone; middleware is renamed to proxy on the Node runtime; revalidateTag requires a second argument; parallel route slots need explicit default.js files or builds fail; next lint is removed and next build no longer lints; and serverRuntimeConfig and publicRuntimeConfig are removed outright.

Most of it is codemoddable. Run npx @next/codemod@canary upgrade latest on a branch and the diff it produces is your estimate — cheaper than any meeting about the estimate. What the codemod will not do is replace a publicRuntimeConfig pattern or redesign a webpack-dependent build, and those are the two that turn a week into a quarter. This is the point where the work stops being a version bump and starts being a web application upgrade with a test plan.

The case for sitting still is stronger than it looks. Patching 15.x is a patch bump and a deploy; the extension hands you thirteen more weeks; and one of the two people in Vercel's own feedback thread is waiting for 17 precisely to avoid migrating twice in a year. The problem with that plan is the shape of the two dates. Active LTS ends when the next major ships, and Next.js shipped a major each October for two years running — 15 on 21 October 2024, 16 on 21 October 2025 — then did not ship one this October, which is why 16.x is still listed as Active LTS. Waiting for 17 swaps a dated deadline you can plan against for an undated one you cannot.

Upgrading now is the wrong call in one specific case: a 15 App Router app with no custom webpack config, no Pages Router routes and async request APIs already in place. There the codemod does nearly all of it, so the work does not need a project — schedule it, do not fund it. The opposite case is a 14 app on the Pages Router with a customised build. Version 15 introduced the async request APIs with temporary synchronous compatibility and 16 removes that compatibility, so a 14 app pays for both migrations at once, against a documented path that does not cover its starting point. That is legacy modernisation work with a framework upgrade inside it, and scoping it as a patch is how it overruns.

What to do before Tuesday

1. Record the exact version, from the lockfile. Not the range in package.json. The advisories on Tuesday will name affected versions precisely, and ^15.5.0 will not tell you whether you are on 15.5.28.
2. Correct your end-of-life data. If any internal report says Next.js 15 support ended on 21 October 2026, replace it with 31 January 2027 and cite the support policy, not a tracker.
3. Make sure a patch bump can ship the same day. On 15.x and 16.x the fix will be a patch release. If your release process cannot get one out inside a day, that, not the CVEs, is your exposure.
4. If you are on 14, decide what you are buying. Advisory-by-advisory mitigation with no upstream patches, or the migration. Both are real choices; drifting between them is not.
5. Run the codemod on a throwaway branch this week. You need the size of the diff before 31 January, not after.

Thirteen weeks is enough time to do this calmly and not enough to do it twice. If you are weighing whether your Next.js 14 or 15 app can be patched in place or has to move to 16 now, our web app development team sizes that upgrade against your actual build config and release process, and tells you which of the two it is before you commit a quarter to the answer.