Next.js WebSocket Upgrade Handler SSRF
Next.js WebSocket Upgrade Handler SSRF (CVE-2026-44578)
Overview
The SonicWall Capture Labs threat research team became aware of a Server-Side Request Forgery vulnerability in Next.js, assessed its impact and developed mitigation measures. Next.js enables organizations to create full-stack web applications by extending the latest React features and integrating powerful Rust-based JavaScript tooling for the fastest builds.
The issue, tracked as CVE-2026-44578, affects all versions from 13.4.13 to before 15.5.16 and 16.2.5. Self-hosted applications using the built-in Node.js server can be vulnerable to Server-Side Request Forgery through crafted WebSocket upgrade requests. This flaw, categorized under CWE-918 Server-Side Request Forgery (SSRF), allows attackers to bypass network boundaries, access hidden internal services, and expose sensitive cloud metadata, with a high CVSS score of 8.6. Users are strongly encouraged to apply the vendor-provided updates without delay.
NOTE: Self-hosted only — Vercel-managed infrastructure and other PaaS providers that do not expose raw WebSocket upgrade capabilities are not affected.
Technical Overview
Vercel Next.js is an open-source, full-stack React framework used to develop web applications. The package is distributed through the npm ecosystem (next).
Figure 1 illustrates the overall Vercel Next.js operational architecture. As per the diagram, in Paradigm A, the network protocol layer is handled by the deployment platform's load balancer or reverse proxy (e.g., Vercel's edge network). The Next.js framework only sees fully parsed and validated HTTP requests. The case of interest here is Paradigm B — the vulnerable deployment model for CVE-2026-44578. In Paradigm B, the custom Next.js deployment is the server engine. The framework code layer handles raw socket parameters directly. Because the code is doing the heavy lifting of parsing incoming HTTP request strings, any flaws in its built-in router (like the absolute-form URI parsing bug in CVE-2026-44578) leave the underlying host system vulnerable to attack.
Root Cause
The exploitation entry vector is a malformed absolute-form URI request line (e.g., GET http:///...). The vulnerability stems from the fact that the code did not properly validate whether the routing lifecycle had fully completed before forwarding raw connections to the internal proxy engine. This flaw allowed unauthenticated attackers to abuse absolute-form request URIs and perform Server-Side Request Forgery (SSRF) attacks. The vulnerable routine is a low-level HTTP/1.1 WebSocket upgrade event listener located in packages/next/src/server/lib/router-server.ts . It reads the absolute-form URI and applies it without validation.
When an attacker structures an absolute request using malformed repeating slashes (such as GET http:///latest/meta-data/), it tricks Next.js's internal components. At the same time, the malformed string structures are reduced to http:/. Since the target domain boundaries are no longer clearly defined, the URL parser treats parsedUrl.hostname as null while still successfully identifying parsedUrl.protocol as http:. To actively trigger this code path, the exploit payload must be a raw TCP transaction (using tools like netcat or raw Python sockets) because standard curl automatically cleanses absolute request structures before transmitting them across a socket.
The affected code snippet that parses the permanent redirect without requiring authentication is shown in Figure 2.
Requirements:
- The vulnerable instances of Next.js are self-hosted only.
- The Upgrade: websocket and Connection: Upgrade headers are strictly mandatory to exploit CVE-2026-44578. Without these two exact headers, the exploit cannot work. The vulnerability resides exclusively inside a specific file segment within the Next.js framework: the native HTTP/1.1 WebSocket upgrade routing routine.
Patch Analysis
The security introduced in patched versions above as shown in Figure 3, adds a confirmation prompt whenever the WebSocket upgrade is triggered. Instead, the socket connection is closed. Only routed, trusted operations are allowed to execute, and access to internal services is blocked.
Triggering Vulnerability
As shown in Figure 4, the exploitation process typically follows these steps:
- An attacker initiates the exploit by sending a specially crafted HTTP GET request containing an absolute-form URI such as http:///latest/meta-data/, along with Connection: Upgrade and Upgrade: websocket HTTP headers.
- When the vulnerable Next.js server processes this request, the URL parser successfully identifies the protocol as http: but fails to extract a valid hostname, resulting in hostname: null.
- During request normalization, repeated slashes are collapsed, transforming the malformed URI from http:/// into http:/. The normalization routine then returns to a redirect response state with finished: true and statusCode: 308.
- However, due to flawed validation logic in the WebSocket upgrade handler, the application only verifies the protocol value and does not confirm whether the routing lifecycle completed successfully or whether a redirect status code was generated.
- Due to this flaw, the request is incorrectly forwarded to the internal proxy engine. The proxy subsequently interprets the malformed request as a local connection and routes it to localhost:80, issuing a request for /latest/meta-data/. If an internal metadata service or sensitive local application is accessible, it responds with sensitive information such as credentials or instance metadata.
- Finally, the vulnerable server relays the internal response back to the attacker, resulting in a successful Server-Side Request Forgery (SSRF) attack.
- Figure 5 shows possible absolute URLs similar to /latest/meta-data/.
Exploitation
Successful exploitation enables a remote, unauthenticated attacker to craft a WebSocket upgrade request and abuse it to reach internal services or retrieve sensitive cloud metadata from the affected system. Figure 6 demonstrates a real-world proof of concept, showing successful exploitation to achieve SSRF, using a publicly available exploit. Given Next.js's extensive system privileges, this vulnerability can result in the disclosure of internal APIs, cloud metadata, admin interfaces, and other internal services, as well as data exfiltration that may compromise the operator's machine.
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:
- IPS: 22184 Next.js WebSocket Upgrade Request Server-Side Request Forgery
Remediation Recommendations
With Next.js's growing user base and increasing deployment footprint, organizations and individual users should upgrade to the latest patched version as outlined in the official vendor advisory.
Apart from patching, if Next.js application logic only exposes REST APIs or standard page renders and does not use WebSockets, drop incoming upgrade connection headers entirely and disable unnecessary WebSocket upgrades.
Relevant Links
Share This Article
An Article By
An Article By
Dhiren Vaghela
Dhiren Vaghela
Dhiren Vaghela has over a decade of experience in the IPS domain, with a strong focus on defensive security. His expertise lies in identifying, analyzing and mitigating vulnerabilities. Dhiren is well-versed in content-based signature writing, scanner-based alert generation and technical blog writing. By leveraging emerging technologies, he has developed numerous IPS signatures across various protocols. Known for his exceptional signature writing skills and collaborative team spirit, Dhiren is a valuable asset in the field of cybersecurity.
