CVE-2026-64645

What it actually does

The flaw affects Next.js applications that define rewrites() or redirects() rules where an external destination hostname is constructed from request-controlled input, such as a route parameter or wildcard. In vulnerable versions, hostname suffix constraints can be bypassed, allowing an attacker to supply an arbitrary external hostname. For vulnerable rewrites(), the Next.js server can be induced to proxy attacker-chosen URLs and return the response from the application’s trusted origin, creating server-side request forgery (SSRF). For vulnerable redirects(), the application can emit redirects to attacker-controlled domains, creating an open redirect. The issue affects Next.js 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10 and is fixed in 15.5.21 and 16.2.11.

Why it matters to the business

If an exposed Next.js application uses the vulnerable routing pattern, attackers may abuse the trusted application domain to reach internal services, cloud metadata endpoints, partner allowlisted systems, or attacker-controlled phishing pages. The most serious risk is SSRF through rewrites, which can expose sensitive internal data or enable pivoting through infrastructure that is not directly reachable from the internet. Open redirect exposure can also damage user trust by making phishing links appear to originate from a legitimate domain. The vulnerability is newly published, has low current EPSS likelihood, is not in the CISA KEV catalog, and has no known mature public exploitation, but internet-facing applications with dynamic external rewrite or redirect rules should still be prioritized because exploitation requires no authentication once the vulnerable configuration is present.

How an attack unfolds

An attacker first identifies a Next.js route backed by a rewrite or redirect rule that sends traffic to an external hostname and where part of that hostname is populated from the incoming request. The attacker crafts a request that places a controlled hostname into the dynamic portion of the rule while preserving any expected suffix or path shape. In vulnerable versions, Next.js incorrectly allows the attacker-controlled hostname to override or bypass the intended hostname suffix. If the rule is a rewrite, the server makes an outbound request to the attacker-selected host and serves the returned content under the legitimate application origin; the attacker may use this to query internal HTTP services, cloud metadata addresses, or an external collaborator server to prove SSRF. If the rule is a redirect, the server responds with a Location header pointing to the attacker-selected site, enabling phishing, credential capture, or redirect-chain abuse. Successful exploitation depends on the application having the specific unsafe rewrite or redirect configuration; Next.js installations without such dynamic external destinations are not directly exploitable by this issue.

How to fix it

Upgrade affected Next.js applications to a fixed release: use Next.js 15.5.21 or later for the 15.x line, or 16.2.11 or later for the 16.x line. Applications running Next.js 12.x, 13.x, or 14.x should upgrade to a supported fixed branch, preferably the latest supported 15.x or 16.x release. In addition to upgrading, review next.config.js for rewrites() and redirects() rules that construct external destination hostnames from route parameters, wildcards, query values, headers, or other request-controlled input. Replace dynamic host construction with a strict allowlist of known destination hosts. Do not rely on suffix matching alone for security decisions. If immediate upgrade is not possible, disable or narrow affected rewrite/redirect rules, block requests containing URL schemes or encoded host separators in dynamic route segments, and restrict server egress so the application cannot reach metadata services, loopback addresses, RFC1918 networks, or other sensitive internal destinations unless explicitly required.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.21 or later, or 16.2.11 or later, by checking package manifests, lockfiles, container images, build output, and runtime dependency inventories. Search application configuration for rewrites() and redirects() rules with external destinations where the hostname contains dynamic segments such as :param, wildcard captures, or values derived from request input. Validate with a controlled test domain: send a request that attempts to place the controlled domain into the destination hostname and confirm that the application does not proxy to it and does not emit a Location header pointing to it unless explicitly intended and allowlisted. For SSRF hardening, verify outbound network controls block access from the application runtime to 169.254.169.254, localhost, RFC1918 address ranges, and other sensitive internal services. Re-run application route tests after upgrading to ensure legitimate rewrite and redirect behavior still works without accepting arbitrary hostnames.

Typical attack path

1. Fingerprint an internet-facing application as Next.js and enumerate routes that appear to proxy or redirect to external destinations.
2. Identify a route whose destination hostname appears to include user-controllable input, such as a path parameter, wildcard, subdomain value, or query-derived value.
3. Send crafted requests containing attacker-controlled hostnames, encoded URLs, dotted-decimal IPs, or internal IP addresses in the controllable portion of the route.
4. For a vulnerable rewrite, observe whether the application server fetches the attacker-selected destination and returns the response from the legitimate application origin.
5. For SSRF validation or exploitation, attempt access to internal-only targets such as localhost services, RFC1918 addresses, or cloud metadata endpoints.
6. For a vulnerable redirect, observe whether the response Location header points to an arbitrary attacker-controlled domain.
7. Use the trusted origin behavior to exfiltrate reachable data, perform internal reconnaissance, or lure users through trusted-looking redirect URLs.

How to detect it

To determine whether exploitation has already occurred, review web access logs, reverse proxy logs, CDN/WAF logs, application logs, and outbound network telemetry from Next.js application servers. Focus on routes governed by rewrites() and redirects() rules with external destinations. Look for requests containing full URL schemes, encoded schemes, encoded slashes, hostname-like route parameters, IP literals, cloud metadata addresses, localhost references, or private network ranges in path segments or query strings. For redirect abuse, search HTTP responses with 3xx status codes where the Location header points to unfamiliar external domains, newly registered domains, URL shorteners, or domains not present in the intended redirect allowlist. For SSRF abuse, correlate suspicious inbound requests with near-simultaneous outbound HTTP/DNS connections from the application server to unexpected hosts, especially 169.254.169.254, 127.0.0.1, ::1, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Review DNS logs for application servers resolving unusual hostnames immediately after crafted route requests. In cloud environments, inspect metadata service access logs where available, IAM credential usage, and unusual calls made by application instance roles following suspicious inbound traffic. Also inspect source control and deployment artifacts for vulnerable rewrite or redirect patterns to identify which routes require retrospective log analysis.

• 169.254.169.254
• metadata.google.internal
• 169.254.169.254/latest/meta-data
• 169.254.169.254/latest/api/token
• 127.0.0.1
• localhost
• ::1
• http%3A%2F%2F
• https%3A%2F%2F
• %2F%2F169.254.169.254
• %2F%2Flocalhost
• %2F%2F127.0.0.1
• Location: http://
• Location: https://
• rewrites()
• redirects()
• destination: 'http://
• destination: "http://
• destination: 'https://
• destination: "https://

What your security team should do

• Inventory all internet-facing and internally exposed Next.js applications and identify those running versions 12.0.0 through 15.5.20 or 16.0.0 through 16.2.10.
• Prioritize applications that define external rewrites() rules, because these can produce SSRF and have higher impact than redirect-only exposure.
• Upgrade to Next.js 15.5.21 or 16.2.11 or later, and rebuild/redeploy artifacts rather than only changing package files.
• Perform code review of next.config.js and related routing configuration for request-controlled external hostnames; replace dynamic hosts with explicit allowlists.
• Add egress filtering for application runtimes to block metadata endpoints, loopback, link-local, RFC1918, and other sensitive internal networks unless required.
• Add monitoring for unusual outbound HTTP requests from Next.js servers to unexpected domains, IP literals, cloud metadata addresses, and internal address ranges.
• Review access logs for redirect responses to unfamiliar domains and rewrite/proxy routes receiving encoded URL schemes, double slashes, or internal IP address values.
• Because this is not currently KEV-listed and has low EPSS, balance urgency against exposure: patch broadly during the next expedited maintenance window, but handle vulnerable internet-facing SSRF-capable configurations as urgent.