Next.js SSRF Flaw Lets Attackers Steal Cloud Credentials

Picture a hotel concierge who'll happily ring any room in the building for a guest, no questions asked. Most days that's a feature. The day a stranger walks in and asks the concierge to ring the manager's safe and read out the combination, it becomes the worst job description in the building. That's roughly what just happened to the WebSocket upgrade handler inside the default Next.js Node.js server.

On May 15, 2026, a high-severity SSRF vulnerability landed in the Next.js ecosystem, and anyone running their own infrastructure now has a concierge with very poor judgement sitting at the front desk.

What Happened

The bug is tracked as CVE-2026-44578, and also as GHSA-c4j6-fc7j-m34r on GitHub. As CyberSecurityNews reported, the flaw originates in how the built-in Next.js Node.js server handles WebSocket upgrade requests. A crafted upgrade request convinces the server to act as a proxy, forwarding the attacker's payload onward to wherever they fancy: an internal admin dashboard, a service mesh endpoint, or the cloud metadata service sitting on the link-local address every backend engineer learned to fear.

The disclosure came from Tim Neutkens on GitHub, and the Next.js maintenance team has shipped patches across two distinct release tracks. The fixed versions are 15.5.16 and 16.2.5. In the patched build, the server only proxies WebSocket upgrade requests when routing configurations explicitly mark them as safe external rewrites. Default deny, opt in. That's the right shape for this kind of feature, and arguably should have been the shape on day one.

Two clarifications that matter for blast radius. First, this is strictly a self-hosted problem. Apps running on Vercel are completely safe, because Vercel's infrastructure does not use the vulnerable WebSocket routing implementation. Second, this isn't a theoretical paper-cut. The article describes attackers querying internal network services, reaching unprotected admin dashboards, and hitting cloud metadata endpoints, which can hand over temporary IAM credentials, API tokens, and deployment secrets in a single response. Anyone who has watched a token-stealing SSRF chain unfold in a postmortem knows how short the road is from "weird WebSocket" to "the attacker has our deploy role".

For the public CVE record, the entry sits in the usual MITRE CVE system under CVE-2026-44578.

Technical Anatomy

The guts of it is depressingly simple. HTTP/1.1 has this odd little ceremony called the upgrade handshake, where a client says "I'd like to switch protocols, please" and the server, if it agrees, hands the socket over to a different code path. WebSockets ride on top of that mechanism. Inside a framework like Next.js, the server needs to decide what to do with an upgrade request: terminate it locally, ignore it, or forward it on to some upstream defined by the route configuration.

The vulnerable behaviour, per the disclosure, is that the default server would forward upgrade requests in scenarios it shouldn't. An attacker sends a specially crafted upgrade, and the Next.js process dutifully opens a connection to a destination the attacker influences. Because the server itself executes the outbound request, it bypasses external firewalls. The packets aren't coming from the public internet anymore. They're coming from a trusted box inside your VPC, with whatever egress rules and IAM context that box happens to enjoy.

From there it's classic SSRF. The juiciest target in any cloud-hosted Node process is the metadata endpoint: the link-local address that returns instance role credentials. A successful hit yields short-lived but very real IAM tokens. Other paths lead to internal admin panels that were "safe" because they were unreachable from outside, to Redis or Elasticsearch instances that never expected an authenticated caller, and to anything else sitting on a private subnet. This is OWASP A10:2021 in textbook form, weaponised through a framework most teams treat as a black box.

The patch design tells you something about the maintainers' thinking. Rather than try to sanitise destinations or pattern-match for metadata IPs (a losing game, as anyone who has tried to block 169.254.169.254 across IPv6, DNS rebinding, and redirect chains can confirm), they flipped the default. No proxying unless the route config says "yes, this is an external rewrite and I meant it". That's the right move. The boring bit is that most teams won't realise they had implicit upgrade-forwarding behaviour until they read the changelog.

Who Gets Burned

The exposed population is anyone running self-hosted Next.js on the default Node.js server. In practice that's a long list: iGaming operators who pulled their player-facing stack in-house for latency or compliance reasons, fintech teams who can't ship customer data through a third-party edge platform, crypto front-ends that explicitly chose self-hosting because they didn't want a single vendor able to pull the plug, and any enterprise that runs Next.js inside a regulated VPC.

The iGaming angle is the one that worries me most. Sportsbooks tend to run admin panels for trading desks, risk controls, and player management on internal subnets, behind the assumption that the public web tier can't reach them. An SSRF in the public web tier collapses that assumption in one hop. If the same Kubernetes cluster also runs the storefront, the attacker now has a proxy into the trading floor.

Fintech teams have a different flavour of the same problem. PCI scope and SOC 2 boundaries are usually drawn on the network. A web frontend that can suddenly speak to internal services, or worse, mint AWS credentials via the metadata endpoint, blows holes in audit assumptions that took months to draw up.

Crypto front-ends carry a special risk: if the self-hosted Next.js box has any signing keys, deployment secrets, or RPC credentials cached locally or reachable on the same network, an attacker walking out with cloud metadata tokens can pivot fast. The next 90 days for these teams should involve a credential rotation drill regardless of whether they think they were hit, because temporary IAM tokens leak silently and the logs to prove a negative often don't exist.

Vercel customers, to be clear, can sit this one out. That's a real architectural dividend for the managed path. It's also a useful talking point the next time a CFO asks why the hosting bill isn't lower.

Playbook for Security Teams

Step one this week: upgrade. Next.js 15.5.16 if you're on the 15.x track, 16.2.5 if you're on 16.x. There's no clever middle ground here. The patch changes default behaviour, so test your routes, particularly anything that genuinely uses WebSocket rewrites to an upstream, because those will now need explicit configuration to keep working.

Where patching isn't possible this week (and there's always a service somewhere stuck on an old build because of a Node version pin or a frozen vendor image), the disclosure recommends two compensating controls. First, configure your reverse proxy or load balancer to block all WebSocket upgrade requests if the application doesn't actively use them. An nginx Connection and Upgrade header strip in front of the origin is a five-minute change with very high return. Second, restrict the origin server's outbound traffic. Block egress to internal cloud metadata services and to unrelated internal networks at the security group or network policy layer.

For AWS users in particular, switching to IMDSv2 with hop-limit of 1 has been best practice for years and is the single most effective hardening step against this exact attack chain. If you haven't done it, this is your nudge. Map the TTP against MITRE ATT&CK T1552.005 (Cloud Instance Metadata API) when you write the postmortem, because someone in your org will ask.

Finally, hunt. Check your access logs for unusual Upgrade: websocket requests, particularly ones with odd Host headers or destinations that don't match your normal traffic. If you find any from before the patch, assume credential exposure and rotate.

Key Takeaways

• CVE-2026-44578 is a high-severity SSRF in the Next.js default Node.js server's WebSocket upgrade handler, disclosed by Tim Neutkens.
• Upgrade to Next.js 15.5.16 or 16.2.5 immediately. The patch makes upgrade-proxying opt-in via explicit safe external rewrite configuration.
• Only self-hosted deployments are affected. Vercel-hosted apps are not vulnerable, because Vercel doesn't use the affected WebSocket routing path.
• If you can't patch, strip WebSocket upgrades at the reverse proxy and lock down origin egress to cloud metadata endpoints and unrelated internal subnets.
• The concierge analogy holds: when the front desk will dial any room on request, the only safe policy is a guest list. Default-deny on internal proxying is the only architecture that survives contact with a determined attacker.