CVE-2026-44578 is a high-severity server-side request forgery vulnerability affecting certain self-hosted Next.js applications. The issue exists in applications that use the built-in Next.js Node.js server and are exposed to crafted WebSocket upgrade requests. According to the GitHub security advisory, affected versions are Next.js >=13.4.13 <15.5.16 and >=16.0.0 <16.2.5; the vulnerability is patched in 15.5.16 and 16.2.5.
At a practical level, the vulnerability can allow an unauthenticated attacker to make a vulnerable server send requests to internal or external destinations chosen by the attacker. This is why the bug is classified as SSRF, or server-side request forgery.
Why This Matters
Next.js is widely used to build full-stack React applications, including apps deployed on cloud infrastructure, containers, private networks, and Kubernetes clusters. SSRF bugs are dangerous because the attacker is not directly connecting to the internal target. Instead, they trick the vulnerable server into doing it for them.
That matters because the server may have network access that the attacker does not. For example, a public Next.js app might be able to reach internal APIs, admin panels, service discovery endpoints, or cloud metadata services. The NVD description specifically notes the risk of exposing internal services or cloud metadata endpoints.
What Is Vulnerable?
The key conditions are:
| Condition | Status |
|---|---|
| Self-hosted Next.js app | Potentially affected |
| Uses the built-in Node.js server | Potentially affected |
| Exposed to untrusted WebSocket upgrade requests | Potentially affected |
| Hosted on Vercel | Not affected according to the advisory |
| Patched to 15.5.16 or 16.2.5 | Fixed for this CVE |
The vulnerability does not apply equally to every Next.js deployment. The GitHub advisory says Vercel-hosted deployments are not affected. The affected scenario is self-hosted applications using the built-in Node.js server.
Affected Versions
The GitHub advisory lists the affected ranges as:
- >= 13.4.13 < 15.5.16
- >= 16.0.0 < 16.2.5
The patched versions for this specific advisory are 15.5.16 and 16.2.5.
One important nuance: Vercel later published a broader May 2026 Next.js security release covering multiple advisories and recommended upgrading to newer versions, including 15.5.18 or 16.2.6, depending on the branch. For teams patching production systems, upgrading to the latest available patched release in your supported branch is safer than targeting only the minimum fixed version for one CVE.
Severity and CVSS
GitHub assigned CVE-2026-44578 a CVSS 3.1 score of 8.6 High with the vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
| Metric | Meaning |
|---|---|
| AV:N | Exploitable over the network |
| AC:L | Low attack complexity |
| PR:N | No privileges required |
| UI:N | No user interaction required |
| S:C | Impact crosses a security boundary |
| C:H | High confidentiality impact |
| I:N | No direct integrity impact |
| A:N | No direct availability impact |
The biggest concern is confidentiality. An attacker may be able to access information from places that should not be reachable from the public internet, especially if the vulnerable server can talk to internal services.
How the Vulnerability Works
A WebSocket connection begins as an HTTP request with an upgrade mechanism. The client asks the server to switch protocols from normal HTTP to WebSocket.
In vulnerable self-hosted Next.js setups, crafted WebSocket upgrade requests could cause the server to proxy traffic to destinations that should not be reachable through the application. GitHub's advisory explains that the fix applies the same safety checks to WebSocket upgrade handling that already existed for normal HTTP requests, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.
That detail is important. The issue was not simply "WebSockets are unsafe." The problem was inconsistent safety handling between normal HTTP request routing and WebSocket upgrade routing.
Example Risk Scenario
Imagine a company runs a self-hosted Next.js app on a cloud virtual machine. The app is public, but the server also has access to private network resources. An attacker sends a crafted WebSocket upgrade request to the public app. If the app is vulnerable, the attacker may cause the server to make a request to an internal-only service.
The attacker is not breaking directly into the private network. They are abusing the trusted position of the Next.js server.
This is the core danger of SSRF: the vulnerable server becomes an unwilling proxy.
What Attackers May Target
| Target type | Why it matters |
|---|---|
| Cloud metadata endpoints | May expose credentials or instance identity data |
| Internal APIs | May leak sensitive business data |
| Admin panels | May reveal configuration or management interfaces |
| Service discovery systems | May expose internal architecture |
| Localhost services | May expose services bound only to the server itself |
Not every vulnerable app will expose all of these. The real impact depends on where the app is hosted, what the server can reach, and whether egress controls are in place.
How to Check Whether You Are Affected
Check your Next.js version:
bashnpm ls nextOr, if using pnpm:
bashpnpm list nextOr, if using yarn:
bashyarn list nextYou should also check how the app is deployed. The highest-risk setup is a self-hosted Next.js app using the built-in Node.js server, especially if the origin server is directly reachable from the internet.
How to Fix It
Upgrade Next.js. For this specific CVE, the patched versions are:
bashnpm install next@15.5.16or:
bashnpm install next@16.2.5However, because Vercel's broader May 2026 security release addressed multiple advisories, teams should strongly consider upgrading to the newest patched release available for their supported branch, such as 15.5.18 or 16.2.6, where compatible. Vercel's release notes state that patching is the only complete mitigation for the broader advisory set.
After upgrading, rebuild and redeploy the application. Then confirm the deployed version, not just the local package version.
Temporary Mitigations
If you cannot upgrade immediately, use layered mitigations. GitHub and Snyk both recommend not exposing the origin server directly to untrusted networks, blocking WebSocket upgrades at the reverse proxy or load balancer if they are not required, and restricting server egress to internal networks and metadata services where possible.
Practical steps include:
nginx# Example only: block WebSocket upgrades if your app does not need them
map $http_upgrade $connection_upgrade {
default close;
}At the infrastructure level, also consider:
- Block access from app servers to cloud metadata IPs unless required.
- Restrict outbound traffic from the app server.
- Place the origin server behind a reverse proxy or load balancer.
- Avoid exposing the raw Node.js server directly to the internet.
- Review logs for unusual
Upgrade: websockettraffic.
These mitigations reduce risk, but they are not a substitute for patching.
Detection and Investigation Tips
Security teams should look for suspicious requests involving WebSocket upgrades, especially requests with unusual hostnames, unexpected routing behavior, or attempts to reach internal IP ranges.
Useful log fields include:
- HTTP method
- Host header
- Upgrade header
- Connection header
- Request path
- Upstream target
- Response status
- Source IP
- User agent
Pay special attention to requests attempting to interact with:
127.0.0.1
localhost
169.254.169.254
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
.internal domains
.local domainsThe presence of these values does not prove exploitation, but it is worth investigating in affected environments.
Lessons for Developers and Platform Teams
CVE-2026-44578 is a reminder that request routing logic must be consistent across protocols. A framework may correctly validate normal HTTP requests but still expose risk through upgrade paths, rewrites, proxies, or edge-case routing behavior.
Good defensive habits include:
- Treat WebSocket upgrade handling as security-sensitive.
- Avoid direct exposure of application origin servers.
- Use outbound firewall rules, not just inbound firewall rules.
- Block metadata service access by default.
- Keep frameworks updated, especially full-stack frameworks that handle routing.
- Monitor advisories for both framework and runtime dependencies.
Final Takeaway
CVE-2026-44578 is a high-severity SSRF vulnerability in self-hosted Next.js applications using the built-in Node.js server. The vulnerable behavior is triggered through crafted WebSocket upgrade requests and may allow attackers to reach internal or external destinations through the server. It is especially concerning in cloud environments where metadata endpoints or private services are reachable from the application host.
The best fix is to upgrade Next.js immediately. For this specific CVE, the patched versions are 15.5.16 and 16.2.5; for broader May 2026 Next.js security coverage, review the later patched releases recommended by Vercel.