Next.js 16.4.4: a bug-fix patch, not the security release

Next.js 16.4.4, released on 2 November 2026 and npm's latest on 3 November, is a bug-fix patch, not a security release. Its release notes (opens in a new tab) list seven backported changes and no security fix, and say the announced November security release comes out the next day. Two fixes matter in production: Turbopack builds of the 16.4 line could run minified server code without strict mode, and an inline Turbopack script missed the CSP nonce during a Partial Prerendering resume. The notes list no breaking change, and the npm entry keeps the dependencies, React peer range and Node.js range of 16.4.3. What to do: take 16.4.4 as a routine patch if you build with Turbopack or serve a CSP nonce with PPR, then upgrade again to the version the November advisories name. If you are still below 16.4.1, upgrade today for the critical October RCE fixes. We checked every claim below against GitHub, the npm registry and the Next.js blog on 3 November 2026; we did not run 16.4.4 on a demo.

What changed in Next.js 16.4.4

The release is a backport from canary to the active LTS branch, like 16.4.3 and its lighter proxy.ts ten days earlier. Every entry links a pull request against releases/lts/active; we opened each one on 3 November:

Change in 16.4.4	What it fixes	Who notices
Revert "Optimize strict module factory chunks" (opens in a new tab)	Minified production server code ran in non-strict mode	Turbopack production builds
Shared-runtime bootstrap in the PPR resume (opens in a new tab)	The Turbopack bootstrap script now gets the CSP nonce when a prerendered page resumes	Turbopack, Partial Prerendering and a nonce-based CSP
Reload on missed Turbopack startup CSS updates (opens in a new tab)	A CSS edit made before the browser connects to HMR no longer leaves stale styles: the page reloads	next dev with Turbopack
Route summaries as the analyzer route index (opens in a new tab)	Generated metadata routes export correctly in the analyzer	Teams that use the 16.4 bundle analyzer
fast-jwt instead of jsonwebtoken (opens in a new tab)	jsonwebtoken still uses SlowBuffer, which Node.js 26 removed	Pages Router Preview Mode
Pin deploy tests to Node.js 22.x (opens in a new tab)	Next.js's own CI	Nobody outside the Next.js repo
Disable one deployment test (opens in a new tab)	Next.js's own test suite	Nobody outside the Next.js repo

Strict mode in Turbopack production builds

This is the fix to care about. The revert explains that the original optimisation moved "use strict" out of each module factory into one wrapper per chunk, which exposed a bug in the SWC minifier: a function could silently lose strict mode in production builds. Canary fixed it with a newer SWC; the LTS branch reverts the optimisation instead, so every factory gets its own "use strict" again. Issue #100617 (opens in a new tab), reported on 16.4.2 and titled "since 16.4", shows the effect: after next build and next start, this in a plain function call was globalThis instead of undefined, while next dev and 16.3.1 behaved correctly. A library that relies on that difference broke; the reporter's was the rhea AMQP client, which crashed with this.container.get_option is not a function. The reporter's workarounds were turning off experimental.serverMinification or listing the package in serverExternalPackages. On 16.4.4 you can remove both.

The CSP nonce during a PPR resume

With Partial Prerendering (PPR), Next.js serves a prerendered static shell and then resumes rendering the dynamic parts of the page. A nonce-based Content Security Policy gives each response a random value that every inline script has to carry, or the browser blocks it. The pull request, a clean cherry-pick of canary's #100102, makes Turbopack's shared-runtime bootstrap part of the resume, so it receives the nonce. If you send a nonce from proxy.ts and saw blocked inline scripts on PPR pages built with Turbopack, this is the fix.

fast-jwt for Preview Mode cookies

The original pull request (opens in a new tab) gives the reason: jsonwebtoken still uses SlowBuffer, which Node.js 26 removed. In Next.js the library signs and verifies the Preview Mode cookie of the Pages Router (res.setPreviewData). In the diff, the new code signs and verifies with HS256 and your preview signing key, and converts maxAge from seconds to the milliseconds fast-jwt expects. The library is compiled into the package: the npm registry (opens in a new tab) lists the same six runtime dependencies for 16.4.3 and 16.4.4, so nothing new lands in your lockfile.

Is Next.js 16.4.4 a security release?

No, and that is the main thing to know before you plan the week. The release notes open with a note that the release backports bug fixes and that the announced November security release follows the next day. None of the ten advisories on the first page of the Next.js security advisories (opens in a new tab) names 16.4.4; the newest are from 14 October 2026. Here is where 16.4.4 sits in the 16.4 line, with npm's publish times:

Version	On npm (UTC)	What it is	Security fixes
16.4.0	6 Oct 2026, 18:35	Minor release	None; affected by the October advisories
16.4.1	14 Oct 2026, 17:43	Out-of-band security update	Three advisories, two critical
16.4.2	15 Oct 2026, 20:57	Backport patch	None
16.4.3	23 Oct 2026, 13:40	Backport patch	None
16.4.4	2 Nov 2026, 10:49	Backport patch, latest on 3 Nov	None
November security release	Scheduled for 3 Nov 2026	Seven medium vulnerabilities	Versions not announced when we checked

The announcement of 27 October (opens in a new tab) gives the date and the count, says the full advisories come with the release, with impact, affected versions and upgrade instructions, and recommends upgrading to a patched version once it is available. It names no versions. The radar that flagged 16.4.4 marked it as breaking; the release notes list no breaking change, and the npm entry keeps the React peer range at ^18.2.0 || ^19.0.0 and Node.js at >=20.9.0, exactly as 16.4.3.

One timing detail: npm had 16.4.4 at 10:49 UTC, and the GitHub release (opens in a new tab) was created as a draft at 10:14 UTC and published at 16:41 UTC. If your tooling watches GitHub releases, it saw the version about six hours after npm install could get it.

Who is affected and how to tell

Every 16.4.x app can take 16.4.4, but it fixes something you would notice only in these setups:

Your setup	What 16.4.4 changes for you	How to tell
Turbopack production build on 16.4.0 to 16.4.3	Server code is strict again	next build without --webpack; a dependency that misbehaves only after next start
Workaround in next.config.ts for the strict-mode bug	You can remove it	experimental.serverMinification: false, or a package added to serverExternalPackages for it
PPR and a nonce-based CSP, built with Turbopack	The bootstrap script carries the nonce	A script-src 'nonce-…' policy and CSP violations in the console on prerendered pages
Pages Router Preview Mode	Cookies are signed and verified by fast-jwt, with HS256	res.setPreviewData in an API route
next dev with Turbopack	A missed startup CSS update reloads the page	Styles that ignored an edit made right after the dev server started
Next.js 15.x or 16.3.x	Nothing: 16.4.4 is on the 16.4 line	npx next --version

If you are on 16.0.0 to 16.4.0, the more urgent problem is older: your version is in the affected range of the three advisories of 14 October 2026, two of them critical, among them the use cache RCE (opens in a new tab) on 16.0.0 to 16.4.0 and the Server Actions denial of service (opens in a new tab), both patched in 16.4.1. Go to 16.4.4 directly, which carries the 16.4.1 fixes.

How to upgrade from Next.js 16.4.3 to 16.4.4

1. Check the version you run

   Run npx next --version or look up next in your lockfile. Below 16.4.1 you are exposed to the October advisories, so upgrade today whatever you decide about the November release.

2. Install 16.4.4

   Run npm install next@16.4.4 (or pnpm add next@16.4.4, yarn add next@16.4.4). Node.js stays at >=20.9.0 and the React peer range is unchanged, so react and react-dom need no change of their own.

3. Remove the strict-mode workarounds

   If you turned off experimental.serverMinification or added a package to serverExternalPackages only because of issue #100617, remove that setting and check the package after a production build.

4. Build and test what the fixes touch

   Run next build and next start, then load a prerendered page under your real CSP and watch the console for blocked scripts. If you use Preview Mode, enter preview, load a page and exit, once, before you deploy.

5. Plan the November security upgrade

   Watch the Next.js security page (opens in a new tab) for the November release. When its advisories name the patched versions, check whether your app is affected and upgrade to the version they give for your release line.

What to watch out for

• 16.4.4 is not the patched version. Don't close a security ticket with it. When we checked on 3 November, npm's latest was 16.4.4, canary was 16.5.0-canary.38 and neither the advisories nor the security post of the November release were out. Plan for a second upgrade this week.
• A strict CSP without nonces is still open. Issue #100906 (opens in a new tab), filed on 29 October against 16.4.3 and open on 3 November, reports that the Turbopack shared runtime (experimental.turbopackSharedRuntime, on by default per the report) emits an inline bootstrap script with no nonce, which a script-src policy without 'unsafe-inline' blocks. 16.4.4 gives that script the nonce during a PPR resume; it does not move it out of the HTML. The reporter got no inline script with turbopackSharedRuntime: false or a webpack build.
• No breaking change listed. The release notes have none, the npm entry has the same dependencies, peers and engines as 16.4.3, and the revert restores the code format the LTS line used before the optimisation.
• What we did not do. We did not build an app on 16.4.4. Every claim here comes from the release notes, the pull requests and issues they link, the npm registry and the Next.js blog, all read on 3 November 2026.

Further reading