CVE-2026-64645: 
Wolfi vulnerability analysis and mitigation

CVE-2026-64645 is a Server-Side Request Forgery (SSRF) and Open Redirect vulnerability in Vercel's Next.js React framework. When a rewrites() or redirects() rule constructs its external destination hostname from request-controlled input (e.g., a dynamic path segment or has capture group), an attacker can supply an arbitrary hostname, bypassing the rule's intended hostname suffix restriction. For rewrite rules, Next.js proxies the request to the attacker-controlled host and serves the response from the application's origin (SSRF); for redirect rules, users can be sent to arbitrary external sites (Open Redirect). Affected versions are 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10; patches are available in 15.5.21 and 16.2.11. The vulnerability carries a CVSS v3.1 score of 6.1 (Medium) and a CVSS v4.0 score of 8.3 (High) (GitHub Advisory).

The root cause is insufficient encoding/validation of dynamic parameter values when they are interpolated into the hostname portion of a rewrite or redirect destination URL (CWE-918: SSRF; CWE-601: Open Redirect). The prepareDestination function in shared/lib/router/utils/prepare-destination.ts compiled the destination hostname template without applying encodeURIComponent to captured values, allowing characters such as . and - to alter the effective hostname. For example, a rule like destination: 'https://:tenant.api.example.com' with source: '/:tenant' could be exploited by requesting /<attacker-controlled-host>, causing Next.js to proxy to an arbitrary host. The fix applies encodeURIComponent as the encoder for the hostname compiler and adds URL validation in proxy-request.ts before the proxy call (GitHub Advisory, Patch 15.x, Patch 16.x).

For rewrite rules, successful exploitation enables SSRF: the Next.js server proxies HTTP requests to an attacker-specified host and returns the response to the client, potentially exposing internal network services, cloud metadata endpoints (e.g., 169.254.169.254), or other backend systems not intended to be publicly accessible. For redirect rules, users can be silently redirected to malicious external websites, enabling phishing, credential harvesting, or malware delivery. Confidentiality impact is rated High (CVSS v4.0) for the vulnerable system, with low integrity impact; availability is not affected (GitHub Advisory).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.78%, indicating a low but non-negligible probability of exploitation in the near term. Exploitation requires no authentication and no special privileges, but for the SSRF vector, attack requirements include specific deployment conditions (a rewrite/redirect rule that builds hostnames from user input), and for the open redirect vector, user interaction (clicking a crafted link) is needed (GitHub Advisory).

1. Reconnaissance: Identify a Next.js application (versions 12.0.0–15.5.20 or 16.0.0–16.2.10) that uses rewrites() or redirects() rules with dynamic segments in the destination hostname (e.g., destination: 'https://:tenant.api.example.com' or using a has query capture).
2. Craft malicious input: For a path-based rule like source: '/:tenant', construct a request path where the dynamic segment resolves to an attacker-controlled hostname. For example, if the destination is https://:tenant.api.example.com, supply a tenant value such as attacker.com%2F or a value that, when substituted without encoding, changes the effective hostname.
3. Send the request: Issue an HTTP request to the Next.js application targeting the crafted path (e.g., GET /attacker.com HTTP/1.1). For query-based has captures, include the malicious value in the appropriate query parameter.
4. Achieve SSRF or Open Redirect: For a rewrite rule, the Next.js server proxies the request to the attacker-controlled host and returns the response — enabling access to internal services or cloud metadata. For a redirect rule, the server issues a redirect response pointing the user's browser to the attacker's site.
5. Exploit the SSRF: Use the SSRF to probe internal network resources (e.g., http://169.254.169.254/latest/meta-data/ on AWS), access internal APIs, or exfiltrate sensitive data returned in the proxied response (GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from the Next.js server process to unexpected external hosts or internal IP ranges (e.g., 169.254.169.254, RFC 1918 addresses); unusual DNS lookups for attacker-controlled domains originating from the application server.
• Logs: Web server access logs showing requests to rewrite/redirect source paths with unusual or encoded values in dynamic segments (e.g., path segments containing dots, percent-encoding, or full hostnames); HTTP responses from the Next.js application containing content from unexpected upstream hosts.
• Application Logs: Next.js server logs recording proxy requests to hostnames that do not match the configured destination suffix; error messages referencing Invalid target hostname (added in the patched version) may indicate attempted exploitation against a patched instance.
• Network: For open redirect exploitation, HTTP 3xx responses from the application pointing to external domains not in the application's expected redirect allowlist.

Upgrade Next.js to version 15.5.21 (for the 15.x branch) or 16.2.11 (for the 16.x branch), which apply encodeURIComponent encoding to dynamic hostname parameters and add URL validation before proxying (v15.5.21 Release, v16.2.11 Release). If an immediate upgrade is not possible, the official workaround is to avoid constructing the hostname of an external rewrites() or redirects() destination from user-controlled input. If a dynamic subdomain is required, constrain the captured value to hostname-safe characters using a strict regex, for example: value: '(?<region>[a-z0-9-]+)' (GitHub Advisory).

The vulnerability was disclosed as part of a broader July 2026 Next.js security release that addressed nine security flaws, including additional SSRF, authentication bypass, and DoS issues, which attracted significant coverage from security news outlets (CyberSecurityNews, GBHackers). Netlify and Cloudflare both published changelogs noting the security release and its impact on their Next.js hosting platforms (Netlify Changelog, Cloudflare Changelog). The Next.js team published an official security release blog post, and HeroDevs provided a detailed technical write-up explaining the SSRF and redirect mechanics for developers on older, unsupported versions (Next.js Blog, HeroDevs).