CVE-2026-64645
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Next.js is an open-source React framework, maintained by Vercel, that provides server-side rendering, static site generation, file-based routing, and a built-in server capable of proxying and redirecting requests through its rewrites() and redirects() configuration.
A high-severity Server-Side Request Forgery (SSRF) and Open Redirect vulnerability (CVE-2026-64645) has been identified in Next.js. A rewrites() or redirects() rule that builds its external destination hostname from request-controlled input could be pointed at an arbitrary hostname, regardless of the hostname suffix the rule was written to enforce. For rewrites, Next.js proxies the request to that arbitrary host and serves the response back from the application's origin, resulting in SSRF; for redirects, the value is emitted in the Location header, resulting in an Open Redirect.
Per OWASP: In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.
Details
Module Info
- Product: Next.js
- Affected packages: next
- Affected versions: >=12.0.0 <15.5.21, >=16.0.0 <16.2.11
- GitHub repository: https://github.com/vercel/next.js
- Published packages: https://www.npmjs.com/package/next
- Package manager: npm
- Fixed in:
- OSS v15.5.21, v16.2.11
- NES for Next.js v12.3.x
Vulnerability Info
This high-severity vulnerability is found in versions of Next.js >=12.0.0 <15.5.21 and >=16.0.0 <16.2.11.
When an application defines a rewrites() or redirects() rule whose external destination hostname includes a dynamic segment built from request-controlled input, Next.js compiled the destination hostname in prepareDestination (packages/next/shared/lib/router/utils/prepare-destination.ts) without encoding the interpolated parameter value. The dynamic segment can be captured from the path (for example source: '/:tenant' with destination: 'https://:tenant.api.example.com') or from a has condition such as a query capture. Because the value was inserted verbatim, a parameter containing an exotic character such as /, #, or ? could break out of the rule's intended hostname suffix.
For example, a rule with the destination https://:target.internal.example.com/data is written expecting the host to always remain under .internal.example.com. A request-supplied target value of attacker.com/ compiles to attacker.com/.internal.example.com, whose effective host is attacker.com.
This vulnerability could be exploited by:
- supplying a crafted parameter value containing exotic characters (/, #, ?) that escape the intended destination hostname suffix
- causing a rewrite rule to proxy the request to an attacker-chosen or internal host (SSRF), potentially exposing internal services or cloud metadata endpoints
- causing a redirect rule to emit an attacker-controlled Location header (Open Redirect)
Mitigation
Next.js versions that are End-of-Life will not receive official updates from the maintainers. Visit the Next.js EOL policy for more information.
Users of the affected component should apply one of the following mitigations:
- Upgrade affected applications to a fixed version of Next.js.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.