Netlify Narrows Nine New Next.js Bugs Down to the One That Matters

Next.js shipped the first release under its new monthly security cadence on July 20, patching nine vulnerabilities, four of them high severity, in next@15.5.21 and next@16.2.11 (Next.js blog, July 2026 Security Release). Netlify posted its own changelog entry the same day telling customers which of those nine actually reach a Netlify build, and it’s one (Netlify changelog, July 21, 2026).

What’s in the patch

The nine CVEs span four categories. The one Netlify calls out by name is CVE-2026-64642, a middleware and proxy bypass that hits App Router apps built with Turbopack and a single locale in config.i18n.locales, letting a request skip an authorization check entirely. The rest are server-side request forgery through rewrites() or redirects() rules that build a destination hostname from request-controlled input (CVE-2026-64645), a Server Action denial-of-service triggered by crafted requests that spike CPU usage (CVE-2026-64641), an unbounded Server Action payload that can exhaust memory on the Edge runtime (CVE-2026-64646), a malicious SVG that can crash the Image Optimization API, and a custom-server SSRF where an attacker controls the Host header a forwarded Server Action redirects to (CVE-2026-64649).

Why Netlify’s read matters more than the CVE list

Nine CVEs at once reads like a bad week for Next.js, but severity depends entirely on how and where an app runs, and that’s the part a generic CVE writeup can’t answer. Netlify’s changelog does the platform-specific triage: Server Action host forwarding, the Image Optimizer crash, and the Edge-runtime memory exhaustion don’t apply to how Netlify runs Next.js, so those three are off the table for Netlify customers by default. The middleware bypass is the one that does apply, and only to a specific combination: Turbopack builds using the legacy middleware.ts convention with a single configured locale. Sites on Webpack, or already migrated to the newer proxy.ts convention, aren’t exposed even to that one. Netlify’s fix is the same as everyone else’s: upgrade to 15.5.21 or 16.2.11 and redeploy.

That distinction is the actual news here. A developer scanning a CVE feed sees nine bugs and a scramble; a developer reading Netlify’s post sees one relevant bug, tied to a specific build config, with a one-line fix. This is the second time this year Netlify has run this playbook. It published matching guidance after a May 2026 Next.js and React security release, pointing self-hosted-adapter users to an OpenNext version bump (Netlify changelog, May 8, 2026). It’s becoming the expected move whenever Vercel’s monthly cadence lands, and it’s a better outcome for customers than treating every framework CVE as universally applicable.

Our take

A monthly security-release cadence is the right instinct for a framework as widely deployed as Next.js. It gives teams predictable warning instead of ad hoc alarms. But it also shifts real work onto every hosting platform Next.js runs on, to translate a framework-level advisory into a platform-specific one before it’s actionable. Netlify doing that translation quickly is good practice, not a given, and it raises the bar for what any host should ship the same day a framework it depends on discloses a bug.

Key Takeaways

• Next.js’s first monthly security release (July 20, 2026) patched nine CVEs, four high severity, in 15.5.21 and 16.2.11.
• Only one, a middleware/proxy bypass in Turbopack builds using legacy middleware.ts with a single locale, reaches Netlify’s platform by Netlify’s own account.
• Three of the nine (Server Action host forwarding, the Image Optimizer crash, Edge-runtime memory exhaustion) don’t apply to how Netlify runs Next.js.
• The fix is the same either way: upgrade to 15.5.21 or 16.2.11 and redeploy.