CVE-2026-64649

What it actually does

This vulnerability is a Server-Side Request Forgery (SSRF) issue in Next.js Server Actions. In affected versions, when a Server Action performs a forward or redirect, attacker-controlled Host-associated headers can influence the destination of the server-side outbound request. If an application accepts untrusted Host, X-Forwarded-Host, Forwarded, or similar headers instead of pinning them to a trusted value, the application server may be induced to contact an attacker-controlled host or, depending on routing and network access, unintended internal services. In some configurations, responses or derived internal values may be exposed in a way that weakens middleware or proxy authorization decisions. The issue affects Next.js 14.1.1 through 15.5.20 and 16.0.0 through 16.2.10 when Server Actions are used and the deployment does not reliably fix the incoming host value. Managed hosting that pins the host upstream is not affected, and `next start` and standalone output pin the host from version 14.2 onward.

Why it matters to the business

A vulnerable application may allow an external attacker to make the server send requests to destinations chosen by the attacker. This can expose sensitive internal information, bypass assumptions made by middleware or proxy authorization, and create a path to attack services that are not directly reachable from the internet. The CVSS vector indicates high confidentiality impact, although exploitation requires a particular deployment condition: the attacker must be able to control Host-associated headers and the application must use affected Server Actions. EPSS is currently low and the issue is not listed in CISA KEV, with no known public exploit maturity reported, but internet-facing custom Next.js deployments should still treat this as important because SSRF can become a pivot point into internal infrastructure.

How an attack unfolds

An attacker identifies a Next.js application using Server Actions and determines that the deployment accepts or trusts client-supplied Host-associated headers. The attacker sends a crafted request to a Server Action endpoint with a manipulated Host, X-Forwarded-Host, Forwarded, or related header so that when the action forwards or redirects, Next.js constructs an outbound request using attacker-influenced host data. The server then makes a request to a host chosen by the attacker. In a basic scenario, the attacker uses an external server they control to confirm SSRF by observing inbound requests from the victim application. In a more serious scenario, the attacker attempts to target internal network addresses, metadata services, service discovery endpoints, administrative panels, or authorization-sensitive middleware/proxy paths. If the application or middleware reflects, forwards, or otherwise exposes values from those internal interactions, the attacker may obtain information that helps bypass authorization checks or expand access.

How to fix it

Upgrade Next.js to a fixed version: 15.5.21 or later for the 15.x line, or 16.2.11 or later for the 16.x line. For applications on older 14.x releases, move to a supported fixed release path; note that `next start` and standalone output pin the host from 14.2 onward, but affected ranges begin at 14.1.1 and safe operation still depends on deployment mode and header handling. Ensure all custom servers and reverse proxies pin the canonical host to a trusted value and do not pass arbitrary client-supplied Host-associated headers into application logic. Configure edge proxies/load balancers to overwrite, not append, `Host`, `X-Forwarded-Host`, `Forwarded`, `X-Forwarded-Proto`, and related headers. Restrict outbound egress from application servers so they cannot reach cloud metadata endpoints, loopback-only administrative interfaces, RFC1918 networks, or sensitive internal services unless explicitly required. If immediate upgrade is not possible, mitigate by disabling or isolating affected Server Actions where feasible, enforcing a strict allowlist of accepted hostnames, rejecting requests with unexpected Host-associated headers, and applying network-layer SSRF protections.

How to confirm the fix worked

Confirm the application is running Next.js 15.5.21 or later, 16.2.11 or later, or a deployment mode/version combination that pins the host to a trusted value. Review `package.json`, lockfiles, container images, build artifacts, and runtime dependency inventories for `next` versions in the affected ranges: 14.1.1 through 15.5.20 and 16.0.0 through 16.2.10. Verify whether Server Actions are enabled or used. Test proxy behavior by sending requests with conflicting `Host`, `X-Forwarded-Host`, and `Forwarded` headers and confirming the application uses only the trusted canonical host and does not generate outbound requests to attacker-supplied domains. In staging, attempt a benign SSRF canary test using an external controlled callback domain and confirm no callback is received. Validate egress controls by confirming the application server cannot reach cloud metadata IPs, loopback administrative ports, or internal-only service ranges unless explicitly allowed.

Typical attack path

1. Find an internet-facing Next.js application running an affected version and using Server Actions.
2. Probe whether Host-associated headers are accepted from the client instead of being pinned by a trusted proxy or runtime.
3. Send a crafted Server Action request containing a malicious Host, X-Forwarded-Host, Forwarded, or similar header.
4. Trigger a Server Action path that performs a forward or redirect.
5. Observe whether the application server makes an outbound request to an attacker-controlled listener.
6. Iterate payloads to target internal hostnames, loopback addresses, cloud metadata addresses, or internal service ports reachable from the application server.
7. Use any returned or side-channel information to infer internal network layout, retrieve sensitive values, or weaken middleware/proxy authorization controls.

How to detect it

Review HTTP access logs, application logs, reverse proxy logs, WAF events, outbound proxy logs, DNS resolver logs, cloud flow logs, and firewall egress logs. Focus on requests to Server Action endpoints or application routes that perform redirects/forwards where the request includes unusual or mismatched `Host`, `X-Forwarded-Host`, `X-Forwarded-Server`, `X-Host`, `Forwarded`, or `X-Original-Host` headers. Look for a sequence where an inbound request with manipulated Host-associated headers is followed immediately by an outbound connection from the application server to an attacker-controlled domain, newly registered domain, public callback service, internal IP address, loopback address, link-local address, or cloud metadata endpoint. In proxy logs, compare the TLS SNI, HTTP Host, and forwarded-host values for mismatches. In DNS logs, look for application workloads resolving domains that appear in inbound Host-associated headers. In cloud and network telemetry, investigate attempted connections to `169.254.169.254`, `127.0.0.1`, `localhost`, RFC1918 addresses, Kubernetes service DNS names, internal service-discovery domains, or ports associated with internal admin panels. Because no specific public exploit string is known from the provided data, detection should emphasize behavioral correlation between malformed host headers and unexpected server-side egress.

• Host: 169.254.169.254
• X-Forwarded-Host: 169.254.169.254
• Forwarded: host=169.254.169.254
• Host: 127.0.0.1
• X-Forwarded-Host: 127.0.0.1
• Forwarded: host=127.0.0.1
• Host: localhost
• X-Forwarded-Host: localhost
• Forwarded: host=localhost
• X-Original-Host: 169.254.169.254
• X-Host: 169.254.169.254
• X-Forwarded-Server: 169.254.169.254
• X-Forwarded-Host: localhost
• Forwarded: host=localhost
• 169.254.169.254/latest/meta-data
• metadata.google.internal
• 169.254.169.254/metadata/instance
• 100.100.100.200/latest/meta-data
• 169.254.170.2
• localhost:3000
• 127.0.0.1:3000
• 127.0.0.1:8080
• 10.
• 172.16.
• 192.168.

What your security team should do

• Inventory all Next.js applications and identify those using Server Actions with `next` versions 14.1.1 through 15.5.20 or 16.0.0 through 16.2.10.
• Prioritize internet-facing custom-server deployments and deployments not behind a proxy or platform that pins the host header.
• Upgrade affected applications to Next.js 15.5.21 or 16.2.11 or later as applicable.
• Harden reverse proxy and load balancer configuration to overwrite untrusted Host-associated headers and enforce an allowlist of canonical application hostnames.
• Add outbound egress restrictions for application workloads, especially blocking access to cloud metadata services, loopback addresses, link-local addresses, and internal management networks.
• Search access logs and application logs for suspicious Host, X-Forwarded-Host, and Forwarded header manipulation, especially requests to Server Action endpoints followed by unusual outbound connections.
• Monitor DNS, proxy, firewall, and egress logs for application servers connecting to unexpected external domains, internal IP ranges, or metadata service addresses.
• If suspicious activity is found, rotate any secrets or tokens potentially exposed through metadata services, internal APIs, or middleware/proxy authorization flows.
• Add regression tests or security tests that verify Host header pinning and reject conflicting forwarded-host headers before future releases.