SSRF in Modern Frameworks: Lessons from the Next.js Disclosure
Why server-side request forgery keeps slipping into the frameworks we trust
This week, Vercel disclosed CVE-2026-44578, a server-side request forgery (SSRF) flaw in self-hosted Next.js applications using the built-in Node.js server. Crafted WebSocket upgrade requests caused the server to proxy connections to arbitrary internal or external destinations. Versions from 13.4.13 through anything before 15.5.16 and 16.2.5 are affected; Vercel-hosted deployments are not, because Vercel-managed Next.js runs on its own edge runtime and the vulnerable code path isn't exposed.
It's a narrow bug with broad implications. SSRF has sat near the top of the OWASP Top 10 since 2021 and continues to appear in mature, well-staffed frameworks. The question worth asking isn't "are we patched?". It's "why does this class of flaw keep landing in production?"
What SSRF actually is
A server-side request forgery vulnerability lets an attacker coerce a server into making a network request on their behalf. Unlike most web flaws, which abuse the application's own logic, SSRF abuses the server's position on the network. Once an attacker controls the destination, three things become reachable that should not be:
- Cloud metadata services. On AWS, GCP and Azure, the instance metadata endpoint serves credentials and configuration to any process that asks. An SSRF reaching
169.254.169.254often yields IAM tokens. - Internal services. Databases, admin panels, monitoring endpoints and internal APIs: anything bound to localhost or a private subnet that assumed it was unreachable from the public internet.
- Outbound exfiltration paths. Forcing the server to call an attacker-controlled host can leak data via DNS, HTTP headers or response timing, even when no response is returned to the attacker.
The Next.js disclosure is a textbook example of the first failure mode: a feature designed to handle internal proxying (WebSocket upgrades) didn't sufficiently validate where the upgrade was being directed.
Why frameworks keep shipping it
SSRF slips in for the same recurring reasons:
- Trusted internal helpers. When a framework exposes a feature for making requests on behalf of the application (proxying, URL fetching, image transformation, webhook delivery), that feature becomes an SSRF primitive the moment user input reaches it.
- Upgrade and protocol-switch paths. HTTP upgrade requests, redirects and protocol switches are easy to overlook in input validation, because they sit outside the request body that most security review focuses on.
- Allow-list assumptions. Blocking
localhost,127.0.0.1and RFC1918 ranges is necessary but not sufficient. DNS rebinding, link-local addresses (169.254.x.x), IPv6 mappings (::ffff:127.0.0.1) and decimal or hex IP notations routinely bypass naive deny-lists.
The original OWASP write-up explicitly warned that SSRF would grow more common as architectures moved toward cloud-fetched URLs, microservice topologies and webhook integrations. Five years on, the prediction has held.
What to do beyond patching
Patching CVE-2026-44578 (Next.js 15.5.16+ for the 15.x branch, 16.2.5+ for the 16.x branch) is necessary if you self-host. The harder work is structural:
- Treat SSRF as an architecture problem, not a string-validation problem. Outbound requests from application servers should pass through a forward proxy with an explicit allow-list of legitimate destinations. Defence at the network layer survives bugs in the framework above it.
- Lock down cloud metadata. On AWS, enforce IMDSv2 (session-token-based metadata access). On GCP and Azure, restrict metadata responses and the network paths that can reach them. This blocks the highest-impact SSRF exploitation path even when an SSRF primitive exists.
- Hunt for SSRF in your own code. Anywhere user input shapes an outbound URL, DNS lookup, or upgrade request is a candidate. Manual testing finds these. Vulnerability scanners typically do not, especially the blind variants that exfiltrate via DNS or response timing rather than returning a visible response.
Frequently asked questions
Are Vercel-hosted Next.js sites affected by CVE-2026-44578?
No. The advisory states Vercel-hosted deployments are not exposed. The vulnerability is in the built-in Node.js server used in self-hosted deployments.
Is patching the framework enough?
For this specific CVE, yes. For SSRF as a class, no. A defensible posture combines patched frameworks, restrictive egress controls and metadata service hardening, so the next undisclosed SSRF doesn't translate directly into credential theft.
How do you find SSRF that scanners miss?
Manual penetration testing focused on outbound request paths: upgrade handlers, webhook receivers, URL-fetching helpers, image proxies. Testers chain input vectors and probe for blind variants (DNS exfiltration, response-timing oracles) that automated tools rarely surface.