Next.js July 2026 Security Release: 9 CVEs Patched

On July 20, 2026, the Next.js team shipped the framework's first scheduled, pre-announced security release: nine vulnerabilities patched in one batch — four high and five medium severity — across the two supported lines, 16.2 and 15.5. The news is not just the CVEs; it's the process. A week earlier (July 13), Vercel announced that Next.js is moving to a monthly security release program with advance notice, following the model long used by Django, Node.js, and OpenSSL.

The problem: surprise patches and a race against attackers

Anyone running Next.js in production knows the drill: a security patch drops with zero warning, and the team's evening turns into an emergency upgrade-and-audit sprint. It happened painfully twice in recent memory — the middleware bypass of March 2025 (CVE-2025-29927, CVSS 9.1), then React2Shell in December 2025, a perfect 10.0 in React Server Components.

The pressure keeps climbing. Vulnerability research volume across the whole industry is surging thanks to LLM-assisted tooling — Mozilla alone disclosed 271 issues in a single Firefox release, all surfaced by Anthropic's tooling. AI did not replace security researchers; it multiplied them — and the same equation applies to attackers. Vercel runs the same class of tooling against Next.js itself, through its deepsec project and an expanded bug bounty.

What actually changed

• A predictable monthly schedule: advance notice on the Next.js blog with the expected timeline and the highest anticipated severity. Ad-hoc patches remain for vulnerabilities already exploited in the wild.
• Coordination with platforms: the lead time lets hosting providers deploy mitigations such as WAF rules before every application has patched.

The headline vulnerabilities in this release:

• CVE-2026-64641 (high): denial of service via Server Actions in App Router through CPU exhaustion.
• CVE-2026-64642 (high): middleware/proxy bypass in apps built with Turbopack and a single i18n locale — any auth check performed in middleware is skipped entirely.
• CVE-2026-64645 (high): SSRF in rewrites() when the destination hostname is built from request-controlled input.
• CVE-2026-64649 (high): SSRF via Server Actions on custom servers.

The practical part

Upgrade first:

npm install next@16.2.11   # Active LTS
npm install next@15.5.21   # Maintenance LTS

Then the deeper lesson from the recurring middleware bypasses: middleware is an optimization layer, not your only line of defense. Session verification belongs in the data access layer itself:

// lib/dal.ts
import 'server-only'
import { verifySession } from './session'

export async function getOrders() {
  const session = await verifySession()
  if (!session) throw new Error('unauthorized')

  return db.orders.findMany({
    where: { userId: session.userId },
  })
}

With this pattern, even when middleware is bypassed (as in CVE-2026-64642), an attacker without a valid session still reaches no data.

Real-world caveats

• Self-hosted deployments are more exposed. Vercel-hosted apps received automatic WAF protection during React2Shell, while self-hosters carry the full window between disclosure and patching. A monthly schedule shrinks that window; it does not eliminate it.
• Running an e-commerce store on App Router with Server Actions? The DoS and SSRF fixes concern you directly — this upgrade is not optional polish.
• Pin dependencies with a lockfile and automate alerts (Renovate or Dependabot) so the monthly patch day becomes a short routine instead of a project.
• It's the same equation covered in MCP agent authentication: as intelligent systems get more capable, security becomes a continuous process, not an event.

Takeaway

Next.js has moved from reactive patching to a plannable security cadence — a direct response to an era where AI multiplies the speed of vulnerability discovery. The practical step today: upgrade to 16.2.11 or 15.5.21, and confirm your authentication never relies on middleware alone.

Primary source: July 2026 Security Release — Next.js blog