On 14 October Next.js shipped the security update it had announced the week before. It covers three vulnerabilities: two critical ones, where an attacker can run code on your server without logging in, and one high, which can take your site down.
The fixes are in Next.js 16.4.1 and 15.5.28, according to the official Next.js security post. Two of the fixes were ready for the September release and were held back for upstream coordination.
If your site or webshop runs on Next.js, this is not news to skim. It is a task for this week.
What was fixed
Next.js lists three issues.
The first flaw (GHSA-673q-mjm6-r5xr) affects apps using the App Router with Cache Components. When a use cache function returns multiple typed arrays, an outside attacker can execute code. There is no workaround. Next.js says to upgrade right away, even if you think you have no such function.
The second flaw (CVE-2026-96889) sits in image optimization. An upstream library that sharp uses to process SVGs has a memory bug. When Next.js runs on glibc-based Linux, this can lead to remote code execution. The interim fix is making sure Next.js uses sharp 0.35.5 or later.
The third issue (GHSA-p3m5-59mp-jv5r) is a denial of service. Crafted requests can max out the CPU on apps using the App Router with at least one Server Action. If you use the Pages Router or no Server Actions, you are not affected.
What this means for a regular business site
Many smaller Next.js sites were built once by an agency or freelancer and not touched since. They work, so nobody looks at them. That is exactly the kind of site where a patch like this sits unapplied.
The risk is not small. Unauthenticated remote code execution means that, in the worst case, someone can do on your server whatever your code can do: read data, change your site, use your server for something else. As of 16 October, the official post does not mention active exploitation. I would not wait for that.
Hosting only helps partly. Netlify explains in its own notice that part of the impact is smaller on its platform because images run through its own CDN. It still recommends upgrading and redeploying. I don't assume any host solves this for you.
A security patch is done when the new version is live, not when it is in
package.json.
How I handle it
My own stack runs on Next.js and Vercel, so I go through the same steps.
- Check which Next.js version each project runs (
package.jsonor the deployment details at your host). - Upgrade to 16.4.1 if you are on 16.x, or to 15.5.28 if you are on 15.5.
- Run
npm ls sharpand confirm you are on 0.35.5 or later. The Layman Security, among others, notes that an oldsharpcan stay installed with 15.5.28, so check instead of assuming. - Deploy to a preview or staging first, test the key pages and forms, then go live.
- Rebuild containers or any other environment running the same code.
On a version older than 15.5, the job gets bigger. The official post only names 16.4.1 and 15.5.28 as patched, so older lines need to move to a supported version first.
Where I stay careful
Severity ratings differ by source. Next.js rates the SVG flaw 9.5, others rate it lower. For a small site that hardly matters: upgrading is the fix either way.
I also don't know how many Dutch small business sites are affected. I have no numbers on that and won't make them up. What I do know: every Next.js site without regular maintenance stays exposed until someone picks this up.
Where to start
- List all your Next.js projects and their versions.
- Upgrade to 16.4.1 or 15.5.28 and check
sharp. - Test on a preview and go live.
- Follow the Next.js security posts directly, so you don't depend on a stray social media post.
Running a Next.js site nobody maintains, or not sure which version it runs? Send me a message and we'll check together whether it is patched.