High-severity Next.js flaw can expose cloud metadata and internal services

A high-severity vulnerability in Next.js can let attackers force vulnerable self-hosted servers to send requests to internal or external systems.

The flaw is tracked as CVE-2026-44578 and affects self-hosted Next.js applications that use the built-in Node.js server. Vercel-hosted deployments are not affected, according to the official advisory.

The issue creates a server-side request forgery risk through crafted WebSocket upgrade requests. In practical terms, an attacker may use the vulnerable server as a proxy to reach internal services that should not face the public internet.

What CVE-2026-44578 does

CVE-2026-44578 affects how Next.js handles WebSocket upgrade requests in some self-hosted deployments. The server may process a specially crafted request and forward it to a destination chosen by the attacker.

This matters because the request comes from the application server itself. Internal systems may trust that server more than they would trust a random external user.

That can expose private resources, internal APIs, cloud metadata endpoints, dashboards, or other services reachable from the origin server. The exact impact depends on how the application and its network are configured.

Item	Details
CVE	CVE-2026-44578
Advisory	GHSA-c4j6-fc7j-m34r
Severity	High, CVSS 3.1 score of 8.6
Weakness type	Server-side request forgery
Affected deployments	Self-hosted Next.js apps using the built-in Node.js server
Unaffected deployments	Vercel-hosted applications
Main risk	Access to internal services or cloud metadata endpoints

Which Next.js versions are affected

The official GitHub advisory says the vulnerability affects Next.js versions from 13.4.13 up to versions before 15.5.16. It also affects Next.js 16.0.0 up to versions before 16.2.5.

Next.js 15.5.16 and 16.2.5 fixed this specific SSRF issue. However, Vercel later published a broader May 2026 security release that addresses 13 advisories across Next.js and React Server Components.

For that wider security release, Vercel recommends upgrading Next.js 13.x and 14.x applications to 15.5.18 or 16.2.6. Next.js 15.x users should move to 15.5.18, while Next.js 16.x users should move to 16.2.6.

Why cloud credentials may be at risk

Server-side request forgery can become serious in cloud environments because many servers can reach metadata endpoints. These endpoints may expose temporary credentials, role data, or deployment information if protections are weak.

An attacker does not need direct internet access to those internal endpoints. The vulnerable Next.js server can become the middle point that sends the request.

That is why security teams should treat this as more than a framework bug. It can become a cloud and infrastructure issue if the server has broad outbound access.

• Cloud metadata endpoints may expose temporary access credentials.
• Internal admin panels may become reachable through the server.
• Private APIs may reveal sensitive application data.
• Network segmentation gaps can increase the blast radius.
• Public proof-of-concept details can increase scanning and testing activity.

Who needs to patch immediately

Teams running Next.js on their own servers, containers, virtual machines, or custom infrastructure should review their versions now. The issue mainly concerns self-hosted environments that use the built-in Node.js server.

Applications hosted on Vercel are not affected by this vulnerability, according to the advisory. Other managed platforms may also avoid exposure if they do not expose the vulnerable WebSocket upgrade path, but teams should confirm this with their provider.

Developers should not assume that a firewall alone protects the application. SSRF attacks use the server’s own network position, which can bypass assumptions about what external users can reach.

How to reduce exposure before upgrading

The safest fix is to upgrade Next.js. Vercel says patching is the only complete mitigation for the May 2026 security release.

If an immediate upgrade is not possible, administrators should avoid exposing the origin server directly to untrusted networks. A reverse proxy or load balancer can also block WebSocket upgrades when the application does not need them.

Security teams should also restrict outbound traffic from the origin server. The server should not freely reach cloud metadata services, internal dashboards, private databases, or unrelated internal networks.

1. Check the installed Next.js version in each application.
2. Upgrade to 15.5.18 or 16.2.6 where possible.
3. Confirm whether the app uses the built-in Node.js server.
4. Block WebSocket upgrade requests if the app does not need them.
5. Place origin servers behind a trusted reverse proxy or load balancer.
6. Restrict outbound access to metadata endpoints and internal networks.
7. Review logs for unusual WebSocket upgrade requests and internal URL access attempts.

The issue is part of a larger Next.js security release

CVE-2026-44578 is only one advisory in Vercel’s May 2026 Next.js security release. The update also covers issues involving middleware and proxy bypass, denial of service, cache poisoning, and cross-site scripting.

This makes the latest patch more important than a single CVE fix. Teams that only patch to the first fixed version may still miss later fixes from the coordinated release.

For production systems, developers should test and deploy the newest patched release supported by their application branch. They should also review custom rewrites, proxy rules, WebSocket usage, and network egress policies.

What developers should check next

Next.js powers many business dashboards, SaaS products, ecommerce systems, internal portals, and AI-built web apps. That makes even framework-level bugs important for security teams.

The highest-risk setups are self-hosted applications with direct internet exposure and broad access to internal services. Those systems should move to the front of the patching queue.

After upgrading, teams should still harden the environment. Good egress controls, metadata endpoint protections, and reverse proxy rules can reduce damage from future SSRF bugs.

FAQ