TL;DR
Vercel fixed three Next.js vulnerabilities, each rated CVSS 8.3. Two of them allow Server-Side Request Forgery, while the third lets crafted requests slip past middleware-based authentication. Patched builds ship in 16.2.11 and 15.5.21.
Why It Matters
Next.js powers full-stack React applications at many large companies. SSRF on such an origin is nasty. The server fetches an attacker-chosen host, then returns that response as if the application produced it.
Internal services usually trust requests from the app tier. A bypass of middleware authentication is equally serious, because many teams place their only authorization check there.
How the Attacks Work
CVE-2026-64645: Rewrites and Redirects
A rewrite rule can build its external destination hostname from request-controlled input. An attacker can then point that rule at an arbitrary host, and the configured hostname suffix does not stop it. Redirect rules configured the same way turn into open redirects.
CVE-2026-64649: Server Actions on Custom Servers
Server Actions sometimes forward or redirect a request. If the attacker controls host-associated headers, the outbound request can land on a malicious host. Some configurations also leak internal values that weaken proxy authorization. Managed hosting pins the host upstream and stays safe, as do next start and standalone output from version 14.2 onward.
CVE-2026-64642: Middleware Bypass
This one is narrower. App Router applications built with Turbopack and exactly one entry in the i18n locales list can be reached through crafted requests that skip middleware authentication.
Affected Versions
- CVE-2026-64645: 12.0.0 to 15.5.20, and 16.0.0 to 16.2.10
- CVE-2026-64649: 14.1.1 to 15.5.20, and 16.0.0 to 16.2.10
- CVE-2026-64642: 16.0.0 to 16.2.10
Patch and Mitigation
Upgrade first. Grab Next.js 16.2.11 on the 16.x branch, or Next.js 15.5.21 for older deployments.
Stuck on an old version? Stop building external destination hostnames from user input, and constrain any dynamic subdomain to hostname-safe characters. Pin or validate Host and X-Forwarded-Host at your edge. Finally, enforce authorization inside each page’s server-side data path rather than in middleware alone.
No public proof-of-concept exists, and nobody has confirmed exploitation in the wild. Full technical detail sits in the Next.js security advisories.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.