highCVE-2026-61666Jul 21, 2026

CVE-2026-61666: websocket-driver Denial of Service via Malformed Host Header

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A remote attacker can crash any Ruby WebSocket server built on websocket-driver by sending a single HTTP upgrade request with a malformed Host header, which triggers an unhandled exception and kills…

Packagewebsocket-driver
Ecosystemrubygems
Affected< 0.8.2
Fixed in0.8.2

The problem

The server-side driver created via WebSocket::Driver.server() parses the incoming HTTP Host header using Ruby's URI module to extract the server name and port.

If the Host value is not a valid host[:port] string, URI.parse raises URI::InvalidURIError. Before 0.8.2, nothing caught this exception inside the request parser, so it bubbled up through parse() and could terminate the server process. Any unauthenticated TCP client can trigger this with one request.

Proof of concept

A working proof-of-concept for CVE-2026-61666 in websocket-driver, with the exact payload below.

http
GET / HTTP/1.1
Host: [invalid
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Ruby's URI.parse raises URI::InvalidURIError on inputs that are not valid URI references. An unclosed IPv6 bracket like [invalid is a canonical trigger: URI.parse('ws://[invalid/') raises immediately.

The patch at commit 7d6fd87 wraps the URI.parse call (used to split Host into server name and port) in a rescue URI::InvalidURIError block. Instead of raising, the driver now calls its own fail method, entering the standard error state and sending a 400 response.

The root cause is CWE-248: Uncaught Exception, where attacker-controlled input reaches an unguarded URI.parse call.

The fix

Upgrade websocket-driver to version 0.8.2 or later. The fix is in commit 7d6fd87759a2fdc83590d3b49ffa661dc53fa128. No workaround exists for older versions other than wrapping every driver.parse(data) call in a rescue URI::InvalidURIError block in application code.

Reported by Pranjali Thakur, DepthFirst Security Research Team.

References: [1][2][3]

Related research