CVE-2026-64645 in Next.js
Summary
by MITRE • 07/27/2026
Next.js is a React framework for building full-stack web applications. In versions 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, a rewrites() or redirects() rule that builds its external destination hostname from request-controlled input can be pointed at an arbitrary hostname, regardless of the rule's hostname suffix. For a rewrite, Next.js proxies the request to that arbitrary host and serves the response from the application's origin, leading to Server-Side Request forgery. A redirects() rule configured this way is vulnerable to an Open Redirect. This issue has been fixed in versions 15.5.21 and 16.2.11.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/27/2026
This vulnerability affects Next.js applications running version 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, where improperly configured rewrite or redirect rules can lead to critical security flaws. The core issue lies in how the framework handles external destination hostnames when these are constructed from request-controlled input parameters. When developers configure rewrites() or redirects() functions that dynamically build hostname values based on user-supplied data without proper validation, Next.js fails to enforce hostname restrictions that would normally prevent access to arbitrary domains.
The technical flaw manifests when an attacker can manipulate the input used to construct external hostnames in rewrite or redirect configurations. For rewrite operations, this creates a server-side request forgery vulnerability because Next.js will proxy requests to any arbitrary hostname specified by the attacker, effectively allowing malicious actors to make requests on behalf of the application server. The framework acts as an intermediary, forwarding requests to attacker-controlled hosts and then serving responses back through the application's origin, bypassing normal network security controls and potentially exposing internal systems or sensitive data.
For redirect operations configured in the same vulnerable manner, the issue results in open redirect vulnerabilities where attackers can redirect users to malicious websites. This creates potential phishing opportunities and allows attackers to exploit user trust in legitimate applications. The vulnerability specifically affects rules that build external destination hostnames from request-controlled input, meaning that any parameter passed through the request such as query strings, headers, or URL segments could be used to manipulate the final hostname value.
This issue directly corresponds to CWE-918, Server-Side Request Forgery, and CWE-601, Open Redirect, both of which are well-documented security weaknesses in web applications. The vulnerability also aligns with ATT&CK technique T1190, Exploit Public-Facing Application, as it represents a method for attackers to leverage application configuration flaws to gain unauthorized access to external resources or redirect users. Organizations using affected Next.js versions face significant risk of data exposure and potential compromise through these attack vectors.
The fix implemented in versions 15.5.21 and 16.2.11 addresses the core problem by introducing proper validation mechanisms that prevent arbitrary hostnames from being used in rewrite and redirect operations. The security patch ensures that hostname values constructed from request-controlled input are properly validated against configured rules or restrictions, preventing the bypass of normal hostname validation. Organizations should immediately upgrade to these patched versions to remediate the vulnerability.
Mitigation strategies include reviewing all rewrite and redirect configurations to ensure that external hostnames are not built from untrusted user input without proper validation. Developers should implement strict hostname whitelisting or pattern matching for external destinations, validate that configured hostnames match expected formats, and avoid dynamic construction of external URLs from request parameters. Security teams should conduct thorough audits of Next.js applications to identify any configurations that might be vulnerable to this class of attack, particularly focusing on routes that handle user input in URL construction.
Additional defensive measures involve implementing network-level controls such as firewalls or proxy restrictions to limit outbound connections from application servers, though this approach provides only partial protection since the vulnerability exists at the application configuration level. Organizations should also consider implementing runtime monitoring to detect suspicious patterns of external requests originating from their applications, which could indicate exploitation attempts. Regular security testing including penetration testing and code reviews focused on URL handling and request routing will help identify similar vulnerabilities in other parts of the application stack that might present similar risks.