Next.js 16.4.1 and 15.5.28 fix two critical remote code execution flaws. For one of them there is no workaround.
Two of the three fixes were postponed from September. Here is what each flaw needs in order to be reachable, the one workaround that exists, and what the announcement leaves out.
- Released
- 14 October 2026, out of band
- Patched versions
- 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS)
- Critical
- Unauthenticated RCE in use cache functions that return typed arrays, GHSA-673q-mjm6-r5xr
- Critical
- RCE in the Image Optimization API with SVG, CVE-2026-96889, GHSA-2464-fhr4-w9xw
- High
- Denial of service in App Router with Server Actions, GHSA-p3m5-59mp-jv5r
- Workarounds
- None for the use cache flaw. sharp 0.35.5 or later for the image flaw
- 16.3 line
- Post names no 16.3 patch, and npm lists nothing after 16.3.8
Three flaws, two of them critical
Vercel published an out of band Next.js security update on 14 October, a week after announcing it. The announcement said it would address three vulnerabilities in upstream dependencies, two critical and one high, and that two of the fixes had been postponed from the September security release "due to upstream coordination". The patched versions are 16.4.1 on the Active LTS line and 15.5.28 on Maintenance LTS.
If you read our coverage of the September release, this is the follow up we flagged: one critical and one high were left open then, with no version or date. The update announced here contains three fixes in total, so it is not simply those two, and the post does not say which of the three were the postponed ones.
The flaw with no workaround
GHSA-673q-mjm6-r5xr is rated critical. The post describes it as a vulnerability in applications using App Router with Cache Components that can lead to unauthenticated remote code execution when a use cache function returns multiple typed arrays. It also lists a related upstream advisory in React, GHSA-xqc2-xf4c-x3h3.
The sentence that matters is the next one: "There is no known workaround for affected applications. You should upgrade immediately even if your application does not have similar functions." Read that second clause as an instruction to stop analysing exposure and patch. You can spend an afternoon working out whether any of your cached functions returns typed arrays, but the post does not ask you to.
The image flaw and the sharp workaround
CVE-2026-96889 (GHSA-2464-fhr4-w9xw) is also rated critical. The post calls it a memory related vulnerability in an upstream library used for Image Optimization, which can lead to remote code execution when Next.js runs on glibc based Linux and the image is an SVG.
This is the one with a stopgap. The post says: "As a workaround, ensure the version of sharp used by Next.js is 0.35.5 or later." It adds that upgrading Next.js to the patched versions makes package managers provide a fixed version of sharp automatically. So if you cannot deploy a new Next.js today, check what sharp resolves to in your lockfile.
One catch is visible in the package metadata. next@15.5.28 declares its optional sharp dependency as ^0.34.3 || ^0.35.5, and next@16.4.1 declares ^0.35.5. A project with a lockfile already pinned to sharp 0.34.x satisfies the 15.5.28 range, so a package manager can leave it there after you upgrade Next.js. The post says the upgrade provides a fixed sharp automatically, which holds for a fresh install but not necessarily for an existing lockfile. We hit this ourselves: after bumping to 15.5.28 our lockfile still resolved sharp 0.34.5 until we pinned it.
The scoping here is by platform, not by router. The post names glibc based Linux, so the base image of your container is part of the answer. We have not tested which common images use glibc and which do not, so check yours rather than assuming.
The denial of service
GHSA-p3m5-59mp-jv5r is rated high. Crafted requests targeting an application using App Router with at least one Server Action can lead to excessive CPU usage, and the post says that CPU usage "blocks processing of further requests in the same process". Applications using Pages Router, or not using Server Actions, are not vulnerable. A related React advisory, GHSA-h3gv-c5rc-p453, is linked.
What the announcement does not say
There are no affected version ranges in the post. They are in the three GitHub advisories it links, and we have not reproduced them here. The post also names only 16.4.1 and 15.5.28. As of 15 October npm lists no 16.3 release after 16.3.8, so a team on 16.3 should read that as a move to 16.4.1 rather than waiting for a 16.3 patch.
Only the image flaw has a CVE number in the post. The other two are identified by their GitHub advisory ids, so a scanner keyed to CVEs may not flag them yet.
What to do
- 1Upgrade to next@16.4.1 on the 16.x line, or next@15.5.28 on 15.5. If you are on 16.3, move to 16.4.1.
- 2Do not wait to decide whether you use use cache with typed arrays. The post says to upgrade regardless.
- 3Confirm sharp resolves to 0.35.5 or later in your lockfile, and pin it explicitly if it does not, for example with a pnpm override. Note which libc your container image uses.
- 4Redeploy preview and branch deployments, which keep serving the build they were created from.
- 5Read the three linked advisories for the affected ranges, and add the GHSA ids to your tracker since two have no CVE.
Common questions
Which Next.js versions fix these flaws?
The post names 16.4.1 on the Active LTS line and 15.5.28 on the Maintenance LTS line. It names no patched 16.3 release, and npm lists nothing after 16.3.8 on that line as of 15 October.
Is there a workaround?
For the use cache flaw the post says there is none. For the Image Optimization flaw the workaround is to make sure the version of sharp used by Next.js is 0.35.5 or later. The denial of service has no workaround listed.
Does the Pages Router protect me?
For the denial of service, yes: the post says applications using Pages Router or not using Server Actions are not vulnerable. For the use cache flaw it scopes exposure to App Router with Cache Components. For the image flaw it scopes by platform, glibc based Linux, rather than by router.
Why were two of the fixes late?
The pre-announcement says they were postponed from the September security release due to upstream coordination, meaning the fixes depend on upstream libraries.
Sources
- Next.js: security update for upstream vulnerabilities, 14 October 2026
- Next.js: upcoming security update announcement
Read against the primary documentation rather than secondary coverage. Where a figure comes from a provider's own docs, it is quoted as published on 2026-10-15.
Related
More from Signals
Open the tool.
Ten production categories, three minutes, and a ranked list of what to fix first.
Check your own stack