Next.js Shipped Two Critical Unauthenticated RCEs in August. Are You Affected?

On August 25, 2026, the Next.js team shipped 15.5.24 and 16.3.3 to fix two critical severity vulnerabilities. Both are unauthenticated remote code execution. One scored 9.0, the other 9.5. No login, no user interaction, no clicking a link.

Then the security roundups did what security roundups do, and half the internet decided every Next.js site on earth was on fire. Search for the Next.js CVE August 2026 coverage and you will find twenty posts telling you to patch immediately and roughly none telling you whether you are actually in scope.

They aren't. One of the two only affects servers running on a Windows filesystem, which excludes essentially every Docker container, every Linux VPS, and every serverless runtime I have ever deployed a client site to. The other one is broader, and that is the one worth your afternoon.

I run Next.js and Astro sites for clients out of a one-person shop in Augsburg. I deploy through Docker and Coolify, with Directus backends behind most of them. So this landed on my own to-do list, not as an abstract news item. Here is what actually shipped, who is genuinely exposed, and how to check yourself in about five minutes.

What Actually Shipped on August 25

The Next.js CVE August 2026 release is two advisories, both marked critical, both patched together.

The first is CVE-2026-75604, CVSS 9.0, a path traversal that leads to unauthenticated RCE on Windows-hosted servers. Affected ranges are >= 13.4 < 15.5.24 and >= 16.0 < 16.3.3. That is a wide version window, going back to Next.js 13.4.

The second has no CVE assigned yet. It is tracked as GHSA-2xp9-vwfh-vxw4 on the Next.js side and GHSA-g89c-p67h-r497 upstream, and it scores 9.5 under CVSS v4.0. It is a heap overflow in libheif, the C library that sharp uses to decode AVIF, and sharp is what Next.js uses for image optimization. Affected ranges are >= 10.0.0 < 15.5.24 and anything below 16.3.3. So: almost every Next.js version ever published.

The fixed versions are 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS). Two commands:

npm install next@15.5.24  # for the 15.5 line
npm install next@16.3.3   # for the 16.3 line

Worth noting what the AVIF fix actually does. Next.js did not fix libheif, because that is not their code. The patched releases disable AVIF optimization entirely until the upstream fix propagates. AVIF images get served as-is, unresized. That is a real behaviour change, and if your LCP image is a large AVIF you should expect it to get heavier after you patch. Ship the patch anyway.

Also worth noting what has not happened: as of writing, there is no confirmed exploitation in the wild and no public proof of concept for either issue. That is not a reason to skip the update. It is a reason to do it calmly instead of at 2am.

The Windows One Is Real, but It Is Narrow

CVE-2026-75604 needs three things at once. Your app uses the Pages Router or the App Router without Cache Components, and the Next.js server is running on a Windows filesystem.

The advisory is blunt about the boundary: Linux and macOS are not affected. The mechanism is why. Percent-encoded backslash sequences reach the routing layer without being normalised, and on Windows a backslash is a directory separator. So the traversal only resolves into something dangerous on a filesystem that treats \ as a path boundary. Attackers can walk out of the build cache directory and read private build data, including the server-reference-manifest encryption key, and from that key you get to code execution.

The CVSS vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. Note the AC:H, attack complexity high. This is not a one-line curl.

If you deploy through Docker on a Linux base image, you are not affected. If you run on a Linux VPS, not affected. Vercel's runtime is Linux. Netlify Functions and Edge Functions run on Linux. That covers most of the industry.

If you are one of the shops running Next.js on IIS or a Windows Server box behind a .NET stack, and those shops exist, this one is yours and there is no workaround. The advisory says so explicitly. Upgrade, or move the app to Linux.

The AVIF One Is the Broader Problem

This is the one I actually stopped what I was doing for. It is not OS-specific, the affected range goes back to Next.js 10, and the trigger is an image.

The path is: someone gets a crafted AVIF file into your image optimization pipeline, sharp hands it to libheif to decode, libheif overflows a heap buffer, and the attacker gets code execution in your Next.js process. No auth needed.

The question that determines whether you care is simple: can an attacker choose what your /_next/image endpoint decodes?

Two ways they usually can. First, if your next.config has permissive remotePatterns that allow a broad range of hosts, an attacker can host the crafted file themselves and hit /_next/image?url=<their-url>. Second, if your app accepts user uploads and runs them back through the optimizer, they do not even need an external host.

If every image your optimizer touches is a build-time local asset in /public or imported from your repo, the attack surface is much narrower, because the attacker has to get their file into your repo first. Narrower is not zero, and I would not treat it as a pass. But it is a meaningfully different risk profile from a site with wide-open remotePatterns and a user avatar upload.

Two configurations take you out of it entirely. If you have images: { unoptimized: true }, there is no optimizer running. If you are on output: 'export' and shipping a fully static build, there is no server-side image endpoint to attack at all. Static exports are not in scope here, and neither are Astro sites that never run sharp at request time.

July Was Nine CVEs, and Almost Nobody Noticed

August did not come out of nowhere. On July 21, 2026, Next.js published its first scheduled security release: nine CVEs, four high and five medium, patched in 16.2.11 and 15.5.21.

Two of them are directly relevant to how most client sites are built.

CVE-2026-64645 (High) is SSRF in rewrites() and redirects(). If a rule builds its external destination hostname from request-controlled input, an attacker can point it at any hostname they like, regardless of the suffix the rule declares. For a rewrite, your server proxies to their host and returns the response through your origin. For a redirect, you get an open redirect. Affected versions run 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10. If your next.config has a rewrite with a dynamic destination host, read this one properly.

CVE-2026-64643 (Medium) is unauthenticated disclosure of internal Server Function endpoints. In App Router apps, Server Action and use cache endpoint IDs can be globally disclosed. The leak itself is opaque internal identifiers, not credentials and not PII. It is reconnaissance material for a longer chain, not a breach on its own. Medium is the right rating, and anyone selling it to you as critical is selling something.

The rest of that release is worth a skim: a DoS in App Router apps with any Server Action (CVE-2026-64641), a middleware bypass for Turbopack builds with a single i18n.locales entry (CVE-2026-64642, and a middleware bypass means your auth checks get skipped), and two separate fetch cache confusion bugs.

Notice the pattern in the preconditions. Turbopack plus exactly one locale. A rewrite with a dynamic host. Windows filesystem. These are conditional bugs, and knowing which condition applies to you is the entire job.

Your Host May Have Already Handled Part of This

This is the part the news coverage skipped, and it changes the urgency a lot.

Vercel stated that applications hosted there are protected, with no upgrades, config changes, or redeploys required. They disabled AVIF optimization across their managed Image Optimization service, and their Next.js runtime is Linux, so the Windows path traversal never applies.

Netlify said the same for both. Windows RCE does not apply because Functions and Edge Functions run on Linux. The image issue does not apply because image requests route to Netlify's own CDN rather than the Next.js optimization API. They still recommend upgrading and redeploying, which is the right advice.

Cloudflare shipped an emergency WAF release on August 26 that updated an existing Next.js RCE rule to catch CVE-2026-75604 and added a new rule for the AVIF image optimizer path. A WAF rule is mitigation, not a fix. It buys you time; it does not patch your dependency.

Self-hosted is the exposed category. If you build your own container and run it on your own box, nobody disabled anything on your behalf and no CDN is intercepting your /_next/image requests. That is where I live, and that is where I checked first. If you are running your own infrastructure, this is the same class of problem I wrote about in The 6 Things That Actually Break on Websites Nobody Maintains: the failure is never the framework, it is the year of nobody touching it.

The Five-Minute Check

Actual steps, in order.

1. Find your real version. Not what package.json says with a caret in front of it. What is installed:

npm ls next

Or read the lockfile directly. A "next": "^15.5.4" in package.json tells you nothing about what shipped in your last build.

2. Check your host OS. If your Dockerfile starts FROM node:22-alpine or any Linux base, CVE-2026-75604 is off your list. If you cannot answer this question about a client project, that is its own finding.

3. Check your image config. Open next.config.js or next.config.ts and look at images. Is unoptimized: true set? Is output: 'export' set? Are there remotePatterns, and how permissive are they? A hostname: '**' in there is worth fixing independently of any CVE.

4. Check your rewrites. Any rewrites() or redirects() rule where the destination host comes from a request parameter is the CVE-2026-64645 shape. Static destinations are fine.

5. Update. Both August fixes are patch releases on a minor, so npm install next@16.3.3 or npm install next@15.5.24 should be uneventful. Run your build, run your tests, deploy to staging first if you have one. Then check that your images still render, because AVIF optimization is now off and that path has changed.

6. Set up something that tells you next time. Dependabot, Renovate, or npm audit in CI. Any of them. The reason I found out about this release the day it happened is that I subscribe to the Next.js blog, not because I am diligent. Automate it, because you will not stay diligent.

If you want the wider version of steps 3 through 6, I put it in The Website Security Hardening Checklist (No Plugins, No BS).

What to Do With a Client Site Pinned to Next 13

This is the awkward one, and it is the situation most people inherit rather than create.

Patches land in the Active LTS and Maintenance LTS lines only. Right now that is 16.x and 15.5.x. If a site is sitting on Next.js 13.4, there is no patch release coming for it. The affected range for CVE-2026-75604 starts at 13.4, and the AVIF range starts at 10.0.0, so an old pin is squarely in scope for both.

You have three honest options.

Upgrade across majors. This is real work: 13 to 14 to 15 to 16, App Router changes, next/image API changes, async request APIs in 15. Budget days, not hours. It is still usually the right call.

Reduce the surface instead. If the site is a brochure site, output: 'export' plus images: { unoptimized: true } removes the image optimizer from the equation entirely. It does not fix the framework, it removes the endpoint.

Pay for extended support. HeroDevs and similar vendors backport fixes to EOL versions. That is a real budget line, and for a client with a working site and no appetite for a rebuild it is sometimes the cheapest option on the table.

What you do not do is tell the client it is fine. Write down which version, which host OS, which CVEs apply, and what each option costs. Let them decide with real numbers. My framework choice for a given client project usually comes down to who is going to maintain it, which is most of what I was getting at in WordPress, Next.js, or Astro? Here's How I Actually Decide for Client Projects.

So Is Next.js Unsafe?

Fair question. Nine CVEs in July, two criticals in August, a CVSS 10.0 RSC bug in December 2025, and the middleware auth bypass in March 2025 that let anyone skip your auth by setting one header. It looks bad written out like that.

Here is the honest answer, and I do not think it is a comfortable one.

A framework that runs your routing, your rendering, your caching, your image processing, and your server-side data fetching has an enormous attack surface by definition. Next.js also decodes untrusted input at half a dozen boundaries. That is a lot of code touching a lot of hostile bytes.

On top of that, the discovery rate genuinely went up. Vercel says so directly: they moved to a monthly pre-announced release model because vulnerability research volume is rising, driven by LLM-assisted discovery. They run that class of tooling against Next.js themselves, through their own deepsec project and an expanded bug bounty. Mozilla disclosed 271 issues in a single Firefox release from the same kind of tooling. This is not a Next.js phenomenon.

So a rising CVE count is partly a measurement artifact. An actively audited framework with 45 million weekly npm downloads produces more CVEs than an abandoned one. The abandoned one has the bugs too. Nobody is looking.

That is not a full defence. Some of these were avoidable design decisions, and the March 2025 middleware bypass in particular was a bad trust assumption baked into a header. A pre-announced monthly release cadence also means a published window in which attackers know a patch is coming and can go hunting. That is a real trade-off, and the industry has decided the planning benefit wins.

But the risk that actually hurts people is not the framework's CVE count. It is the site that got built in 2023, went live, and has never had npm install run against it since. Every one of these advisories is survivable if you update. None of them are survivable if you never do. The same thing is true of the npm supply chain problem, and of what AI coding assistants pull in without checking. The framework is not the variable. Maintenance is.

Where That Leaves You

The short version of the August 2026 Next.js CVE situation. If you are on Vercel or Netlify, you were covered before you read this, and you should still upgrade and redeploy when convenient.

If you self-host on Linux, the Windows RCE is not yours. The AVIF issue is, and how much it matters depends on whether attacker-controlled images can reach your optimizer. Upgrade to 16.3.3 or 15.5.24 this week and expect your AVIF images to get bigger.

If you self-host on Windows, stop reading and go upgrade. There is no workaround for that one.

And if you have a client site on an old major that nobody has touched in two years, the August CVEs are not the problem. They are the notification.

If you inherited a Next.js site and cannot answer what version it runs, what OS it runs on, or when it was last updated, that is a two-hour audit, not a rebuild. I do them for clients at wunderlandmedia.com, and most of the time the answer is less alarming than the headline suggested.