Security release
Next.js July 2026 Security Release Upgrade Checklist
Published July 24, 2026
Next.js 15.5.21 and 16.2.11 fix nine vulnerabilities in App Router, Server Actions, middleware and proxy handling, external rewrites, image optimization, and server-side fetch caching.
Upgrade first, then check which vulnerable features the app uses. The checks below do not send exploit requests. They tell you which advisories deserve a closer code and deployment review.
Install a patched release
The official release provides patches for the supported 15.5 Maintenance LTS and 16.2 Active LTS lines:
pnpm add next@15.5.21
# or
pnpm add next@16.2.11
pnpm exec next --version
pnpm buildNext.js also published the fixes in 16.3.0-canary.92 and 16.3.0-preview.7. I would not move a stable production app to canary or preview just to get this patch. Use the supported stable line unless the app already depends on a 16.3 prerelease.
Several advisories include Next.js 12, 13, and 14 in their affected ranges, but the first patched releases listed by GitHub are 15.5.21 and 16.2.11. An older app needs a tested major-version upgrade, not a patch that does not exist on its current line.
Check the app before you test anything hostile
I start with package and source inspection. Run these from the repository root and review the matches instead of treating every match as proof of exposure:
pnpm exec next --version
git grep -nE \
'use server|use cache|runtime.*edge|middleware|proxy|remotePatterns|unoptimized|loader' \
-- '*.ts' '*.tsx' '*.js' '*.jsx' '*.mjs'
git grep -nE \
'rewrites|redirects|i18n|locales|new Request|X-Forwarded-Host|Host' \
-- 'next.config.*' '*.ts' '*.tsx' '*.js' '*.jsx' '*.mjs'A clean search is useful, but it is not enough. Check generated configuration, custom servers, reverse proxies, deployment templates, and code outside the main app directory. Confirm the installed version from the production lockfile or image as well as a developer machine.
Match each advisory to its required conditions
| Advisory | Affected Next.js versions | Check this condition |
|---|---|---|
| CVE-2026-64641High | >=13.0.0 <15.5.21>=16.0.0 <16.2.11 | App Router with at least one Server Action. Crafted requests can exhaust CPU. Pages Router apps and apps without Server Actions are not affected. There is no workaround besides upgrading. |
| CVE-2026-64642High | >=16.0.0 <16.2.11 | App Router built with Turbopack, exactly one entry in config.i18n.locales, and authorization in middleware or proxy. Until upgraded, enforce authorization again in the page's server-side data path. |
| CVE-2026-64645High | >=12.0.0 <15.5.21>=16.0.0 <16.2.11 | An external rewrites() or redirects() destination builds its hostname from a path or has capture controlled by the request. Remove that input from the hostname or constrain it to hostname-safe characters. |
| CVE-2026-64649High | >=14.1.1 <15.5.21>=16.0.0 <16.2.11 | Server Actions on a custom server or deployment where clients can control host-associated headers. Managed hosting is not affected. Next.js next start and standalone output pin the host from 14.2 onward. |
| CVE-2026-64644Medium | >=15.5.0 <15.5.21>=16.0.0 <16.2.11 | Self-hosted default image loader with configured remote images. Vercel, images.unoptimized: true, and a custom image loader are not affected. The advisory provides experimental.imgOptSkipMetadata: true as a temporary workaround. |
| CVE-2026-64646Medium | >=13.0.0 <15.5.21>=16.0.0 <16.2.11 | App Router with a Server Action using the Edge runtime. Until upgraded, make the hosting provider reject request bodies larger than 5 MiB. |
| CVE-2026-64643Medium | >=13.0.0 <15.5.21>=16.0.0 <16.2.11 | App Router with use server or use cache endpoints. Endpoint IDs can be disclosed for reconnaissance. Authenticate inside every Server Action and cache boundary. |
| CVE-2026-64648Medium | >=13.0.0 <15.5.21>=16.0.0 <16.2.11 | App Router server-side calls shaped like fetch(new Request(init), aDifferentInit). A response body can be confused with one for another request body. There is no workaround besides upgrading. |
| CVE-2026-64647Medium | >=13.0.0 <15.5.21>=16.0.0 <16.2.11 | App Router server-side fetches derived from request bodies with a non-UTF-8 charset. Use UTF-8 bodies until upgraded. Pages Router apps are not affected. |
Verify the deployed fix
After the upgrade, I check the artifact that will run in production:
- The lockfile resolves Next.js to 15.5.21 or 16.2.11.
- The production build finishes with the same lockfile and package manager as CI.
- Server Actions, middleware or proxy rules, images, rewrites, and redirects still work.
- The deployed image or server reports the intended Next.js version.
- Rollback points to a patched image, not the vulnerable release that was just replaced.
Do not prove the denial-of-service findings against production. Do not aim SSRF checks at cloud metadata, internal services, or third-party hosts. Configuration review, a patched version check, and normal regression tests answer the upgrade question without creating an incident.
Patching does not replace application authorization
CVE-2026-64642 can bypass middleware or proxy authorization under its specific conditions. CVE-2026-64643 also shows why a Server Action ID is not a secret. Keep the permission decision inside the server-side operation that reads or changes data.
I use the same rule outside Next.js: a frontend auth check is not authorization.
Check the public deployment separately
The Codevetta vibe coding launch risk scanner checks public HTTP behavior such as security headers, cookies, exposed client assets, and backend surface signals. It does not inspect your package version and cannot confirm that these nine CVEs are fixed.
Use the version and configuration checks above for this release. Use the scanner after deployment for a separate pass over what the public app exposes.
Primary sources