Next.js November Security Release: What to Prep Before Nov 3

The Next.js team has given a week's notice: a scheduled security release is coming on Tuesday, November 3, 2026, and the pre-announcement on the Next.js blog says it will fix seven vulnerabilities, all rated medium. The post is short on purpose. It doesn't name affected versions, CVE IDs or attack vectors, so for now you can't tell whether your app is exposed. What you can do is make sure that on November 3 the upgrade is a small, boring dependency bump and not a scramble.

What the announcement says, and what it leaves out

Here is everything the post confirms:

The release lands on November 3, 2026.
It fixes seven vulnerabilities in Next.js, each rated medium severity.
Full advisories ship with the release and will cover impact, affected versions and upgrade instructions.
The team recommends upgrading to a patched version once it's out.

The authors explain why they're posting early:

"This advance notice gives teams time to plan upgrades before patches are published."

— Next.js blog, October 27, 2026

The post also mentions that many of these reports come in through Vercel's Open Source Bug Bounty on HackerOne, and that security questions go to security@vercel.com.

Several things are still unknown, and they matter for planning:

Which release lines get patches. The post doesn't say whether older majors will get backports or only the current major. If you're more than one major behind, plan as if you'll have to move up.
Which features are affected. Seven medium issues could sit in middleware, the image optimizer, Server Actions, caching or the App Router's RSC handling. Until the advisories are out, nobody outside the team knows.
Whether React packages are involved. The announcement only talks about vulnerabilities "in Next.js." It doesn't say whether react-server-dom-* or other React packages are part of it.
Whether hosted platforms get mitigations first. In past incidents some hosting providers added platform-level protections before or alongside the patches. This post doesn't promise that. If you self-host with next start or a standalone build, assume the patch is your only fix.

Why "medium" doesn't mean "skip it"

Medium severity usually means an attacker needs particular conditions: a certain config, a feature you have to opt into, or a less damaging outcome like denial of service or leaking information instead of running code. Seven of them in one release is still a reason to upgrade on the day, not someday.

There's also a practical risk. Once advisories are public, the patch diff shows attackers exactly where to look, and exploits for web frameworks can show up within days. Next.js has had severe incidents recently, including the March 2025 middleware authorization bypass (CVE-2025-29927) and the December 2025 React Server Components remote code execution issue. In both cases, teams that could ship a dependency bump the same day were in much better shape than teams stuck on an unsupported major. A scheduled release with a week's warning is the easy version of this problem, so use the week.

What to do before November 3

1. Find out exactly which version you run

Your package.json range doesn't tell you this. Check what actually got installed, in every app and package of a monorepo:

1# What the lockfile resolved
2npm ls next
3
4# pnpm workspaces: every package that depends on next
5pnpm why next -r
6
7# The binary that actually runs
8npx next --version

If different packages resolve to different versions, fix that now. A monorepo where one app quietly sits on an old minor is how "we patched" turns out to be untrue.

2. Get onto a current major if you're behind

This is the step that takes real time, and it's the reason to start now. If the patches only reach the current major (and maybe the one before it), being two majors behind turns a security fix into a migration. Next.js ships an upgrade codemod that handles a lot of the mechanical changes:

1npx @next/codemod@latest upgrade latest

Run it on a branch, read the diff, and run your full test suite. If the jump is too big to finish this week, at least move to the newest release of the major you're on, so the patch is a small step from there.

3. Make sure you can deploy on the day

Look at what would slow down a deploy: frozen release windows, manual QA gates, a staging environment nobody has touched in weeks. Check now that a patch-level next bump can go through CI and reach production on November 3 or 4. If you need to plan around a change freeze, now is when to do it.

4. Let automation open the PR

If you already use Dependabot or Renovate, make sure security updates for next aren't held back by a schedule or grouping rule. Here's a Dependabot config that keeps next (and the matching ESLint config) in its own group so the PR shows up on its own:

1# .github/dependabot.yml
2version: 2
3updates:
4  - package-ecosystem: "npm"
5    directory: "/"
6    schedule:
7      interval: "daily"
8    groups:
9      nextjs:
10        patterns:
11          - "next"
12          - "eslint-config-next"

Security PRs from Dependabot ignore the schedule, but keeping next in its own group means the patch won't be buried in a bundle of 20 unrelated bumps.

What upgrading will probably look like

There's no before/after code to show because the announcement doesn't describe any API changes. Security patch releases of Next.js have usually been drop-in version bumps. Once the advisories are published, the upgrade should look something like this:

1# Replace with the patched version listed in the advisory for your release line
2npm install next@<patched-version> eslint-config-next@<patched-version>
3npm run build

Don't just install next@latest without thinking about it. If you're on an older major that gets a backport, latest could pull you into a major upgrade you didn't plan. Read the affected-versions section of each advisory and pin the patched version for your line.

One caveat: sometimes a security fix has to close a hole by tightening behavior, such as stricter header handling, stricter request validation or a narrower image optimizer config. If any of the seven advisories say so, the release notes should spell it out. Read them before assuming the bump has no side effects, especially if you have custom middleware, rewrites or images.remotePatterns settings.

The bottom line for your week

You can't patch anything yet, and guessing at the vulnerabilities won't help. Use the next six days to find out what you run, close any gap between major versions, and clear the path to deploy. Then on November 3, read the seven advisories, figure out which apply to your setup, and ship the patched version that day. If you self-host, don't wait for anyone else to mitigate this for you.