Next.js SSRF Vulnerability Leaks Cloud Credentials and API Keys from Self-Hosted Apps

Next.js, one of the world's most widely used React frameworks, is putting thousands of organizations at risk of credential theft, API key exposure, and unauthorized access to internal admin panels. The vulnerability, disclosed this week, requires no credentials and no user interaction to exploit. That combination makes it particularly dangerous for any team running Next.js in production on their own infrastructure.

On May 11, 2026, Vercel published GHSA-c4j6-fc7j-m34r and released Next.js 15.5.16 and 16.2.5, fixing CVE-2026-44578, a server-side request forgery vulnerability in the WebSocket upgrade handler that affects all self-hosted Next.js deployments from 13.4.13 onward. If you haven't patched yet, stop reading and go do that first.

Sampling of directly-exposed Shodan-indexed Next.js hosts on the default port suggests approximately 79,000 instances are exploitable today. That's not a small tail risk.

---

What Is CVE-2026-44578?

CVE-2026-44578 details a Server-Side Request Forgery (SSRF) vulnerability affecting self-hosted Next.js applications using the built-in Node.js server, rated 8.6 (High) on the CVSS scale. SSRF, for those less familiar, is an attack class where a server is tricked into making outbound HTTP requests on behalf of an attacker, typically to internal resources that should never be reachable from the public internet.

In CVE-2026-44578, the vulnerability exists in Next.js's HTTP/1.1 WebSocket upgrade handler in packages/next/src/server/lib/router-server.ts. When a client sends an HTTP Upgrade request with Connection: Upgrade and Upgrade: websocket headers, the upgrade handler calls resolveRoutes to determine the request's destination.

The vulnerable handler then checks only parsedUrl.protocol before forwarding to proxyRequest, ignoring the finished and statusCode flags that the equivalent HTTP request handler already enforces. That missing check is the entire root cause. One incomplete conditional, and the server becomes a proxy for any destination the attacker names.

---

How the Attack Works

The flaw lets an unauthenticated attacker, with a single crafted HTTP request, cause the Next.js process to issue an internal HTTP GET to any host reachable from the server on port 80, including cloud metadata services, administrative panels, and internal APIs, and read the response.

The cloud metadata angle is the most severe. The impact is particularly severe in cloud-hosted environments because cloud metadata services on port 80 are reachable from inside the instance, including AWS IMDSv1 (169.254.169.254), Azure IMDS, Oracle OCI, and DigitalOcean metadata.

An attacker targeting an AWS-hosted application could abuse the SSRF condition to query the instance metadata service and silently retrieve temporary IAM credentials. Those credentials can then be used to escalate privileges or move laterally within an organization's cloud environment, all without triggering standard authentication alerts.

There is one partial constraint worth noting: AWS IMDSv2 is largely not exploitable because it requires a PUT /latest/api/token to mint a session token, which this GET-only SSRF cannot perform, and it rejects requests carrying X-Forwarded-For. Teams that have enforced IMDSv2 on their EC2 instances have meaningful protection here. Everyone else does not.

---

Key Technical Highlights

All versions starting from 13.4.13 before 15.5.16, and all versions starting from 16.0.0 before 16.2.5, are affected. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, classified under CWE-918 (Server-Side Request Forgery).

Key facts at a glance:

• CVE: CVE-2026-44578 | CVSS 8.6 (High)
• Affected: Self-hosted Next.js on built-in Node.js server, versions 13.4.13 through 15.5.15 and 16.0.0 through 16.2.4
• Fixed in: Next.js 15.5.16 and 16.2.5
• Auth required: None
• User interaction required: None
• Vercel-hosted apps: Not affected

The Next.js security team responded quickly, releasing patched versions 15.5.16 and 16.2.5. These updates introduce stricter validation for WebSocket upgrade requests, ensuring only explicitly trusted external rewrites are permitted, bringing WebSocket handling in line with existing HTTP security controls.

---

What Gets Exposed

Three categories of sensitive data are directly at risk once an attacker successfully exploits this flaw.

Cloud credential theft is the most dangerous scenario. Attackers can query metadata services exposed by cloud providers to retrieve temporary or persistent cloud credentials, which grant broad access to cloud infrastructure, potentially leading to data exfiltration, service disruption, or further network penetration.

API key harvesting is the second vector. By making internal requests, attackers can access configurations or environment variables that store API keys for various services. Compromised API keys can allow them to impersonate applications, access third-party services, or manipulate data.

Third, the SSRF flaw can be exploited to bypass network segmentation and access internal administrative interfaces that are typically only reachable from within a private network.

This is also an increasingly relevant concern for AI-powered applications. Many modern Next.js deployments store OpenAI, Anthropic, or other AI provider API keys in server-side environment variables. A successful SSRF hit against those apps doesn't just leak infrastructure credentials. It leaks the keys powering the AI layer too.

---

Part of a Broader Next.js Vulnerability Cluster

CVE-2026-44578 did not arrive alone. Vercel released urgent security updates for Next.js addressing a cluster of high-severity vulnerabilities that expose web applications to unauthenticated Denial of Service, SSRF, and multiple middleware authentication bypasses. The patches land in versions 15.5.16 and 16.2.5, covering affected branches spanning Next.js 13.x through 16.x.

Three separate advisories address middleware bypass vulnerabilities in App Router applications. Specially crafted .rsc and segment-prefetch URLs can resolve to the same page without being matched by intended middleware rules, allowing protected content to be accessed without proper authorization checks.

A high-severity denial-of-service vulnerability tracked as CVE-2026-23870 also affects React Server Components packages for versions 19.x and all Next.js App Router deployments on versions 13.x through 16.x. A specially crafted HTTP request sent to any App Router Server Function endpoint can trigger excessive CPU usage, resulting in denial-of-service attacks in unpatched environments.

---

How to Fix It and What to Do Right Now

Patching is the only complete fix. The only effective remediation for this class of vulnerability is upgrading to a patched version of Next.js. There are no configuration-based workarounds that fully mitigate the risk.

For teams that cannot patch immediately, apply these interim controls:

• Avoid exposing origin servers directly to the internet, block unnecessary WebSocket upgrade requests at reverse proxies or load balancers, and restrict outbound traffic to sensitive internal endpoints or metadata.
• Configure network firewalls and security groups to restrict outbound connections from Next.js application servers. Allow only necessary connections to trusted external services and deny access to internal IP ranges, such as 169.254.169.254 for cloud metadata services.
• Once you have patched your version and re-deployed your application, rotate all your application secrets.
• Enforce AWS IMDSv2 and replace any reused SSH keys.

If you're using Vercel, you will see a banner in the vercel.com dashboard when your production deployment is using a vulnerable version of these packages. That's a useful signal, but don't treat it as a substitute for checking your deployed versions directly.

---

Final Thoughts

What stands out about CVE-2026-44578 technically is how minimal the root cause is. A single missing check on two routing flags in the WebSocket upgrade handler creates a full SSRF primitive that any unauthenticated user on the internet can trigger. The fix Vercel shipped gates the proxy call on finished && parsedUrl.protocol && !statusCode, the same check the HTTP handler already performed. The asymmetry between the simplicity of the fix and the severity of the exposure is a useful reminder that security bugs in widely deployed frameworks don't need to be architecturally complex to be catastrophic.

The broader context here matters too. This is the second major vulnerability cluster to hit the Next.js and React Server Components stack in roughly six months, following the React2Shell (CVE-2025-55182) campaign that saw 766 hosts compromised in 24 hours according to Cisco Talos. The pattern is consistent: modern full-stack frameworks deeply integrated with cloud infrastructure are high-value targets, and the attack surface grows with every new protocol feature added to the server layer.

If you're running self-hosted Next.js anywhere near cloud credentials or AI API keys, treat this as a priority patch this week. What's your current patch status? Drop your thoughts in the comments.

---