Next.js WebSocket Upgrade SSRF (CVE-2026-44578): Patch Self-Hosted Deployments, Jump to 15.5.18 or 16.2.6 Not 15.5.16 / 16.2.5

On May 6, 2026, Vercel's Next.js maintainer Tim Neutkens published GHSA-c4j6-fc7j-m34r, tracked as CVE-2026-44578; Vercel followed on May 7 with a coordinated Next.js May 2026 security release changelog covering 13 advisories total (12 disclosed May 6 plus the May 7 Turbopack incomplete-fix follow-up). The SSRF itself is a pre-auth server-side request forgery reachable via the WebSocket upgrade handler in self-hosted Next.js applications using the built-in Node.js server. An unauthenticated attacker who can reach the Next.js origin can cause it to proxy HTTP requests to arbitrary internal or external destinations, including cloud instance metadata services (IMDS) and any internal-only service reachable from the origin host. The MITRE CVE record (published May 13, 2026) lists CVSS 3.1 base 8.6 HIGH with vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N and weakness class CWE-918. Affected versions: next >= 13.4.13 < 15.5.16 and >= 16.0.0 < 16.2.5. Vercel-hosted deployments are explicitly not affected. Patch to 15.5.18 or 16.2.6, not the minimum 15.5.16 / 16.2.5 called out for this CVE specifically, so you also pick up the May 7 follow-up advisory for the Turbopack-incomplete-fix issue and the rest of the coordinated cluster.

Framing note: this bulletin is scoped to the WebSocket upgrade SSRF. The coordinated release covers 13 advisories total, including the May 7 follow-up, spanning middleware/proxy bypass, App Router segment-prefetch bypass, Pages Router i18n bypass, RSC cache poisoning, App Router CSP-nonce XSS, image-optimizer DoS, and a Cache Components connection-exhaustion DoS. Several of those are individually high-severity for the right deployment shape, but the SSRF is the one with the clearest "internal-network-pivot" blast radius for self-hosted operators, and is the bulletin trigger. The fix matrix below targets 15.5.18 / 16.2.6 because that is the version pair that covers the whole cluster; treat 15.5.16 / 16.2.5 as a hard minimum if you genuinely cannot move that one extra patch level.

Affected versions, fix matrix, and what is not affected

Priorities, by deployment

Triage on three axes: is the deployment self-hosted on the built-in Node.js server (versus Vercel, Netlify Functions, or a fully static export), is the Next.js origin reachable from untrusted networks (directly or via a permissive reverse proxy), and does the origin host have access to anything sensitive on the inside (cloud IMDS, internal admin services, database admin panels, sidecar processes).

Prioritization above is this bulletin's framing, anchored to the GHSA's "self-hosted Node.js server" affected-configuration statement, Netlify's May 8 customer-facing changelog for the Netlify-not-affected determination, and the standard SSRF-to-IMDS-to-IAM pivot pattern that determines real-world blast radius on cloud VMs.

Am I affected?

Check your installed Next.js version

In each project that depends on next:

npm ls next
# or
pnpm why next
# or
yarn why next

A resolved version in the range >= 13.4.13 < 15.5.16 or >= 16.0.0 < 16.2.5 is affected if the application is self-hosted on the built-in Node.js server (next start or a custom server that wraps the Next.js request handler). A resolved version < 13.4.13 pre-dates the vulnerable handler. Anything >= 15.5.16 on the 15.x line or >= 16.2.5 on the 16.x line carries the CVE-specific fix; >= 15.5.18 or >= 16.2.6 additionally carries the May 7 Turbopack follow-up.

Check how the app is hosted

If deployed via Vercel: the platform mitigates this CVE, independent of dependency version. If deployed via Netlify Functions or Edge Functions only: not affected for this CVE. If deployed via Docker / Kubernetes / a VM running next start or a custom Node server: affected, patch the dependency.

Quick external-exposure inventory

For an inventory across an organization, the Modat Magnify external-attack-surface query technology="Next.js" returns internet-reachable hosts whose response headers identify Next.js. Treat this as a starting inventory, not a vulnerability determination: the query does not distinguish Vercel-hosted from self-hosted, does not return the framework version, and will list patched instances alongside vulnerable ones. For each host returned that you own, confirm the hosting model and the resolved next version against the patch matrix above before acting.

Response steps

If you self-host on the built-in Node.js server (Highest / Higher)

1. Upgrade the next dependency to 15.5.18 or 16.2.6. Not 15.5.16 / 16.2.5. The one-extra-patch jump costs nothing, clears the Turbopack-incomplete-fix follow-up, and avoids a second deploy when the rest of the May 6 / May 7 cluster lands in your next vulnerability scan.

   npm install next@15.5.18    # for 15.x lines
   npm install next@16.2.6    # for 16.x lines

   Earlier minors of 15.x and 16.x will not be backported per Vercel and Netlify guidance; if you are on, e.g., 15.3.x or 16.1.x, the upgrade is to the patched minor, not a hotfix on your current minor.
2. Rebuild and redeploy. Verify the resolved version is the patched one by running npm ls next against the deployed artifact (in the container or on the host, not just in CI). Lockfile-resolution surprises are the most common reason a patched-in-package.json deploy is still actually vulnerable.
3. Lock down cloud instance metadata. Independent of the Next.js patch, harden the metadata-service posture on every cloud VM that hosts a self-hosted Next.js origin. The controls are cloud-specific, not interchangeable.

   # AWS: enforce IMDSv2 (token-based) with PUT response hop-limit 1.
   # Hop-limit 1 prevents containers and reverse proxies from reaching
   # IMDS via an extra network hop.
   aws ec2 modify-instance-metadata-options \
     --instance-id <id> \
     --http-tokens required \
     --http-put-response-hop-limit 1 \
     --http-endpoint enabled
   
   # GCP: metadata requests already require Metadata-Flavor: Google.
   # An SSRF that doesn't set arbitrary headers cannot read GCE metadata.
   # Verify your application HTTP client cannot be coerced into setting
   # that header from a user-controlled value. Additionally, prefer
   # Workload Identity over instance service accounts where possible.
   
   # Azure: IMDS already requires Metadata: true header and only responds
   # on the link-local address 169.254.169.254. Same header-coercion
   # caveat as GCP applies. Prefer managed identities scoped to the
   # minimum required resources.
   
   # DigitalOcean: no header- or token-based protection on metadata.
   # Block 169.254.169.254 at the host firewall on droplets that do not
   # need it at runtime. iptables example, droplet-local:
   sudo iptables -I OUTPUT -d 169.254.169.254 -m owner ! --uid-owner root -j DROP
   
   # Oracle Cloud: enable IMDSv2 (HTTP-only token-based) per the
   # Instance Metadata Service v2 documentation and disable v1 fallback.
   
   # Alibaba Cloud: enable hardened mode (token required) on the ECS
   # Metadata Service via DescribeInstance / ModifyInstanceMetadataOptions.

   These are defense-in-depth controls against this specific SSRF and against the broader class of pre-auth and post-auth SSRF that will keep appearing in web frameworks. Verify your chosen control with a synthetic SSRF probe (curl from the host against 169.254.169.254 with and without the required header / token) before considering the host hardened.
4. If you cannot patch immediately, harden at the reverse proxy. Per Vercel's own interim guidance: if the application does not require WebSocket upgrades, block them at the reverse proxy or load balancer. In nginx:

   if ($http_upgrade != "") {
       return 403;
   }

   If WebSockets are required, restrict Upgrade handling to known WebSocket paths only, and reject upgrade requests on any other route. Strip internal headers (x-forwarded-for spoofing, internal-only auth headers) from untrusted traffic at the proxy.
5. Restrict origin egress. The SSRF is only as bad as what the Next.js origin host can reach. Cloud security groups, host-level egress firewalls, and Kubernetes NetworkPolicies can all be used to deny outbound to 169.254.0.0/16 (IMDS), to known-internal subnets the Next.js origin has no business calling, and to arbitrary external destinations beyond the allowed list. This is good hygiene independent of this CVE; the CVE makes it acute.
6. Treat any Next.js origin internet-exposed during the disclosure-to-patch window as potentially probed. No confirmed in-the-wild exploitation is public as of this bulletin's publication, but PoCs are. Based on public PoC behavior, review HTTP access logs on the origin and on the upstream proxy for anomalous Upgrade: websocket requests, particularly those with absolute-form request lines pointing at internal addresses (e.g. GET http://169.254.169.254/... or GET http://10.x.x.x:... in the request line rather than a path), and for outbound requests from the origin host to the cloud metadata service, to internal admin services, or to unexpected external destinations during the window. These are heuristics derived from public PoC code, not vendor-confirmed signatures; absence of such evidence is not proof of safety, but presence is a strong signal worth investigating.

If you host on Vercel (Lower)

1. No action required for CVE-2026-44578. The vendor advisory explicitly excludes Vercel-hosted deployments. The platform does not expose the vulnerable upgrade code path.
2. Still upgrade next for the rest of the cluster. Several of the other May 6 advisories (middleware/proxy bypass, RSC cache poisoning, App Router CSP-nonce XSS) do affect Vercel-hosted apps and require an application-side framework upgrade. Target 15.5.18 or 16.2.6 here too.

The broader pattern

A few observations worth flagging in the context of this bulletin's series:

First, this is the second pre-auth SSRF in self-hosted Next.js in less than a year. CVE-2025-57822, disclosed September 2025, was an SSRF in Next.js middleware redirect handling when next() was called without explicitly passing the request object. The shape is different (that one required a specific custom-middleware pattern), but the operational lesson is identical: "self-hosted Next.js on the built-in Node.js server" is a meaningfully different security posture from Vercel-hosted, and the gap is widening as the framework grows more features that the platform-side compensates for and the self-hosted-side does not. Operators who self-host should plan for "SSRF-class CVE in the request pipeline" as a recurring threat-model entry, not a one-off, and cloud metadata-service hardening (per the per-cloud controls above) should be table stakes regardless of framework patch state.

Second, May 2026 continues a noisy patch month for operators with diverse stacks: cPanel CVE-2026-41940 (April 28, exploited in the wild, ransomware payloads), Copy Fail CVE-2026-31431 (April 29, CISA KEV, WSL2 implications), DAEMON Tools supply-chain (May 5), PAN-OS CVE-2026-0300 (May 6, exploited in the wild), Ollama Bleeding Llama and Windows Auto-Update RCE (May 10), mistralai PyPI 2.4.6 compromise (May 12), and now the Next.js cluster. Triage ruthlessly; for shops with self-hosted Next.js exposed to the internet, this one belongs in the upper half of the list.

Third, "the platform protects you" is now a load-bearing assumption in modern JavaScript framework security. Vercel hosting handles this CVE because of how Vercel's request router gates upgrade handling, not because the framework code is different. Netlify Functions handle it by not supporting the code path at all. Operators choosing self-hosted Next.js for cost, sovereignty, or air-gap reasons inherit the security-engineering work that the platforms do silently for everyone else. That tradeoff is fine, but it should be a conscious one with corresponding investment in egress hardening, IMDS lockdown, and dependency-update SLAs.