Patched Next.js in September? You're Still Exposed (16.4.1, 2026)

If you upgraded Next.js to 16.3.8 after the September 30 advisories, you did the right thing, and you're still exposed. Two weeks later, on 2026-10-14, Next.js shipped an out-of-band update for a critical unauthenticated RCE and a high-severity DoS. Both affect 16.3.8. And there is no 16.3.9: we checked the npm registry on 2026-10-28, and the 16.3 line ends at 16.3.8.

The fix is 16.4.1, a minor-version jump. Teams that only take patch releases will skip right past it.

What shipped, and when

Next.js split this into two releases because, in its own words, two fixes were "postponed from the September security release due to upstream dependency delays." The October 14 announcement lists three issues:

The first two have no CVE ID on their advisory pages as of this writing, so search for them by GHSA ID. The Next.js announcement links each one to an upstream React advisory (GHSA-xqc2-xf4c-x3h3 and GHSA-h3gv-c5rc-p453).

Here's the release timeline from the npm registry, because it explains the trap:

Note 16.4.0. It shipped eight days before the fix, so if someone upgraded you to "the latest minor" in early October, that doesn't count either.

Which bug actually reaches your app

The RCE needs a specific shape, and the advisory says upgrade anyway

The RCE needs App Router with Cache Components, plus a use cache function that returns multiple typed arrays (Uint8Array, Float32Array and friends). That's a narrow pattern. Most apps don't return binary buffers from cached functions.

The advisory doesn't let you off the hook on that basis, though: "You should upgrade immediately even if your application does not have similar functions." Take that seriously. "We don't have that pattern" is a claim about every file in a codebase you didn't write line by line, and it needs to hold for every future AI edit too.

The DoS reaches almost every AI-built App Router app

The Server Actions bug has a much lower bar. You need App Router and at least one Server Action. That's it. No auth needed, and a crafted request "can lead to excessive CPU usage" that "blocks processing of further requests in the same process."

This is the one that matters for most of our readers. When you ask Cursor, v0, Bolt or Claude Code to build a contact form, a settings page or a waitlist signup in a Next.js App Router project, the idiomatic answer is a Server Action: a function marked "use server" that the form posts to. If your app has a single form like that, it's in scope. Pages Router apps, and App Router apps with zero Server Actions, are not.

The two-minute check

npm ls next      # or: pnpm why next / yarn why next

# Server Actions: any hit means the DoS applies
grep -rlnE "[\"']use server[\"']" . \
  --include=*.{ts,tsx,js,jsx,mjs} --exclude-dir={node_modules,.next}

# use cache functions: review each hit for typed-array returns
grep -rnE "[\"']use cache[\"']" . \
  --include=*.{ts,tsx,js,jsx,mjs} --exclude-dir={node_modules,.next}

npm install next@16.4.3      # or next@15.5.28 if you're on the 15 line
npm ls next                  # confirm the lockfile moved
npm run build

Why this one slips through

Three habits stack up here.

Exact pins. create-next-app writes an exact version ("next": "16.3.8"), not ^16.3.8. Dependabot or Renovate will open a PR for 16.4.1, but npm update on its own won't move you, and plenty of AI-built projects have no update bot at all.

Patch-only policies. If your rule is "take patch releases automatically, review minors," this fix falls on the wrong side of it. That's not a mistake in the rule. It's just worth knowing the September and October fixes landed on different minors.

"I already patched this month." The September advisories got a lot of coverage. It's very natural to see "Next.js security update" in October and assume it's the one you already handled.

What CheckYourVibe sees here

Our scanner works from the outside, the way an attacker would. It can tell a site runs Next.js, and it flags the client-side problems these apps usually ship with: keys in the bundle, missing headers, exposed source maps. It can't prove whether a particular Server Action is reachable or whether a use cache function returns typed arrays, because that lives in server code.

So this one is a lockfile check, not a scan finding. Run step 1 above. If the version is in range, upgrade, and then run a scan to catch the things a framework upgrade doesn't fix.