The Next.js July patch only hits your project under six conditions

When an npm audit suddenly lists nine open CVEs for a single package, the first reaction is usually panic. The Next.js release of 20 July 2026 is no exception. Four High, five Medium, numbers running from CVE-2026-64641 to CVE-2026-64649, all published in one go. If you look after several client projects, you end up with the same question on your desk in multiple copies, namely whether this particular project now has a problem or not.

The answer comes down to six conditions. Not to nine separate research sessions. Go through those six once and you know where every project stands.

What was released on 20 July

The blog post on nextjs.org is dated 20 July 2026, with Andrew Imm, Josh Story and Sebastian Silbermann as authors. The actual release went out a day later, Netlify’s changelog carries 21 July, and the OSV entries were published on 22 July. For practical purposes, late July 2026 is close enough.

Photo: sigmund / Unsplash

The fixes ship in two versions, 16.2.11 for the Active LTS branch and 15.5.21 for Maintenance LTS. They are additionally present in 16.3.0-canary.92 and 16.3.0-preview.7 and will come along with stable 16.3.0 in the normal course of things.

# Apply the patch, exactly as given in the Next.js blog
npm install next@15.5.21  # for 15.5
npm install next@16.2.11  # for 16.2

The framework around the release is new as well. On 13 July 2026 Vercel introduced a pre-announced security release model, meaning roughly monthly advance notice on the blog with an expected date and the highest expected severity. It worked for this release. The pre-announcement already named the split of four High and five Medium along with the branches 16.2 and 15.5 before any detail was public. As justification for the cadence Vercel points to the sharply rising stream of findings from LLM-assisted security research, citing Mozilla, which disclosed 271 issues in a single Firefox release, found with Anthropic’s Mythos Preview. Vercel uses its own tooling for this, including deepsec.

Version first, everything else after

Before you check a single vulnerability, work out whether your project can receive a fix at all.

npm ls next
npm why next

If that says 16.x or 15.5.x, the rest of this article is relevant to you. If it says 14.x or 13.x, you have a different problem. Under the support policy 16.x is Active LTS (released 21 October 2025) and 15.x is Maintenance LTS (released 21 October 2024), and Maintenance LTS runs for two years from the initial release, so 15.x runs out on 21 October 2026. Everything older is out. Several of the nine advisories name 12.0.0 or 13.0.0 as the lower bound of the affected range, but the fixes were only released in 15.5.21 and 16.2.11. On 14.x you therefore get confirmation that you are affected and no fix to go with it. At that point the job is migrating to an LTS branch, not applying the patch.

The normal case hits you twice

The condition “App Router with at least one Server Action” is not a niche, it is the normal case for modern Next.js projects. And two items hang off exactly that. CVE-2026-64641 is a denial of service via Server Actions, High, CVSS 4.0 with 8.2, CWE-834 for excessive iteration. Affected are >=13.0.0 <15.5.21 and >=16.0.0 <16.2.11. There is no workaround other than the upgrade. On top of that comes CVE-2026-64643, Medium at 6.3, where internal server function endpoints are exposed without authentication because the endpoint IDs sit in publicly retrievable client artefacts. That affects Server Actions and 'use cache' alike.

Anyone running the Pages Router or without a single Server Action is out of scope on both items. Everyone else has at least two hits, one of them High. So the standard installation does not get away untouched, it merely does not get hit nine times over.

Photo: kellysikkema / Unsplash

The six conditions

The nine CVEs distribute across six classes of condition. This is the list I work through per project.

1. App Router with at least one Server Action. Carries CVE-2026-64641 (High, 8.2) and CVE-2026-64643 (Medium, 6.3). If the action runs in the Edge runtime, CVE-2026-64646 joins them, an unbounded request payload, Medium at 6.3 with CWE-770. As a workaround the advisory names a body limit of around 5 MiB at the host. For context, the default limit for Server Action bodies is 1 MB according to the documentation and is configurable via serverActions.bodySizeLimit.

2. App Router plus a Turbopack build plus exactly one entry in config.i18n.locales. That is CVE-2026-64642, a middleware and proxy bypass, High at 8.3, CWE-285, and exclusively on the 16 branch. This mixed constellation arises easily, because the i18n key in next.config is really the Pages Router internationalisation and tends to linger in projects that moved to the App Router long ago. The advisory only says “built with Turbopack” and does not state whether the production build alone is meant.

3. Self-hosted image optimisation with permitted remote hosts. CVE-2026-64644, a DoS in the Image Optimization API via SVGs, Medium at 6.3. Affected are 15.5.0 through 15.5.20 and 16.0.0 through 16.2.10, but only when self-hosting with the default loader and config.images.remotePatterns set. If you run images.unoptimized: true or loader: 'custom' you are out, and so is Vercel hosting.

4. rewrites or redirects with a dynamically built target hostname. CVE-2026-64645, High at 8.3, reaching back to 12.0.0. As soon as the external target hostname is derived from request input, meaning from dynamic segments in the path or from has capture groups, a rewrite turns into an SSRF and a redirect into an open redirect.

5. Server Actions on a custom server without host pinning. CVE-2026-64649, High at 8.3, affected from 14.1.1. The precondition is that the client can control the host related headers. Managed hosting as well as next start and standalone deployments from 14.2 onwards are protected by default according to the advisory.

6. Two special cases in the fetch cache. CVE-2026-64647 is a cache confusion with bodies containing invalid UTF-8 sequences, Medium at 6.3 and with high attack complexity. Two different UTF-16 byte sequences end up in the same cache entry. CVE-2026-64648 is a second cache confusion that only bites with one particular call form. Both require the App Router.

Five-minute triage

Six checks, that is all it takes.

# 1) Is there any Server Action at all? (CVE-2026-64641, -64643, -64646)
grep -rn "use server" app/ src/ --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx"

# 2) Turbopack and i18n in the same configuration? (CVE-2026-64642, 16.x only)
grep -n "i18n" next.config.*
grep -n "turbopack\|--turbopack" next.config.* package.json

If step 2 produces a hit, count the locales. Only this constellation is vulnerable.

// next.config.js
module.exports = {
  i18n: {
    locales: ['en'],      // exactly ONE entry = affected
    defaultLocale: 'en',
  },
}

Step 3 is a look at the image block. As soon as remotePatterns is set and you host yourself, you are in scope.

module.exports = {
  images: {
    remotePatterns: [{ protocol: 'https', hostname: '**.example.com' }],
  },
}
// not affected: images.unoptimized === true or images.loader === 'custom'

If the upgrade has to wait for some reason, the advisory names a configuration switch for this item.

module.exports = {
  experimental: {
    imgOptSkipMetadata: true,
  },
}

Step 4 is manual work on the rewrites. Anything where part of the hostname comes out of the URL is dangerous.

// vulnerable: target hostname is built from request input
async rewrites() {
  return [{ source: '/api/:region/:path*', destination: 'https://:region.api.example.com/:path*' }]
}
// advisory recommendation: restrict values to hostname-safe characters
// value: '(?<region>[a-z0-9-]+)'

Step 5 concerns only custom servers and deployments without upstream host pinning.

# From 14.2.0 onwards, as a mitigation per the advisory:
export __NEXT_PRIVATE_ORIGIN="https://your-real-domain.com"
# additionally pin Host and X-Forwarded-Host at the proxy

Step 6 is a search for the one fetch form that tips over.

fetch(new Request(init), aDifferentInit)   // affected
fetch(new Request(init), init)             // unremarkable
fetch(url, init)                           // unremarkable, the normal case

Two of the advisories come down to the same recommendation in substance, namely pulling authorisation to the server boundary instead of handling it solely in middleware or at page level.

'use server'

export async function deleteProject(id: string) {
  const session = await getSession()          // check INSIDE the action
  if (!session) throw new Error('Unauthorized')
  // ...
}

What hosting takes care of and what it does not

By its own account Netlify caught three of the nine items at platform level. For CVE-2026-64649 the edge overwrites an incoming X-Forwarded-Host with the real host, for CVE-2026-64644 the Image CDN takes over the /_next/image path, and for CVE-2026-64646 capped request bodies and isolated invocations apply. The remaining six still require the upgrade. For Vercel the advisory on CVE-2026-64644 explicitly states non-affectedness. I have nothing to hand on other platforms, and for your own servers the assumption is simple anyway, nothing is caught there.

Photo: thisisengineering / Unsplash

What I find interesting is how much pure build and deployment decisions shift who is affected. According to advisory GHSA-89xv-2m56-2m9x, standalone and next start deployments from 14.2 onwards are protected by default against the Server Action SSRF, because they pin the host upstream. So anyone who has set output: "standalone" may already have that High item off the table, on the back of a decision that is usually taken for entirely unrelated reasons, such as shrinking the Docker image. Nobody should rely on it without checking their own configuration, though.

What the monthly cadence changes for maintenance

The announced monthly rhythm is the real news for planning. Until now Next.js security fixes arrived without warning, and now there is usually a lead time with a date and a severity level. Vercel explicitly names as one purpose the coordination of mitigations with hosting partners during that window, such as firewall rules for apps that are not yet patched. For you that means a maintenance window on a monthly rhythm becomes something you can plan around rather than a fire drill. Whether a date is already set for August 2026 is open, as nothing was listed on the blog when I closed research on 27 July.

What remains important is that the upgrade itself stays small. A step within an LTS branch, say from 16.2.10 to 16.2.11, is a patch release and not a rebuild. If you update your dependencies automatically anyway, it is worth checking whether your own rules slow such fixes down, because a grace period for new package versions works in the wrong direction for a security patch. How I solved that for myself is in my post on the Dependabot cooldown rule.

Photo: jakewalker / Unsplash

In the end most projects are left with a short list. Check the version, walk the six conditions, lift next to 16.2.11 or 15.5.21, deploy. The effort does not sit in the patch, it sits in the projects on 13.x and 14.x for which there is none.

If you are not sure which of the six constellations apply to you, or if a project sits on a version that no longer receives fixes, drop me a line. I will look at next.config, the router setup and the deployment path and tell you what actually needs touching.