Next.js High-Severity SSRF CVE-2026-44578: Impact Scope and Upgrade Guidance

Sun, 17 May 2026 17:27:13 +0800

Next.js disclosed a high-severity SSRF vulnerability in May 2026: CVE-2026-44578.

According to the GitHub / Vercel advisory GHSA-c4j6-fc7j-m34r and the NVD record, the issue affects self-hosted Next.js applications that use the built-in Node.js server and are exposed to malicious WebSocket upgrade requests. An attacker may cause the server to proxy requests to arbitrary internal or external destinations, exposing internal services or cloud metadata endpoints.

Vercel-hosted deployments are not affected. The fixed versions are 15.5.16 and 16.2.5.

Short Version

If you run Next.js on your own servers, containers, Kubernetes, ECS, VPS, bare metal, or a self-managed PaaS, check this first.

Affected ranges:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Unaffected or lower-risk cases:

Applications deployed on Vercel.
Applications upgraded to 15.5.16, 16.2.5, or later.
Deployments that do not expose the built-in Node.js server.
Environments where reverse proxies or load balancers already block unnecessary WebSocket upgrades and outbound access is restricted.

Recommended response order:

Confirm the next version actually running in production.
Upgrade self-hosted applications to a patched version as soon as possible.
If you cannot upgrade immediately, block unnecessary WebSocket upgrades at the reverse proxy or load balancer.
Restrict application servers from reaching cloud metadata, internal admin panels, and sensitive internal services.
Review recent WebSocket upgrade requests and internal access logs.

What the Vulnerability Is

CVE-2026-44578 is a Server-Side Request Forgery vulnerability, or SSRF.

The core risk of SSRF is that an attacker does not access internal systems directly. Instead, they make your server send requests on their behalf. Servers often sit closer to private networks, cloud platforms, and internal services, so if a server becomes a proxy, it may reach resources the attacker could not otherwise access.

In this Next.js case, the issue is in the WebSocket upgrade handling path. The advisory says that self-hosted applications using the built-in Node.js server can be made to proxy requests to arbitrary internal or external destinations through crafted WebSocket upgrade requests.

Risk areas include:

Internal HTTP services.
Admin panels.
Cloud metadata endpoints.
Container or cluster-internal services.
Internal APIs that only the server can reach.

The CVSS v3.1 score is 8.6 High, with this vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

That means the attack is network reachable, low complexity, requires no privileges or user interaction, and primarily affects confidentiality.

Why Self-Hosting Is Riskier

The advisory explicitly states that Vercel-hosted deployments are not affected.

The focus is self-hosted deployments. Their network environments vary widely: some expose the origin server directly, some sit behind Nginx, Traefik, Ingress, Cloudflare, ALB, or a custom gateway, and some run in cloud VMs, container networks, or Kubernetes clusters.

If outbound traffic is not restricted, the Next.js process may be able to reach:

Cloud metadata addresses such as 169.254.169.254.
Private IP ranges.
Services exposed only inside a VPC.
Internal Redis, Elasticsearch, Prometheus, Grafana, and similar components.
Kubernetes Services, Pods, or management endpoints.

So the danger is not only in Next.js itself. It depends on what the Next.js server can access from its network position.

How to Check Exposure

First, check the next version.

Run this in the project directory:

`1`	`npm ls next`

Or:

`1`	`pnpm why next`

You can also inspect:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

If the version falls in these ranges, you need to act:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Second, check the deployment model.

Pay close attention to:

Production services started with next start.
Custom Node.js servers hosting Next.js.
Docker images that start a Next.js server directly.
Kubernetes / ECS / VPS / bare-metal self-hosting.
A Next.js origin still reachable behind a reverse proxy.
Application networks that can reach internal services or cloud metadata.

If the application is deployed on Vercel, the official advisory says it is not affected by this vulnerability. Still, keep Next.js updated, because adjacent releases may contain other security fixes.

What Version to Upgrade To

The official patched versions are:

15.5.16
16.2.5

Upgrade example:

`1`	`npm install next@15.5.16`

Or, if you are on 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

Or:

`1`	`pnpm add next@16.2.5`

Then rebuild and redeploy:

1
2

npm run build
npm run start

Or follow your CI/CD process to rebuild and publish the Docker image.

If your project is pinned to 14.x or 15.x, do not rush into a major upgrade to 16.x just for this fix. A safer path is to upgrade to the 15.5.16 patch line first, test and release, then plan a major-version migration separately.

Temporary Mitigations

If you cannot upgrade immediately, the advisory’s core guidance is: do not expose the origin server directly to untrusted networks; block WebSocket upgrades at the reverse proxy or load balancer if they are not required; and restrict outbound access from the origin where possible.

Consider these mitigations:

Do not expose the Next.js origin server directly.
Filter unnecessary WebSocket upgrades at Nginx, Ingress, ALB, Cloudflare, or similar entry points.
If the business does not use WebSockets, reject requests with upgrade semantics.
Apply egress restrictions to block access to cloud metadata and sensitive internal ranges.
Use safer cloud metadata modes where available, such as token-required metadata services.
Add authentication and network isolation around admin panels, databases, caches, and monitoring systems.

Reverse proxy rules are temporary mitigations, not a replacement for upgrading. Framework vulnerabilities should ultimately be fixed by moving to patched versions.

Operational Review

Because this issue mainly affects confidentiality, the key question is whether the server was used to reach internal resources.

Review:

Web logs for abnormal Upgrade, Connection, Host, paths, and source IPs.
Reverse proxy or load balancer logs for unusual WebSocket upgrade requests.
Abnormal outbound connections near the Next.js service.
Cloud metadata access logs or credential usage records.
Unusual access to internal admin services, monitoring, caches, or search systems.
Abnormal IAM temporary credential, access key, or token usage.
Suspicious processes, downloads, or lateral movement on containers or hosts.

If exploitation is suspected:

Preserve logs and evidence.
Rotate potentially exposed cloud credentials, API keys, database passwords, and session secrets.
Review recent cloud account API calls.
Check internal service access records.
Rebuild affected containers or hosts.
Revisit egress controls and metadata protection.

Not the Same as the React/Next.js RCE

One common source of confusion: CVE-2026-44578 is a Next.js WebSocket upgrade SSRF, not the earlier React Server Components RCE.

Its core impact is making the server request attacker-chosen internal or external addresses. The main risk is information exposure and internal resource probing.

React Server Components RCE issues are code execution risks, with different consequences and patch ranges.

So do not stop at the headline “Next.js has a vulnerability.” Map the exact CVE to the affected versions, deployment model, and fixed versions.

Teams That Should Prioritize This

Highest priority:

Self-hosted Next.js production sites.
Deployments on cloud VMs, containers, Kubernetes, or internal networks.
Application servers that can access cloud metadata services.
Application servers that can reach internal admin panels, databases, caches, or monitoring systems.
Directly exposed next start origin servers.
Older next versions with unclear upgrade ownership.

Lower priority:

Applications fully deployed on Vercel.
Applications already upgraded to patched versions.
Origins not directly exposed, with entry layers blocking unnecessary WebSocket upgrades.
Strict outbound network control preventing access to sensitive internal resources.

Lower priority does not mean “do not upgrade.” Next.js is a high-exposure framework, and long-stale framework versions accumulate risk quickly.

Developer Checklist

Use this checklist:

Confirm the next version in every repository.
Identify all self-hosted deployments, not only Vercel projects.
Mark services using next start or the built-in Node.js server.
Upgrade to 15.5.16, 16.2.5, or later.
Rebuild and publish production images.
Block unnecessary WebSocket upgrades at the entry layer.
Restrict application server access to cloud metadata and sensitive internal ranges.
Review recent abnormal upgrade requests and outbound access.
Rotate credentials that may have been exposed.
Add Next.js security updates to the dependency update process.

Summary

CVE-2026-44578 is a high-severity Next.js SSRF vulnerability that deserves prompt attention.

It does not affect Vercel-hosted deployments, but it covers a broad range of self-hosted Next.js applications: from 13.4.13 up to before 15.5.16, and from 16.0.0 up to before 16.2.5. The trigger is the WebSocket upgrade handling path. An attacker may cause the server to proxy requests to internal or external addresses, potentially exposing internal services or cloud metadata endpoints.

The direct fix is to upgrade to 15.5.16 or 16.2.5. Temporary mitigations are to avoid exposing the origin server directly, block unnecessary WebSocket upgrades, and restrict outbound access from the application server.

For operations teams, the important point is not only the CVE score. It is what your Next.js server can reach from its network position. With SSRF, the real impact often depends on internal resources and cloud permissions behind the server.

References:

WebSocket on KnightLi Blog