Next.js Shipped Its First Scheduled Security Release — the Middleware Bypass Is the One to Actually Worry About
On July 21, 2026, Vercel shipped v16.2.11 and v15.5.21, patching nine CVEs in Next.js, four rated High severity. That's not unusual on its own; frameworks patch bugs constantly. What makes this release different is that it's the first one to happen under a formal, pre-announced security-release program Next.js announced a week earlier, on July 13. One of those High-severity bugs is a middleware and proxy bypass that can skip your auth checks entirely if you're running App Router on Turbopack with a single locale. Another is a server-side request forgery hiding in rewrites() configs that most people never think to audit.
What actually shipped
The July 21 release covers both active Next.js lines: v16.2.11 for the Active LTS track and v15.5.21 for Maintenance LTS. Nine CVEs total, split four High and five Medium. The fixes also landed in the 16.3 canary and preview builds ahead of a stable 16.3 release. If you're running anything below those patch numbers on either major line, you're exposed to all nine.
The four High-severity issues are a denial-of-service bug in App Router apps that use Server Actions (CVE-2026-64641), the middleware/proxy bypass in Turbopack single-locale setups (CVE-2026-64642), the SSRF via request-controlled rewrite destinations (CVE-2026-64645), and a second SSRF affecting Server Actions on custom servers (CVE-2026-64649). The five Medium-severity issues cover an SVG-triggered DoS in the Image Optimization API, an unbounded Server Action payload bug on the Edge runtime, unauthenticated disclosure of internal Server Function endpoint IDs, and two cache-collision bugs where a server-side fetch with a request body can return a cached response meant for a different request to the same URL.
The middleware bypass is the one to actually worry about
Here's the one I'd stop and check first: CVE-2026-64642. If your App Router app is built with Turbopack and has exactly one entry in config.i18n.locales, middleware and proxy checks can be bypassed outright. Any authentication or authorization logic you've put in middleware (session checks, role gating, redirecting unauthenticated users away from protected routes) simply doesn't run for the affected requests.
That's a bigger deal than a typical Medium-severity leak because middleware is where a lot of solo and small-team Next.js apps put their entire auth gate. You write one middleware.ts file, check for a session cookie, redirect to /login if it's missing, and call the app protected. If that check can be routed around at the framework level, the protection was never actually there for the affected request shapes. No misconfiguration on your part required, just Turbopack plus a single-locale setup that's genuinely common for apps that never bothered with i18n in the first place.
The SSRF, and the rest of the batch
CVE-2026-64645 is quieter but has a wider blast radius. If your rewrites() or redirects() config builds an external destination hostname from anything request-controlled (a header, a query param, a path segment you're interpolating into the target URL), an attacker can redirect that request to an arbitrary host, regardless of the hostname suffix your rule was supposed to constrain it to. For rewrites, that's SSRF: your server becomes the one making the outbound request, which means it can reach internal services, cloud metadata endpoints, or anything else sitting behind your server's network boundary that an external attacker couldn't otherwise touch. For redirects, the same flaw produces an open redirect. Unlike the middleware bug, this one doesn't need Turbopack or a specific locale config: it needs one rewrite rule with a hostname built from user input, which is a pattern I've seen in more than one proxy-style Next.js setup that forwards requests to a backend based on a subdomain or path prefix.
The rest of the batch is lower-drama but worth knowing about. CVE-2026-64643 lets an attacker enumerate internal Server Function endpoint IDs without authenticating. It's not exploitable on its own, but it's useful reconnaissance for chaining into something else. CVE-2026-64647 is the cache-collision bug: a server-side fetch call with a request body containing invalid UTF-8 byte sequences can return a cached response meant for a completely different request to the same URL, because the cache key doesn't fully distinguish between bodies that decode differently. It's a narrow trigger condition, but if you're doing server-side fetches with dynamic bodies and relying on Next's data cache, it's worth knowing the collision exists.
Why "scheduled" is the real headline
Next.js has patched security bugs before, but always ad hoc: no advance notice, whenever a fix was ready. Starting this month, Vercel is moving to something closer to what Node.js and other mature open-source projects already do: a roughly monthly cadence, announced in advance, with the expected timeline and worst-case severity published before the actual patch drops. They flagged this July release a week early, on July 13, telling teams to expect 4 High and 5 Medium fixes before a single CVE number existed.
That's a genuinely useful change for planning: you can budget a recurring maintenance slot instead of getting blindsided. But it also means "check for a Next.js security release" is now a calendar commitment, not a one-off. Vercel says urgent, actively-exploited bugs still get ad hoc patches outside the schedule, so this doesn't replace vigilance entirely. It adds a predictable rhythm on top of it. If you already have a monthly maintenance pass for dependencies (and if you don't, this is a good reason to start one), add "check nextjs.org/blog for a security release" to it alongside whatever you're already doing for Node and npm.
The five-minute check, and the honest counter-take
Run this now: confirm your deployed Next.js version. If it's below 16.2.11 or 15.5.21, upgrade regardless of anything else in this post: that alone closes all nine issues. Then check two things specifically: are you on Turbopack with a single-locale i18n config and using middleware for auth or route protection, and does any rewrites() or redirects() rule build its destination hostname from request-controlled input. Both checks take less time than reading this article.
Here's the honest counter-take: most solo Next.js apps don't have an exotic middleware-plus-single-locale setup, and if you haven't touched i18n config at all, CVE-2026-64642 likely doesn't apply to you in the specific way the advisory describes. This isn't a universal five-alarm fire the way a remote-code-execution bug would be. But the SSRF in rewrites() has a much wider blast radius than the middleware bug, because it doesn't need any unusual configuration, just one proxy-style rewrite rule with an attacker-influenceable hostname, which is common in exactly the kind of small app that forwards requests to a backend by subdomain. Check it even if you're fairly sure you're not exposed. Being fairly sure is how these things end up in a postmortem instead of a changelog entry.
Author
Lukas
@lukcombinator