EUVD-2026-38549
GHSA-x2qc-cmh9-f4hf
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Network-delivered crash requiring victim to initiate the connection (UI:R); attacker needs no victim-system privileges (PR:N); only the connecting Deno process terminates (A:L), no data exposed.
Primary rating from Vendor (https://github.com/denoland/deno).
CVSS VectorVendor: https://github.com/denoland/deno
Lifecycle Timeline
2DescriptionCVE.org
Summary
A Deno program that opens a client WebSocket connection could be crashed by the remote server. While handling the WebSocket handshake response, Deno parsed the Sec-WebSocket-Protocol and Sec-WebSocket-Extensions response headers in a way that assumed their bytes were always printable ASCII. A response header containing non-visible-ASCII bytes (0x80-0xFF) caused a panic that aborted the entire Deno process.
Details
When establishing a client WebSocket connection, Deno read the Sec-WebSocket-Protocol and Sec-WebSocket-Extensions headers from the server's 101 Switching Protocols response and converted them to strings without handling the failure case. HeaderValue::to_str() returns an error for any value containing bytes outside the visible-ASCII range, so a header carrying such bytes triggered an unrecoverable error during conversion.
Because the client initiates the outbound connection, the handshake response is fully controlled by the server. A server that returns bytes such as 0xFF 0xFE in either header could therefore crash any client that connected to it.
This is purely an availability issue. There is no information disclosure and no memory-safety impact; the only effect is termination of the current process.
Impact
Remote denial of service. Any Deno application that establishes WebSocket connections to untrusted or potentially-compromised endpoints could be terminated by the remote peer. Exploitation requires the victim application to initiate the outbound WebSocket connection. An attacker who controls the WebSocket endpoint, or who can man-in-the-middle a plaintext ws:// connection, could trigger the crash. The effect is confined to crashing the process that opened the connection.
Patch
The issue is fixed in Deno 2.7.5. The header values are now parsed with graceful fallbacks: values that cannot be represented as ASCII strings are skipped instead of aborting the process. A regression test covers a server that returns non-ASCII bytes in Sec-WebSocket-Protocol.
Users should upgrade to Deno 2.7.5 or later.
Workarounds
Until you can upgrade, only connect to trusted WebSocket endpoints and prefer wss:// (TLS) over ws://, which prevents a network man-in-the-middle from injecting malicious header bytes into the handshake response.
AnalysisAI
Process-terminating denial of service in Deno's WebSocket client (versions <= 2.7.4) allows any server - or a network man-in-the-middle on an unencrypted ws:// connection - to crash a Deno application by returning non-visible-ASCII bytes (0x80-0xFF) in the Sec-WebSocket-Protocol or Sec-WebSocket-Extensions handshake response headers. The root cause is an unhandled Rust panic in the HTTP upgrade path: HeaderValue::to_str() returns an error for out-of-range bytes, and that error path was not caught, causing the entire Deno process to abort. No public exploit has been identified at time of analysis and this is not listed in the CISA KEV catalog; impact is strictly availability - the advisory explicitly states there is no information disclosure or memory-safety consequence.
Technical ContextAI
Deno is a JavaScript and TypeScript runtime built on V8 and Rust. The vulnerability is located in its WebSocket client handshake implementation, specifically in how HTTP 101 Switching Protocols upgrade response headers are processed. The Rust http crate's HeaderValue::to_str() method is defined to return Err for any byte value outside the visible ASCII range (0x20-0x7E); the Deno code consumed this Result without handling the error case, causing an unrecoverable panic (CWE-248: Uncaught Exception in the Rust sense - an unwrap or expect on a failed conversion) that propagates up to abort the entire process. The CPE identifier pkg:rust/deno confirms the Rust-level layer as the locus of the defect. The affected headers - Sec-WebSocket-Protocol and Sec-WebSocket-Extensions - are part of the RFC 6455 WebSocket opening handshake and are fully attacker-controlled when the attacker owns or can intercept the server side of the connection.
RemediationAI
Upgrade to Deno 2.7.5 or later; this is the vendor-released patch confirmed by the GitHub advisory GHSA-x2qc-cmh9-f4hf. In 2.7.5, the WebSocket header parsing was hardened with graceful fallbacks: Sec-WebSocket-Protocol and Sec-WebSocket-Extensions values containing non-ASCII bytes are now silently skipped rather than causing a process-aborting panic, and a regression test covering a server that returns non-ASCII bytes in Sec-WebSocket-Protocol was added. If an immediate upgrade is not feasible, apply two compensating controls: (1) restrict WebSocket connections exclusively to a known-good allowlist of trusted endpoints, which eliminates the attacker-controlled-server path but does not protect against a compromised allowlisted server; and (2) enforce wss:// (TLS) for all WebSocket connections, which removes the network man-in-the-middle attack vector by encrypting the handshake, though it does not protect against a malicious origin server. Neither workaround addresses a scenario where a previously trusted endpoint is later compromised, so patching to 2.7.5 remains the definitive fix.
Same weakness CWE-248 – Uncaught Exception
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today