CVE-2026-61666 in websocket-driver-ruby
Summary
by MITRE • 08/17/2026
websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.8.2, WebSocket::Driver.server() passes a malformed Host header to URI.parse in lib/websocket/http/request.rb without catching URI::InvalidURIError, allowing a remote client to crash a TCP-backed WebSocket server when the application does not catch the error from parse(). This issue is fixed in version 0.8.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in websocket-driver versions prior to 0.8.2 represents a critical reliability flaw within the Ruby-based WebSocket protocol handler, specifically affecting servers that utilize TCP-backed connections. The core of this issue lies in the handling of HTTP upgrade requests during the initial WebSocket handshake process. When a client initiates a connection, it sends an HTTP request containing various headers, including the Host header which specifies the target host and port. In versions earlier than 0.8.2, the method WebSocket::Driver.server() processes this incoming data by passing the extracted Host header value directly to Ruby's URI.parse function without implementing any preliminary validation or error handling mechanisms for malformed input.
This lack of defensive programming leads to a direct denial-of-service condition when a remote attacker crafts a malicious HTTP request with an improperly formatted or syntactically invalid Host header. Because URI.parse is not designed to handle arbitrary, potentially dangerous strings gracefully in all contexts, it raises a URI::InvalidURIError exception upon encountering the malformed input. Since the websocket-driver library does not catch this specific exception within its internal logic, the unhandled error propagates up the call stack, causing the Ruby process hosting the WebSocket server to terminate abruptly or crash. This behavior effectively allows any remote client with network access to disrupt service availability simply by initiating a connection and sending a specifically crafted header string that triggers the parsing failure.
From a security architecture perspective, this vulnerability is classified under CWE-754: Improper Check for Unusual or Exceptional Conditions, as the application fails to validate input before processing it in a way that expects standard formats. Furthermore, because the impact results in the termination of the server process and denial of service for all connected clients, it aligns with MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under the sub-category of Resource Exhaustion: DoS via Exception Conditions. The severity is heightened by the fact that WebSocket servers are often long-running processes designed to maintain persistent connections; a crash forces a restart or requires manual intervention, leading to significant operational downtime and potential data loss for active sessions.
Mitigation strategies primarily involve upgrading the websocket-driver gem to version 0.8.2 or later, where this specific exception handling gap has been addressed by implementing proper try-catch blocks around URI parsing operations. For organizations unable to immediately upgrade due to dependency constraints, a temporary workaround involves wrapping the WebSocket server initialization in an external error handler that catches SystemExit or RuntimeError exceptions and attempts to restart the process gracefully, although this is not a substitute for fixing the root cause. Additionally, implementing input validation at the reverse proxy level before requests reach the application server can provide an additional layer of defense by filtering out malformed HTTP headers early in the request lifecycle.