Next.js 16.4.1 fixes two bugs that let attackers run code

Next.js shipped patched releases on October 14 that close two critical remote code execution bugs and one denial of service. The Next.js security post, from Vercel, the company that maintains the framework, gives the fixed versions as 16.4.1 on the Active LTS line and 15.5.28 on Maintenance LTS. Two of the three fixes were held back from the September release while upstream dependencies caught up.

The worst of the three needs nothing from an attacker but a request. An App Router application using Cache Components can be driven into unauthenticated remote code execution when a use cache function returns multiple typed arrays, and the post says there is no known workaround. It also tells teams to upgrade even if their own code has no function that looks like that, which is worth following literally. The related advisory it cites is against React, so the vulnerable path most likely sits below application code.

The second critical bug is the one in an SEO’s territory. The Image Optimization API, the service behind next/image that resizes and re-encodes images on request, can reach remote code execution through an SVG, by way of a memory bug in sharp, the image library Next.js leans on underneath. It is tracked as CVE-2026-96889 and only applies when Next.js runs on glibc-based Linux. For anyone who cannot ship a framework upgrade today, the stated workaround is to make sure the sharp version Next.js resolves to is 0.35.5 or later. Upgrading Next.js does that anyway, because the patched releases let package managers hand it a fixed sharp.

The denial of service is the one that will surface in reporting before anyone reads a changelog. Crafted requests against an App Router application with at least one Server Action can run CPU usage high enough that the process stops handling anything else. Pages Router applications, and App Router applications with no Server Actions, are not vulnerable.

Vercel’s post treats that as an availability problem and says nothing about search. A process pinned at full CPU cannot answer Googlebot any more than it can answer a customer, so a sustained version of this reads as timeouts and server errors across every template at once rather than as a problem with particular pages. The useful response during an incident is the one Google documents for overloaded servers: have the load balancer or CDN in front of the app return a 503 with a Retry-After header when the process stops answering, instead of letting requests hang until they time out.

What to do

Patch first, then work out what you were exposed to.

npm install next@16.4.1   # 16.4 line
npm install next@15.5.28  # 15.5 line
npm ls sharp              # expect 0.35.5 or later

• Confirm sharp separately. npm ls sharp can report a version held down by your own dependencies or by a lockfile the Next.js upgrade did not move, and if it comes back below 0.35.5 it needs raising explicitly.
• Find out whether you have Server Actions at all. One "use server" directive anywhere in an App Router build puts the denial of service in scope, and a team that added one for a contact form a year ago will not remember it.
• Watch your 5xx and timeout rate for the next few days. Crawl Stats updates slowly, so server logs or your host’s metrics will show a CPU-exhaustion attack well before Search Console does.