Next.js August 2026 flaws: who patched on your behalf

Two unauthenticated remote code execution flaws in Next.js, fixed on 25 August 2026. Short answer: if your site runs on Vercel or Netlify, you probably have nothing to do. It was handled before you woke up.

If you run your own server, nobody did anything for you.

That gap is what makes this week worth reading about, far more than the word "critical".

In this article#

• What happened, in order
• The two flaws, in plain terms
• The real story: your host patched overnight
• Why it could
• The fifteen minutes to spend if you host it yourself
• This will happen again, and more often
• The three questions that cost the most
• What not to overplay

What happened, in order#

The second flaw did not come from Next.js. It came from an upstream dependency, and it is what pulled the date forward.

The two flaws, in plain terms#

A booby-trapped image that takes over the server#

The origin is not in Next.js. It sits in libheif, the library that decodes the AVIF format. libheif is used by sharp, which is used by next/image. Three links in a chain, and you picked none of them.

The defect is a heap overflow in the scale_nearest_neighbor() function. The code reserves memory sized for 8-bit samples, then writes 16-bit samples into it through a different path. On a 128 by 128 pixel image, that means writing 32,768 bytes into a 16,384 byte space. The rest spills over.

No exotic manoeuvre is needed. Your server simply has to decode the image.

Note what the fix actually is: Next.js does not repair the flaw, it switches the feature off. That is the right reflex when the defect belongs to someone else, and it means your AVIF images will no longer be resized until the whole chain catches up.

A badly filtered file path, on Windows only#

The second one, CVE-2026-75604, is a path traversal. It needs three conditions at once: an application using both the Pages Router and the App Router, without Cache Components, on a Windows server.

The real story: your host patched overnight#

Here is the part almost nobody covered, and it is the most useful.

The Fastly case deserves attention: the patch exists, but you have to flip it to Enabled by hand in the console. A patch sitting disabled protects nobody.

Vercel states plainly that no upgrade, no configuration change and no redeploy is required for applications hosted there. Netlify says the same, and still recommends upgrading.

Rule of thumb. It was not your framework that protected you, it was your host. If you do not have a host in the sense used here, you had no protection.

Why it could#

This is the mechanism, and it is new. On 13 July 2026, Next.js formalised a monthly security release programme with advance notice before each release. The announcement gives the reason on the next line: that lead time also lets them coordinate with hosting providers and platform partners, so those partners can deploy firewall rules that protect applications not yet patched.

So the 20 August notice handed Vercel, Netlify, Cloudflare and Fastly a five-day head start.

Five days you did not get, because nobody told you. Unless you read the Next.js blog on a Thursday.

The fifteen minutes to spend if you host it yourself#

A VPS, a Docker container at a client's, a Coolify, a Dokploy, a machine in a cupboard. In every one of those cases, you are the host.

npm ls next

npm install next@16.3.3   # branch 16, active support
npm install next@15.5.24  # branch 15, maintenance

Fifteen minutes per project. The difficulty is not the problem. The number of projects is.

This will happen again, and more often#

Moving to a monthly rhythm is not an organisational whim. Next.js writes the reason into its July announcement: the volume of vulnerability research across the industry is rising fast, driven by LLM-assisted discovery.

The figure they quote is the right marker: Mozilla disclosed 271 issues in a single Firefox release, all surfaced by an AI tool. Vercel runs the same class of tooling against Next.js, under the name deepsec, on top of its bug bounty.

That is good news at heart. These flaws already existed, they are simply found earlier and by the right people. It is bad news for your calendar.

Rule of thumb. The question is no longer whether there will be a flaw. It is how long sits between the advisory going public and your npm install.

The three questions that cost the most#

The technical part takes fifteen minutes. The rest does not.

1. How many projects do you run self-hosted, and which of them accept images uploaded by visitors? If you cannot answer in thirty seconds, the list does not exist, and building it is the first job.

2. Who receives the alert when an advisory lands, and is that person allowed to deploy on a Friday? An alert arriving in a mailbox nobody reads is worth nothing. So is a fix waiting for Monday morning.

3. A security patch on a project delivered eight months ago: billed, included, or done for free at 11 p.m.? This is the question people discuss least, and it is the one that costs freelancers and small studios the most.

All three models exist and all three can be defended. The maintenance retainer, where the client pays a fixed amount and you cover this kind of event. Per-incident billing, at a rate written down before it happens. And the goodwill gesture, which works beautifully until fourteen projects need the same gesture on the same evening.

What cannot be defended is not having decided. Because the default answer is you, at 11 p.m., for free.

Our answers, since we asked the questions#

Asking those three questions without answering them would be a little easy.

Every project we have shipped runs on Vercel or Netlify. On 25 August we had strictly nothing to do. That is not merit, it is a hosting choice made upfront, and it just paid for itself. The flip side is real and you know it: you depend on a platform and on its pricing.

The first month after delivery is included, security patches with it. After that it is a monthly retainer of 50 to 200 € depending on the project, more if the application is large and needs real attention. The price is written into the quote, before we start.

On a critical flaw, the commitment is 24 hours, weekends included. Not 48 business hours, not "as soon as we can". A flaw published on a Saturday gets fixed on the Saturday.

Monitoring runs on GitHub advisories for the repositories, and on reading the announcements at the source. That is what caught the 20 August notice. It is not a perfect system, and we are in the middle of strengthening it, otherwise this article would not exist.

And the usual refusal: if you have a developer in house, a retainer with us is worth nothing. They will run that npm install faster and better, because they live in your code all week.

What not to overplay#

Two clarifications, because this subject invites hype.

At the time of publication, no exploitation in the wild was confirmed, and no public proof of concept was circulating for the Next.js side. The libheif advisory does contain enough to reproduce the defect, which is one more reason to upgrade quickly, not a reason to panic.

And treat exposure figures with care. The millions of weekly npm downloads you will see quoted measure how popular a package is, not how many applications are vulnerable. It is not a victim count.

What to take away#

If you sit on a large host, this week cost you nothing, and that is a fair reason to stay there. If you run your own server, you just found out the real price of that independence, and it is paid in quarter hours, not in euros.

Neither position is the wrong one. The wrong position is believing you are in the first when you are in the second.

Frequently asked questions#

On the same topic#

• Next.js 16.3: what actually changes for your site
• Beyond no-code: when Zapier and Make are not enough
• Two quotes 40 % apart: how to actually compare them