🚨 New Next.js CVE: CVE-2026-44578. High-severity SSRF via WebSocket Upgrade handling in self-hosted Next.js apps using the built-in Node.js server. Unauthenticated. Network-reachable. CVSS 8.6 High. Vercel-hosted deployments are not affected. If you run Next.js on your own infra, read on 🧵

What happens? A crafted WebSocket Upgrade request can make the Next.js server proxy traffic to an attacker-controlled destination. In self-hosted environments, that can expose internal services, cloud metadata endpoints, or other network-reachable resources from the Next.js host.

Root cause / fix: WebSocket Upgrade handling missed safety checks that already existed for normal HTTP request proxying. The patch applies those checks to Upgrade handling, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.

Affected versions: next >= 13.4.13, < 15.5.16 next >= 16.0.0, < 16.2.5 Fixed in: 15.5.16 16.2.5 Quick check from your project: ``` node -p "require('next/package.json').version ```

Mitigation if you can't patch immediately: - Don't expose the origin Next.js server directly to untrusted networks - Block WebSocket upgrades at your reverse proxy / LB if you don't need them - Reject unexpected absolute-URL request lines - Restrict egress from the Next.js host, especially to metadata and internal-only services

Important: don't rely only on WAF coverage here. Some providers say a safe generic WAF rule for this SSRF class may break legitimate application behavior. Patch first, then use edge filtering and egress controls as defense-in-depth.

References: - github.com/vercel/next.js… - github.com/dwisiswant0/ne…