CVE-2026-64645: 
Wolfi vulnerability analysis and mitigation

CVE-2026-64645 is a Server-Side Request Forgery (SSRF) and Open Redirect vulnerability in Next.js affecting its rewrites() and redirects() configuration rules. When a rule constructs an external destination hostname from request-controlled input (path parameters or query string capture groups), an attacker can point the rule at an arbitrary hostname, bypassing the intended hostname suffix restriction. The vulnerability affects Next.js npm package versions >= 12.0.0 and < 15.5.21, and >= 16.0.0 and < 16.2.11. It was published on July 21, 2026, with the GitHub Advisory Database entry updated July 22, 2026. It carries a CVSS v4.0 base score of 8.3 (High) (GitHub Advisory).

The root cause is insufficient validation and encoding of dynamic route parameters when they are interpolated into the hostname portion of a rewrites() or redirects() destination URL (CWE-918: SSRF). The fix applies encodeURIComponent encoding to the destination hostname compiler in prepare-destination.ts, and adds URL validation in proxy-request.ts to ensure the resolved target is a valid URL before proxying (GitHub Commit 15.x, GitHub Commit 16.x). Exploitation requires no authentication and no user interaction, but does require the target application to have a rewrites() or redirects() rule that places a dynamic segment (from a path parameter or a has query capture group) directly into the hostname of the destination URL. For example, a rule like destination: 'https://:tenant.api.example.com' where :tenant is attacker-controlled allows the attacker to supply a value such as attacker.com# to redirect the proxy to an arbitrary host (GitHub Advisory).

For rewrites() rules, successful exploitation causes Next.js to proxy the HTTP request to an attacker-controlled host and serve the response from the application's origin, enabling SSRF — potentially exposing internal services, cloud metadata endpoints (e.g., 169.254.169.254), or other network-internal resources. For redirects() rules, the impact is an Open Redirect, which can be used to phish users or bypass security controls that rely on trusted redirect destinations. Confidentiality is the primary concern, as internal service responses may be exfiltrated; integrity and availability impacts are lower (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, such as https://:tenant.api.example.com or https://:region.api.example.com.
2. Identify the dynamic parameter: Determine whether the dynamic segment comes from a path parameter (e.g., /:tenant) or a has query capture group (e.g., ?region=...).
3. Craft a malicious request: Construct a request where the dynamic parameter value contains characters that break out of the intended subdomain context. For example, supply a value like attacker.com%23 (URL-encoded #) or attacker.com/ to cause the resolved hostname to point to attacker.com instead of attacker.com.api.example.com.
4. Trigger SSRF or Open Redirect: Send the crafted HTTP request to the Next.js application. For a rewrites() rule, the server will proxy the request to the attacker-controlled host and return the response to the client. For a redirects() rule, the server will issue an HTTP redirect to the arbitrary host.
5. Exfiltrate data (SSRF): If targeting internal infrastructure, use the SSRF to probe internal services (e.g., cloud metadata at http://169.254.169.254/latest/meta-data/) by crafting the hostname accordingly and reading 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) that do not match the configured api.example.com suffix.
• Network: HTTP responses from the Next.js application containing content originating from unexpected hosts (e.g., cloud metadata, internal service responses).
• Logs: Web server or Next.js access logs showing requests to rewrite/redirect routes with path segments or query parameters containing characters such as %23 (#), /, or other hostname-breaking sequences in the dynamic parameter position.
• Logs: Proxy error logs referencing unexpected target hostnames that do not match the configured destination suffix (e.g., error message Invalid target hostname "attacker.com" for proxy request, expected "api.example.com" — introduced in the patched version).
• Logs: Repeated requests to the same rewrite/redirect route with varying values in the dynamic parameter, potentially indicating automated scanning or exploitation attempts.

Upgrade to Next.js 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 (Next.js v15.5.21 Release, Next.js v16.2.11 Release). If an immediate upgrade is not possible, avoid constructing the hostname of external rewrites() or redirects() destinations 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 Next.js July 2026 security release that addressed multiple high and moderate severity issues simultaneously, including additional SSRF, DoS, and cache confusion vulnerabilities (Next.js v15.5.21 Release). Netlify published a changelog entry acknowledging the Next.js security vulnerabilities and their platform's response. Cloudflare's WAF changelog also referenced the release. Community discussion on dev.to noted that the blurring of client/server boundaries in Next.js (including Server Actions) contributes to this class of vulnerability.