Open Proxy Risk: High-Severity Next.js SSRF Flaw Exposes Cloud Metadata Endpoints

The development framework Next.js has remediated a critical security vulnerability, designated as CVE-2026-44578, which afflicts applications deployed on self-hosted infrastructure utilizing the embedded Node.js server runtime. The flaw manifests as a Server-Side Request Forgery (SSRF) vector, a vulnerability class that permits an adversary to coerce the vulnerable host into dispatching arbitrary requests toward internal or external network destinations, thereby granting unauthorized access to assets shielded from the public internet. Deployments hosted natively on Vercel remain entirely unaffected.

The core architectural issue stems from the improper validation of incoming WebSocket protocol upgrade headers. An engineered request can manipulate the native Next.js server into functioning as an open proxy, forwarding telemetry to arbitrary endpoints. This behavior exposes internal administrative control panels, restricted service APIs, and cloud provider metadata endpoints—repositories that frequently harbor ephemeral IAM credentials, API bearer tokens, and deployment secrets.

The vulnerability compromises Next.js iterations spanning versions 13.4.13 through 15.5.16 and 16.0.0 through 16.2.5. Definitively patched releases have been deployed in Next.js 15.5.16 and 16.2.5. GitHub has classified the threat profile within the high-severity tier, while the National Vulnerability Database (NVD) maps the issue to CWE-918 with a calculated CVSS base score of 8.6.

Following the implementation of the security patch, Next.js enforces more rigorous validation structures on WebSocket handshake anomalies, effectively blocking arbitrary proxying actions absent explicit, secure routing configurations. Developers managing self-hosted infrastructure are urged to expedite the upgrade of the next package to a remediated version. In scenarios where immediate patch deployment is unfeasible, administrators should suppress protocol upgrade requests at the reverse proxy or load balancer tier, provided the application does not rely on active WebSocket connections.

As a secondary line of defense, security practitioners should implement restrictive egress firewalls on application servers. A Next.js runtime rarely requires unrestricted network visibility over adjacent internal subnets, cloud metadata links, or peripheral utility APIs. Enforcing the principle of least privilege at the network layer significantly mitigates the blast radius of SSRF exploits, ensuring resilience even if analogous software defects surface in future iterations.

Concurrently, Netlify released a technical advisory confirming that its deployments are immune to this vector; Netlify Functions and Edge Functions do not natively support WebSocket protocol transitions, rendering the problematic logic dead code within their ecosystem. Cloudflare similarly counselled immediate package remediation, cautioning organizations against an over-reliance on Web Application Firewalls (WAF), as underlying design structures within React and Next.js can occasionally elude edge-based firewall rule definitions entirely.