Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.5, 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. This vulnerability is fixed in 2.7.5.
Affected: crates.io: deno
## 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 applicat…