Next.js – Server-side request forgery in applications using WebSocket upgrades

reimertz1 pts0 comments

Server-side request forgery in applications using WebSocket upgrades · Advisory · vercel/next.js · GitHub

//repos/advisories/show" data-turbo-transient="true" />

Skip to content

Search or jump to...

Search code, repositories, users, issues, pull requests...

-->

Search

Clear

Search syntax tips

Provide feedback

--><br>We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

-->

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

//repos/advisories/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up

Appearance settings

Resetting focus

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

vercel

next.js

Public

Notifications<br>You must be signed in to change notification settings

Fork<br>31.1k

Star<br>139k

Server-side request forgery in applications using WebSocket upgrades

High

timneutkens<br>published<br>GHSA-c4j6-fc7j-m34r<br>May 6, 2026

Package

npm

next<br>(npm)

Affected versions

>= 13.4.13 >= 16.0.0<br>Patched versions

15.5.16

16.2.5

Description

Impact

Self-hosted applications using the built-in Node.js server can be vulnerable to server-side request forgery through crafted WebSocket upgrade requests. An attacker can cause the server to proxy requests to arbitrary internal or external destinations, which may expose internal services or cloud metadata endpoints. Vercel-hosted deployments are not affected.

Fix

We now apply 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.

Workarounds

If you cannot upgrade immediately, do not expose the origin server directly to untrusted networks. If WebSocket upgrades are not required, block them at your reverse proxy or load balancer, and restrict origin egress to internal networks and metadata services where possible.

Severity

High

8.6

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).

/ 10

CVSS v3 base metrics

Attack vector<br>Network

Attack complexity<br>Low

Privileges required<br>None

User interaction<br>None

Scope<br>Changed

Confidentiality<br>High

Integrity<br>None

Availability<br>None

Learn more about base metrics

CVSS v3 base metrics

Attack vector:<br>More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity:<br>More severe for the least complex attacks.

Privileges required:<br>More severe if no privileges are required.

User interaction:<br>More severe when no user interaction is required.

Scope:<br>More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality:<br>More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity:<br>More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability:<br>More severe when the loss of impacted component availability is highest.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE ID

CVE-2026-44578

Weaknesses

No CWEs

You can’t perform that action at this time.

severe server websocket data search requests

Related Articles