CVE-2026-44578

What it actually does

This vulnerability is a server-side request forgery (SSRF) issue in self-hosted Next.js applications that use the built-in Node.js server. In affected versions from 13.4.13 through versions before 15.5.16 and before 16.2.5, crafted WebSocket upgrade requests can cause the application server to proxy attacker-controlled requests to arbitrary internal or external destinations. Because the request originates from the server-side runtime, an attacker may reach network locations that are not directly accessible from the internet, including internal HTTP services, administrative interfaces, service discovery endpoints, and cloud instance metadata services. The CVSS scope change and high confidentiality impact reflect the risk of crossing a trust boundary and exposing sensitive internal data without authentication.

Why it matters to the business

Organizations running affected self-hosted Next.js applications may have internal services or cloud metadata exposed through a public-facing web application. Successful exploitation could lead to disclosure of credentials, tokens, configuration data, internal API responses, or other sensitive information that supports further compromise. The issue is especially urgent because exploitation is considered weaponized, the attack is unauthenticated and network-reachable, and the EPSS score indicates meaningful exploitation likelihood. Vercel-hosted deployments are not affected, but self-managed Node.js deployments should be treated as high priority.

How an attack unfolds

An attacker first identifies a publicly reachable self-hosted Next.js application running an affected version and using the built-in Node.js server. The attacker then sends a specially crafted HTTP request that attempts to initiate a WebSocket upgrade while controlling routing or destination-related values used by the server. Due to the flaw, the Next.js server may proxy the resulting request to an attacker-selected internal or external URL. The attacker iterates through common internal targets such as localhost services, RFC1918 network ranges, Kubernetes or service-mesh endpoints, and cloud metadata addresses. If responses are returned or behavior differs based on reachability, the attacker can enumerate internal services and retrieve sensitive data such as metadata credentials, internal API responses, or configuration details. The attacker may then use any obtained secrets or internal knowledge to pivot into cloud resources, application backends, or administrative services.

How to fix it

Upgrade affected self-hosted Next.js applications to a fixed version immediately. Applications on the 15.x line should upgrade to Next.js 15.5.16 or later, and applications on the 16.x line should upgrade to Next.js 16.2.5 or later. Applications running versions from 13.4.13 onward and before these fixed releases should be considered vulnerable if they use the built-in Node.js server in a self-hosted deployment. If immediate upgrade is not possible, restrict network egress from the application runtime so it cannot reach cloud metadata endpoints, localhost-only administrative services, private RFC1918 ranges, link-local addresses, or other sensitive internal destinations unless explicitly required. Place egress controls at the container, host, firewall, Kubernetes network policy, service mesh, or cloud security group layer. Block or tightly validate unexpected WebSocket upgrade traffic at reverse proxies and web application firewalls where feasible. Ensure cloud metadata services require hardened controls such as IMDSv2 on AWS and equivalent protections on other platforms. Vercel-hosted deployments are not affected, but any self-hosted copy of the application should still be inventoried and validated.

How to confirm the fix worked

Confirm exposure by inventorying all Next.js applications and determining whether they are self-hosted with the built-in Node.js server. Validate the installed Next.js package version through package-lock.json, pnpm-lock.yaml, yarn.lock, npm ls next, pnpm why next, yarn why next, container image SBOMs, or runtime build metadata. The application should report Next.js 15.5.16 or later for the 15.x branch, or 16.2.5 or later for the 16.x branch. Validate that production images and deployed artifacts have been rebuilt after dependency updates, not just source repositories patched. Test network egress controls from the application runtime to confirm that requests to 169.254.169.254, localhost, loopback ranges, RFC1918 addresses, and other sensitive internal endpoints are denied unless explicitly required. Review reverse proxy behavior to ensure unexpected WebSocket upgrade requests are logged and, where appropriate, blocked.

Typical attack path

1. Scan the internet or target a known public application to identify self-hosted Next.js deployments.
2. Confirm the application is plausibly running an affected Next.js version using response behavior, headers, static asset paths, build artifacts, or framework-specific routes.
3. Send crafted WebSocket upgrade requests designed to make the server proxy traffic to an attacker-controlled destination.
4. Change the requested destination to internal targets such as localhost, private IP ranges, container network services, or cloud metadata endpoints.
5. Analyze response content, timing, status codes, and error messages to determine which internal services are reachable.
6. Extract sensitive information if internal endpoints return credentials, tokens, configuration, or application data.
7. Use any exposed secrets or service information to escalate access, pivot to cloud resources, or attack internal applications.

How to detect it

Investigate whether the vulnerability was already exploited by reviewing HTTP access logs, reverse proxy logs, application logs, WAF logs, CDN logs, container logs, and cloud network telemetry for suspicious WebSocket upgrade activity. Focus on requests with headers such as Upgrade: websocket and Connection: Upgrade combined with unusual Host values, absolute URLs, encoded destinations, internal IP addresses, localhost references, or cloud metadata endpoints. Look for outbound connections from the application server or container to 169.254.169.254, 127.0.0.1, ::1, RFC1918 ranges, Kubernetes service addresses, internal DNS zones, or administrative service ports shortly after inbound WebSocket upgrade requests. Correlate inbound source IPs with bursts of probing across many destinations, varied encodings, unusual 101 Switching Protocols responses, 3xx redirects, 4xx/5xx errors, or anomalous response sizes. Cloud environments should review metadata service access logs where available, identity provider logs, cloud audit logs, and unusual use of temporary credentials following suspicious requests. If metadata credentials may have been exposed, search for subsequent cloud API activity from unfamiliar IP addresses, regions, user agents, or sessions associated with the affected workload identity. Because the issue is weaponized, absence of a single known exploit string is not sufficient; detection should combine header analysis, destination indicators, egress telemetry, and post-exploitation credential-use review.

• Upgrade: websocket
• Connection: Upgrade
• Sec-WebSocket-Key:
• Sec-WebSocket-Version:
• 169.254.169.254
• http://169.254.169.254
• http://169.254.169.254/latest/meta-data/
• http://169.254.169.254/latest/api/token
• metadata.google.internal
• http://metadata.google.internal/computeMetadata/v1/
• 169.254.169.254/metadata/instance
• http://169.254.169.254/metadata/instance
• 127.0.0.1
• http://127.0.0.1
• localhost
• http://localhost
• [::1]
• http://[::1]
• 0.0.0.0
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.
• %31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34
• %6c%6f%63%61%6c%68%6f%73%74
• latest/meta-data
• latest/api/token
• computeMetadata/v1
• Metadata-Flavor: Google
• Metadata: true

What your security team should do

• Prioritize immediate patching of all internet-facing, self-hosted Next.js applications because exploitation is weaponized and does not require authentication.
• Inventory all Next.js deployments and separate Vercel-hosted applications from self-hosted Node.js server deployments; focus remediation on the latter.
• Upgrade to Next.js 15.5.16 or later on the 15.x branch, or 16.2.5 or later on the 16.x branch, and redeploy rebuilt production artifacts.
• Implement deny-by-default egress controls for application runtimes, with explicit blocks for cloud metadata endpoints, loopback, link-local, and private network ranges unless business-required.
• Review access logs for suspicious WebSocket upgrade requests, especially those associated with internal hostnames, IP literals, metadata endpoints, encoded URLs, or unusual Host and Upgrade header combinations.
• Harden cloud metadata access, including enforcing token-based metadata access where supported and limiting instance or workload identity permissions to least privilege.
• Rotate credentials and tokens if logs or telemetry suggest the application may have reached metadata endpoints or sensitive internal services.
• Add SIEM detections for WebSocket upgrade requests containing internal IP ranges, localhost references, link-local addresses, or URL-encoded variants.
• Run targeted incident response on high-value applications to look for evidence of internal service enumeration or metadata credential exposure.
• Track EPSS and vendor advisories for changes in exploitation activity and re-prioritize any remaining unpatched systems accordingly.