CVE-2026-64645: Next.js SSRF Vulnerability in rewrites() and redirects() Explained (and How to Fix It)

A High-severity Server-Side Request Forgery flaw lets attacker-controlled hostnames slip past rewrites() and redirects() rules, and the fix isn't available to every Next.js major version still in production.

‍

Introduction

CVE-2026-64645 is a High-severity Server-Side Request Forgery (SSRF) vulnerability disclosed in Next.js on July 21, 2026. It affects the rewrites() and redirects() configuration options when a rule builds its destination hostname from request-controlled input, such as a path segment or a query parameter captured through a has condition.

The issue carries a CVSS 4.0 base score of 8.3, and it does not require authentication or user interaction to exploit. What makes CVE-2026-64645 an operational problem rather than just a patch-and-move-on item is the version range: it spans Next.js 12.0.0 through the latest 16.x releases, but the official fix only landed in two specific patch versions (v15 and v16). Teams on older major versions have no direct upgrade path to remediation without a broader migration.

‍

What Is CVE-2026-64645?

CVE-2026-64645 (GHSA-p9j2-gv94-2wf4) is classified under CWE-918, Server-Side Request Forgery. When a Next.js application defines a rewrites() or redirects() rule whose external destination hostname is assembled from request input, an attacker can substitute an arbitrary hostname into that destination, regardless of any suffix the rule was intended to enforce.

For a rewrites() rule, Next.js proxies the request server-side to that attacker-chosen host and returns the response as if it came from the application's own origin. That means an attacker can use the Next.js server as a relay into internal networks, cloud metadata endpoints, or other systems the server can reach but the public internet cannot. For a redirects() rule configured the same way, the result is an open redirect: the server sends the client's browser to an arbitrary destination the attacker controls.

‍

Why This Matters

For teams running Next.js in production, this vulnerability shows up in familiar ways:

• Vulnerability scanners such as Snyk and Tenable will begin flagging the next package once their databases ingest CVE-2026-64645, which will surface in dependency scans across affected applications.
• SSRF findings are treated seriously in SOC 2, PCI DSS, and FedRAMP audits, since they represent a path from an external attacker directly into internal infrastructure.
• CI/CD pipelines with dependency-gating rules could start blocking builds and deployments when this CVE is scored and ingested.
• Security teams reviewing any application that uses dynamic rewrite or redirect destinations, including common multi-tenant subdomain routing patterns, will want to confirm the affected code path exists before closing the finding.

The vulnerability doesn't require an unusual configuration to be exploitable. Multi-tenant SaaS applications that route by subdomain, and applications that build proxy destinations from a locale, region, or tenant identifier, are the most direct match for the vulnerable pattern.

‍

Who Is Affected

CVE-2026-64645 affects the next npm package across a wide version range, but the OSS remediation is only available for the two most recent release lines.

The distinction in that table matters. Vercel remediated CVE-2026-64645 by shipping patch releases within the currently maintained 15.5.x and 16.2.x lines. There is no equivalent patch release for the 12.x, 13.x, or 14.x lines. If your application is running one of those major versions, upgrading to a patched release means crossing at least one major version boundary, not applying a point release.

Applications are only exposed if a rewrites() or redirects() rule constructs its destination hostname dynamically, from a path parameter, a query value, or a has capture group. Static rewrite and redirect destinations are not affected by this specific CVE.

‍

Why This Is Hard to Fix Fast

The standard advice for any framework CVE is "upgrade to the patched version." For teams on Next.js 15.5.x or 16.2.x, that advice is accurate and low-risk: a point release upgrade.

For teams on Next.js 12.x, 13.x, or 14.x, that advice means something much larger. Major version upgrades in Next.js routinely bring changes to routing conventions, data fetching patterns, middleware behavior, and build tooling (the Pages Router to App Router transition alone represents a significant rewrite for many codebases). An engineering team running Next.js 12 in production is not one npm install away from remediation. They are looking at a multi-sprint migration project, regression testing across the entire application, and the very real possibility that the migration surfaces additional breaking changes unrelated to this CVE.

‍

Meanwhile, the SSRF finding does not wait for the migration to finish. Scanners flag it the moment their databases update. Auditors ask about it the moment it appears on a dependency report. Security teams open a ticket with a remediation SLA attached. The gap between "we know about this" and "we have shipped a fix" is exactly where NES for Next.js closes the loop.

‍

The HeroDevs Solution

NES for Next.js delivers remediated packages for EOL Next.js major versions (12.x) that resolve vulnerabilities like CVE-2026-64645 without requiring your team to complete a major version migration first.

This is a drop-in fix: your application continues running on the major version it already runs on, with no new features, no routing changes, and no code changes required to receive the security remediation. NES exists specifically to decouple "we need to fix this CVE now" from "we need to finish this migration eventually," so your team can plan the App Router migration on its own timeline instead of compressing it into an audit deadline.

‍

How to Fix It

If you're running Next.js 15.5.x or 16.x (supported lines): Upgrade directly.

npm install next@15.5.21   # for the 15.5 line
npm install next@16.2.11   # for the 16.2 line

As a workaround if you cannot upgrade immediately, avoid constructing external rewrites() or redirects() destination hostnames from user-controlled input. If a dynamic subdomain is required, constrain the captured value to hostname-safe characters, for example a pattern like [a-z0-9-]+, rather than accepting arbitrary input.

If you're running Next.js 12.x (EOL lines): There is no OSS patch release for your major version. Your options are:

1. Complete a major version migration to 15.5.21 or later, validating routing, middleware, and build behavior across your application, or
2. Apply a remediated package through NES for Next.js to resolve CVE-2026-64645 on your current major version while you plan the migration.

‍

Taking Action

CVE-2026-64645 is a reminder that framework security fixes generally target the versions still receiving active maintenance, not the versions still running in production. If your team is on a supported Next.js release, upgrade now, it's a straightforward patch. If you're running Next.js 12 and a full migration isn't realistic on your compliance team's timeline, talk to HeroDevs about NES for Next.js to get CVE-2026-64645 remediated on the version you're running today.

For the full technical advisory, see the GitHub Security Advisory GHSA-p9j2-gv94-2wf4.