The Next.js July 2026 security release patches nine vulnerabilities, and one of them lets an attacker walk straight past your middleware. If you run a headless commerce storefront or a product surface on Next.js, this is a patch-this-week item. The fix that matters most is a middleware and proxy bypass that voids exactly the authentication checks most teams put their trust in.
What Next.js patched on July 20
Next.js shipped fixes in v16.2.11 (Active LTS) and v15.5.21 (Maintenance LTS) on July 20, 2026, closing four High and five Medium severity issues, per Vercel's release note. The four High-severity flaws are a middleware and proxy bypass (CVE-2026-64642, CVSS 8.3), server-side request forgery through rewrites (CVE-2026-64645, CVSS 8.3), server-side request forgery in Server Actions on custom servers (CVE-2026-64649), and a denial of service in App Router Server Actions (CVE-2026-64641). This is also the first release under a new preannounced monthly cadence Vercel described on July 13, 2026, so a Next.js security patch is now a scheduled event rather than a surprise. The fixes also ship in the 16.3 canary and preview lines and will land in 16.3 once it reaches stable.
Why the middleware bypass is the one to fix first
CVE-2026-64642 is the priority because it silently disables the security layer teams rely on most. The flaw hits App Router applications built with Turbopack that set a single entry in config.i18n.locales, and a crafted request bypasses any authentication or authorization check the middleware performs, per the GitHub advisory. It scores CVSS 8.3, is classed as improper authorization (CWE-285), and affects every 16.x release from 16.0.0 up to the 16.2.11 fix. The reason it ranks above the two SSRF flaws for most storefronts is behavioural. It produces no error. A request that should have been blocked simply is not, and it reaches a protected page or route handler as if it were authorized. For a storefront with a gated account area, a B2B pricing tier, or an admin surface sitting behind middleware, that is a straight-through door with no log line that looks wrong.
Middleware auth vs server-side data-path auth
Server-side data-path authorization is the durable pattern, and middleware authorization is the convenient one that just failed. Vercel's own workaround for the bypass is to enforce authorization in the page's server-side data path rather than relying solely on middleware, per the advisory workaround. That is not a stopgap, it is the correct architecture. Middleware is a good place for redirects, locale handling and cheap early rejects, but it sits in front of the request, so a framework-level bug in that position bypasses everything behind it. Authorization checked inside the Server Component, route handler or data loader that actually reads the data cannot be walked around by a routing trick, because it runs at the point of access. The two SSRF flaws make the same case from the other direction. CVE-2026-64645 lets a rewrites() or redirects() rule with a request-controlled hostname be pointed at an arbitrary host, and it reaches back to Next.js 12.0.0, per its advisory. Trusting request-derived input at the edge, whether for auth or for a destination hostname, is the shared root cause.
What we would change this quarter
Upgrade to 16.2.11 or 15.5.21 first, then move revenue-critical authorization out of middleware and into the server-side data path. Grep the codebase for auth logic that lives only in middleware.ts, and for every gated route confirm the check also runs where the data is actually read. Audit every rewrites() and redirects() rule for a hostname built from request input, because CVE-2026-64645 reaches back to Next.js 12 and a headless storefront that proxies to a CMS or a commerce backend is the exact shape that gets abused. On our headless commerce work we treat Next.js as the runtime under the whole storefront, so a framework CVE is a scheduled deploy with a regression run behind it, the same way we handle it on product builds and AI-native surfaces where Server Actions and streaming are core. Pin your Next.js version explicitly and wire the new monthly cadence into your deployment automation, so each release is a green or red build rather than a research project. The teams that stay calm on patch day are the ones who never put a revenue-critical check somewhere a routing bug could skip.