Andy Garcia · freelance dev
FRENES
Back to the blog
Security

Next.js Shipped Two More Critical RCE Fixes on October 14. One Hits the Model It Now Recommends

October 19, 2026 7 min read

On Wednesday, October 14, 2026, the Next.js team published an out-of-band security update: Next.js 16.4.1 on the Active LTS line and 15.5.28 on the Maintenance LTS line. It fixes two Critical vulnerabilities, both unauthenticated remote code execution, and one High-severity denial of service. The team had announced it on October 8 and said two of the three fixes had been postponed from the September 30 security release "due to upstream coordination."

I already wrote about the August 25 emergency patch. This one deserves its own read, for two reasons. The delay says something about who controls a framework's security calendar now. And on the 16.x line, the fix only exists in 16.4, the minor release that on October 6 began recommending Cache Components "as the best choice for every Next.js app." I run Next.js in production, so here is how I read both, and what I would do with an existing app.

Why the fixes came in a second wave

The timeline is all on the Next.js blog. On September 23, the team announced a scheduled release for September 30. On September 30, a note added to that announcement changed the count: the release "now addresses seven vulnerabilities instead of nine," and the remaining two, one Critical and one High, were "pending upstream coordination." The September release shipped as 16.3.8 and 15.5.27. On October 8 came the notice for October 14.

The October 8 notice never names the upstream. The October 14 post and the advisories do. Two of the three October advisories have a twin in React's own repository. The remote code execution in use cache functions (GHSA-673q-mjm6-r5xr) points to GHSA-xqc2-xf4c-x3h3, "Unauthenticated Remote Code Execution in React Server Components." The Server Actions denial of service points to GHSA-h3gv-c5rc-p453. Both affect the react-server-dom packages for webpack, Turbopack and Parcel, and React backported the fixes to four release lines: 19.0.9, 19.1.10, 19.2.9 and 19.3.1. The third bug sits in "an upstream library used for Image Optimization," and its workaround is sharp 0.35.5 or later.

The npm registry shows the choreography. React's four patched releases of react-server-dom-webpack appeared between 16:49 and 16:55 UTC on October 14. Next.js 15.5.28 followed at 17:36, and 16.4.1 at 17:43. Four React lines and two Next.js lines in under an hour.

Next.js does not say which upstream caused the wait, or which of the two Critical bugs was the postponed one. One thing follows by elimination: September held back one Critical and one High, and October has a single High. So the Server Actions denial of service shipped 14 days after the release it was meant for.

That is the practical lesson. When a bug lives in a shared layer like React Server Components, a framework cannot ship alone. Its date becomes the date of the slowest coordinated release. For anyone who runs Next.js, the "upcoming security update" posts are the real signal: the October 8 notice gave six days to book an upgrade slot.

What is exposed, and the detail in the lockfile

The use cache bug (CVSS 9.5) affects 16.0.0 through 16.4.0, in App Router apps with Cache Components, when a use cache function returns multiple typed arrays. There is no workaround, and the advisory says to upgrade "even if your application does not have similar functions." The first patched version is 16.4.1. There is no 16.3.9 on npm. If you stayed on 16.3.8 after September, the security fix now comes with a minor upgrade: React 19.3, Turbopack changes, new APIs.

The image bug, CVE-2026-96889 (also 9.5 in the Next.js advisory), applies when Next.js runs on glibc-based Linux. sharp's own advisory places the flaw in librsvg, which sharp's prebuilt binaries bundle, so the workaround is a sharp version. Here is the detail that is easy to miss. Next.js 16.4.1 declares sharp as ^0.35.5, so the upgrade forces a fixed version. Next.js 15.5.28 declares ^0.34.3 || ^0.35.5. A 15.5 app whose lockfile already resolves sharp 0.34.x satisfies that range and keeps it after the upgrade. The Next.js advisory names 0.35.5 as the floor, and sharp's advisory for the same CVE lists every version below 0.35.5 as vulnerable: there is no fixed 0.34.x. On 15.5, I would check which sharp the lockfile actually resolves, not just the Next.js version. sharp 0.35.5 has been on npm since September 27, and sharp published its advisory on September 30, two weeks before Next.js published its own.

The denial of service (CVSS 8.2) hits App Router apps with at least one Server Action, from 13.0.0 on. Pages Router apps and apps without Server Actions are not affected. No workaround besides upgrading. Like the image bug, which goes back to 10.0.0, it has no fix below 15.5.28: an app still on 13.x or 14.x has to change major to get it.

Cache Components now has a security record

Put the two releases side by side. The September 30 release had seven advisories, two of them in use cache: a cache key that could leak content across root param values, and a pending cache fill that could leak Draft Mode content into regular responses and persisted pages. Both Medium. October 14 added the Critical one. Three of ten advisories across two releases touch the directive at the center of the model Next.js now recommends.

I do not read that as a reason to avoid Cache Components. New code paths are where researchers look, and this is a young model getting a lot of attention. I read it as a cost of adoption: if you turn it on, your patch cadence has to be tighter than before.

Here is the reassuring part. Upgrading to 16.4.1 does not turn Cache Components on. The 16.4 post says you use the model "by enabling two flags," cacheComponents and partialPrefetching. Only new apps from create-next-app get it by default. The patch and the migration are two separate decisions.

What the migration actually changes

The 16.4 post says Cache Components "will become the default in Next.js 17" and gives no date for 17. The migration guide is where the cost lives:

  • The route segment configs dynamic, revalidate and fetchCache error once the flag is on, and exporting dynamicParams fails the build.
  • use cache defaults to in-memory storage: entries are discarded when a serverless instance is destroyed, and they are scoped to a single deployment. The old fetch Data Cache and unstable_cache persist across deployments and serverless instances. use cache: remote or a cache handler survives instance teardown, but even with durable storage the guide says to expect cached values to recompute after a new deployment. That is a line on the hosting bill, not just a refactor.
  • Component state now survives navigation. Forms keep their values and dropdowns stay open, because routes are hidden with React's Activity instead of unmounted.
  • generateStaticParams returning an empty array now errors.
  • new Date(), Math.random() and crypto.randomUUID() during prerender fail the build, even on routes opted out with instant = false.
  • It requires Next.js 16.

None of that is exotic. All of it is work.

The 15.x clock

The Next.js support policy says each major stays in Maintenance LTS "for two years following the initial release." Next.js 15 was released on October 21, 2024. By the policy's own arithmetic, its window ends on October 21, 2026. The page lists no end date, and it keeps a clause for patching versions outside the policy "in rare circumstances." I would still plan as if 15.5.28 could be among the last routine fixes for that line. And because Cache Components requires 16, a 15.x app faces two upgrades, not one.

What I would do

Patch first, alone. 16.x goes to 16.4.1 or later, 15.5 goes to 15.5.28. One pull request with nothing else in it, so a rollback stays a rollback. Then confirm sharp at 0.35.5 or later, in the lockfile and on the deployed build.

If Cache Components is already on in production, list every use cache function. You were in scope for the Critical bug and, if you serve Draft Mode previews, for one of the September ones.

On 15.x, schedule the move to 16 now, as its own project.

For the migration, use a branch and the incremental path the guide describes: the cache-components-instant-false codemod opts every route out of validation, you fix synchronous IO (the one thing the opt-out does not defer), then you convert routes one at a time. Before merging, deploy twice and watch how the cache behaves after the second deploy, and click through every form you have.

I orchestrate my work with Claude Code, so next upgrade --agent and the Cache Components adoption skill are aimed at people like me. The command prepares migration guides, codemods and verification steps for the agent. What I would check before letting an agent run it: that the security bump and the migration land in separate pull requests, that the resolved sharp version is right, and that verification includes a real deploy, not only a local build. 16.4 also adds experimental.agentUpgrade, whose default policy, 'security', reminds you during next dev and next build about upgrades that fix known vulnerabilities in your installed version. I would leave it on.

The patch is a version bump. The migration changes how your app caches, renders and bills. Next.js 17 will decide the default. You still decide the order.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk