CVE-2026-64649: Vercel Next.js SSRF Vulnerability

CVE-2026-64649 Overview

CVE-2026-64649 is a Server-Side Request Forgery (SSRF) vulnerability in Vercel Next.js affecting versions 14.1.1 through 15.5.20 and 16.0.0 through 16.2.10. The flaw resides in the Server Actions request forwarding and redirect logic. When a Server Action forwards or redirects a request, an attacker who can control Host-associated headers can cause the server to send the outbound request to an attacker-controlled host. In some configurations, this behavior also exposes internal values that weaken middleware and proxy authorization. The vulnerability is patched in Next.js 15.5.21 and 16.2.11.

Critical Impact
Attackers can coerce Next.js Server Actions into issuing outbound requests to malicious hosts, enabling SSRF and disclosure of internal authorization values on custom or non-proxied deployments.

Affected Products

Vercel Next.js versions 14.1.1 through 15.5.20
Vercel Next.js versions 16.0.0 through 16.2.10
Custom server deployments and deployments not behind a proxy that pins the host

Discovery Timeline

2026-07-27 - CVE-2026-64649 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-64649

Vulnerability Analysis

The vulnerability is classified as SSRF [CWE-918]. Next.js Server Actions forward requests between internal workers when handling POST-based mutations and redirects. The forwarding logic derived the outbound origin from the incoming Host header when the __NEXT_PRIVATE_ORIGIN environment variable was not set. An attacker who can control Host-associated headers on an unfixed deployment can redirect the internal fetch to a hostname of their choosing. The result is a server-issued request to an attacker-controlled endpoint. In some configurations, the forwarded request also carries internal headers or values that middleware and proxies rely on for authorization decisions. Applications behind managed hosting or next start in standalone mode from version 14.2 onward pin the host upstream and are not affected.

Root Cause

The vulnerable code path in packages/next/src/server/app-render/action-handler.ts constructed the forwarding origin using ${proto}://${host.value}, where host.value was taken from the incoming request headers. Because the Host header is client-controllable on servers that do not pin it, the resulting fetchUrl could point at any host.

Attack Vector

Exploitation requires a network-reachable Next.js application running an affected version on a custom server or a deployment that does not pin the host at the proxy layer. The attacker sends a crafted POST to a Server Action endpoint with a manipulated Host header. The server then issues an internal forwarded fetch to the attacker-specified host, carrying forwarded headers such as x-action-forwarded.

typescript

// Patch: packages/next/src/server/app-render/action-handler.ts
// The origin is no longer derived from the request Host header.
  forwardedHeaders.set('x-action-forwarded', '1')

-  const proto =
-    getRequestMeta(req, 'initProtocol')?.replace(/:+$/, '') || 'https'
-
-  // For standalone or the serverful mode, use the internal origin directly
-  // other than the host headers from the request.
-  const origin = process.env.__NEXT_PRIVATE_ORIGIN || `${proto}://${host.value}`
+  // TODO: Remove __NEXT_PRIVATE_ORIGIN
+  let origin: string | undefined = process.env.__NEXT_PRIVATE_ORIGIN
+  if (origin === undefined) {
+    const initUrl = getRequestMeta(req, 'initURL')
+    if (initUrl !== undefined) {
+      try {
+        const parsedUrl = new URL(initUrl)
+        origin = parsedUrl.origin
+      } catch (error) {
+        throw new Error(
+          'Could not determine origin for forwarded Server Actions request. This can happen if port or hostname are not configured for this server.',
+          { cause: error }
+        )
+      }
+    } else {
+      throw new InvariantError('Missing initURL')
+    }
+  }

   const fetchUrl = new URL(`${origin}${basePath}${workerPathname}`)

Source: GitHub Next.js Commit b512063

Detection Methods for CVE-2026-64649

Indicators of Compromise

Outbound HTTP requests from Next.js server processes to unexpected external hostnames, particularly requests carrying the x-action-forwarded: 1 header.
Incoming requests to Server Action endpoints containing Host headers that do not match the application's configured hostname.
Application error logs referencing Invalid target hostname for proxy requests after patching, indicating attempted exploitation.

Detection Strategies

Inspect reverse proxy and load balancer logs for requests where the Host header differs from the expected canonical host of the application.
Correlate Server Action POST requests with subsequent outbound connections from the Node.js process to identify anomalous fetch destinations.
Audit Next.js application logs for stack traces referencing action-handler.ts and forwarded request failures.

Monitoring Recommendations

Enable egress network monitoring on hosts running Next.js to detect connections to non-allowlisted destinations.
Alert on any Server Action request whose Host header value is not in the set of trusted hostnames for the deployment.
Track version inventories of Next.js packages across development, staging, and production to identify unpatched instances.

How to Mitigate CVE-2026-64649

Immediate Actions Required

Upgrade Next.js to version 15.5.21 for the 15.x branch or 16.2.11 for the 16.x branch.
Audit all deployments using custom servers or configurations that do not sit behind a host-pinning proxy.
Review Server Action code paths for reliance on request-derived origins or Host headers.

Patch Information

The issue is fixed in Next.js 15.5.21 and 16.2.11. The patch replaces Host-header-derived origin construction with an origin parsed from initURL request metadata, and throws when the origin cannot be determined. See the GitHub Security Advisory GHSA-89xv-2m56-2m9x, the Next.js v15.5.21 release notes, and the Next.js v16.2.11 release notes.

Workarounds

Place the Next.js application behind a reverse proxy that pins the Host header to a trusted value before requests reach the Node.js server.
Use managed hosting, or run next start or the standalone output on version 14.2 or later, which pins the host upstream.
Set the __NEXT_PRIVATE_ORIGIN environment variable to the trusted internal origin so that forwarded Server Action requests do not rely on incoming headers.

bash

# Nginx example: pin the Host header to a trusted value before proxying to Next.js
location / {
    proxy_set_header Host app.example.com;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:3000;
}

# Alternatively, set the internal origin explicitly for the Next.js process
export __NEXT_PRIVATE_ORIGIN="https://app.example.com"