Next.js Security Patches Now Come on a Schedule: What the First Release Fixes

Next.js shipped its first scheduled security release today. Patch releases for the two lines it covers, 16.2.11 (Active LTS) and 15.5.21 (Maintenance LTS), fix four high-severity and five medium-severity vulnerabilities, detailed in the July 2026 Security Release post. The fixes matter, but I think the change in process matters more. Until now, Next.js security patches arrived without advance notice. Now most will come on a calendar teams can plan around.

From surprise patches to a calendar#

The Next.js team announced the program on July 13. Roughly once a month, the Next.js blog will post advance notice of an upcoming security release, with the expected timeline and the highest anticipated severity it covers. Urgent disclosures and anything already exploited in the wild will still get ad-hoc patches. The team gives two reasons: the old ad-hoc patches came with no warning and disrupted users, and vulnerability research volume is rising fast, driven by LLM-assisted discovery that they also run against Next.js.

The first release was set for July 20 and then moved to July 21. The npm registry shows 15.5.21 and 16.2.11 published on July 21, followed by 16.3.0-canary.92 and 16.3.0-preview.7 the same day. A one-day slip is fine, but leave some slack in your upgrade window.

What got fixed#

The four high-severity issues:

• CVE-2026-64641: crafted requests to an App Router app with at least one Server Action can cause excessive CPU usage that blocks other requests in the same process, a denial of service.
• CVE-2026-64642: App Router apps built with Turbopack that have a single entry in config.i18n.locales can have their middleware/proxy bypassed.
• CVE-2026-64645: a rewrites() or redirects() rule that builds its external destination hostname from request-controlled input can be pointed at any host, whatever hostname suffix the rule expects. Rewrites become SSRF and redirects become an open redirect.
• CVE-2026-64649: on custom servers, a Server Action that forwards or redirects a request can be steered to a malicious host if the attacker controls Host-associated headers.

The five medium-severity issues are CPU exhaustion in /_next/image from malicious SVGs, unbounded Server Action payloads in the Edge runtime, disclosure of Server Action and use cache endpoint IDs, and two fetch cache-confusion bugs where a server-side fetch with a body can get a cached response for a different body sent to the same URL. One needs the fetch(new Request(init), aDifferentInit) shape; the other needs a body with invalid UTF-8.

Middleware should not be your only auth layer#

The advisory for CVE-2026-64642 is blunt: any authentication or security checks your middleware/proxy performs are bypassed. The affected configuration is narrow, but the lesson is not.

Middleware is a useful first filter for redirects, coarse gating and headers, not the only thing between an anonymous request and your data. Every Server Action, Route Handler and server-side data access function should check the session and authorization on its own. If your app already works that way, this CVE turns an auth bypass into a routing nuisance. If it doesn't, you have a design problem that will outlast this bug.

Triage by how you deploy#

Not every CVE applies to every app, so I sort by deployment shape:

• Any App Router app with Server Actions is in scope for the CPU denial of service. Patch it.
• Self-hosted with the default image loader and remote images configured is in scope for the SVG issue. Remote optimization is off by default, so check your images config.
• Custom servers: the Server Action SSRF applies to custom servers and needs attacker control of Host-associated headers. Separately, if you self-host behind nginx like I do on a VPS, check whether your proxy passes client-supplied Host or X-Forwarded-Host through as-is.
• Rewrites with dynamic hostnames: search next.config for rules whose external destination hostname comes from request input.

A quick first pass:

npm ls next
grep -nE "rewrites|redirects|i18n|remotePatterns" next.config.*

Making the calendar useful#

A schedule only helps if the team treats it as one. What I'd set up this week:

• Watch the Next.js blog and turn each notice into a ticket with an owner and a date.
• Stay on a patched line. This release ships patches for 16.2 and 15.5, plus the 16.3 canary and preview. If you are on any other line, getting onto one of those comes first.
• Keep upgrades boring. A short smoke test covering a Server Action, a protected route, an image route and any rewrites lets a patch go out as a normal deploy.
• Remember what self-hosting costs you. The Next.js team says the lead time lets it coordinate with hosting providers and platform partners on mitigations like firewall rules for unpatched apps. On your own VPS, nobody deploys those for you, so the advance notice is your head start.

My take#

This is the right move. Surprise patches force teams to choose between dropping everything and carrying risk; a roughly monthly slot turns security patching into planned work. More machine-assisted research means more findings, so I expect these releases to be full, not empty. I'm working through CEH material right now, and SSRF and trusting client-controlled Host headers are textbook web mistakes. Seeing both in one framework release is a good reminder to check proxy and header handling on every project.