CVE-2020-7663

What it actually does

The vulnerable websocket-extensions Ruby module parses the Sec-WebSocket-Extensions HTTP header with a regular expression that can exhibit catastrophic backtracking. A remote unauthenticated attacker can send a WebSocket upgrade request containing an extension parameter with an unterminated quoted string made of repeating backslash-plus-character sequences, causing header parsing to consume excessive CPU. On single-threaded Ruby application servers, this can block the event loop or worker and make the WebSocket endpoint unavailable; with repeated requests, an attacker can degrade or deny service across available workers.

Why it matters to the business

Applications that expose WebSocket endpoints through vulnerable versions of websocket-extensions-ruby can be disrupted remotely without authentication. The likely business effect is intermittent or sustained application unavailability, slow responses, exhausted Ruby worker capacity, failed real-time messaging features, and increased infrastructure load. Although the issue does not directly expose data or allow code execution, the CVSS availability impact is high and public exploit techniques are available, so internet-facing WebSocket services should be prioritized for upgrade.

How an attack unfolds

An attacker identifies an application endpoint that accepts WebSocket upgrade requests and uses the vulnerable Ruby websocket-extensions parser. The attacker sends crafted HTTP requests with a Sec-WebSocket-Extensions header containing an extension parameter whose value begins with a quote but is never closed, with the value body made from repeated two-byte backslash-character sequences. When the application parses the header, the vulnerable regular expression attempts many alternative matches before failing, producing quadratic CPU consumption relative to the header length. A single request can tie up a single-threaded server or worker for an extended period; many concurrent or repeated requests can consume all workers and create an application-level denial of service.

How to fix it

Upgrade websocket-extensions-ruby to version 0.1.5 or later, or to a dependency version that includes the upstream fix. For source-based deployments, ensure the dependency includes commit aa156a439da681361ed6f53f1a8131892418838b or a later equivalent. Rebuild and redeploy all applications, containers, and packages that vendor or bundle this Ruby module. If immediate upgrade is not possible, reduce exposure by blocking or rate-limiting WebSocket upgrade requests with abnormally long Sec-WebSocket-Extensions headers, enforcing maximum header sizes at the reverse proxy or load balancer, and rejecting extension parameter values with unterminated quotes or excessive escape sequences. Horizontal scaling may reduce impact but does not fix the vulnerable parser.

How to confirm the fix worked

Confirm dependency resolution shows websocket-extensions-ruby 0.1.5 or later, or verify the deployed source contains commit aa156a439da681361ed6f53f1a8131892418838b or equivalent parser changes. Check Gemfile.lock, bundled vendor directories, container images, and runtime package inventories for older websocket-extensions versions. Exercise a controlled test against a non-production endpoint using a malformed Sec-WebSocket-Extensions header with a long unterminated quoted parameter and verify the service rejects it quickly without sustained Ruby CPU usage. Confirm reverse proxies or application servers enforce sane HTTP header size limits and that WebSocket handshake failures are logged and rate-limited.

Typical attack path

1. Discover an internet-accessible application endpoint that supports WebSocket upgrade requests.
2. Send a WebSocket handshake request with a crafted Sec-WebSocket-Extensions header.
3. Use an unterminated quoted parameter value containing long repeated backslash-character sequences to trigger regex backtracking.
4. Force the Ruby process or worker handling the request to spend excessive CPU parsing the header.
5. Repeat or parallelize requests until application workers are saturated and legitimate WebSocket or HTTP traffic is delayed or dropped.

How to detect it

Look for evidence of attempted or successful denial-of-service activity around WebSocket handshake endpoints. Relevant log sources include reverse proxy access logs, web server logs, load balancer logs, WAF events, application request logs, Ruby application server logs, APM traces, and host metrics for Ruby worker CPU usage. Search for HTTP requests containing Upgrade: websocket and Sec-WebSocket-Extensions headers that are unusually long, malformed, or include quoted parameter values without a closing quote. Correlate these requests with spikes in ruby, puma, thin, unicorn, passenger, or application worker CPU consumption; increased request latency; request queue depth; worker timeouts; 400/408/499/500/502/503/504 responses; or process restarts. Because the attack primarily causes CPU exhaustion and may not leave a file artifact, detection depends on retained HTTP headers and timing correlation between malformed handshake requests and service degradation.

• Sec-WebSocket-Extensions
• Upgrade: websocket
• Connection: Upgrade
• Sec-WebSocket-Extensions: permessage-deflate
• Sec-WebSocket-Extensions: x-webkit-deflate-frame
• Sec-WebSocket-Extensions: .*="(\\.){50,}
• Sec-WebSocket-Extensions: .*="(\\[^"\\]){50,}
• HTTP request with Upgrade: websocket and an unterminated quoted value in Sec-WebSocket-Extensions
• HTTP request with Sec-WebSocket-Extensions header length greater than normal baseline
• ruby process sustained high CPU during WebSocket handshake traffic
• puma worker timeout correlated with Sec-WebSocket-Extensions
• passenger worker timeout correlated with Sec-WebSocket-Extensions
• unicorn worker timeout correlated with Sec-WebSocket-Extensions

What your security team should do

• Inventory applications and services that expose WebSocket endpoints and use Ruby dependencies, especially faye/websocket-extensions-ruby.
• Prioritize patching internet-facing WebSocket services to websocket-extensions-ruby 0.1.5 or later, or a build containing commit aa156a439da681361ed6f53f1a8131892418838b.
• Add temporary WAF, reverse proxy, or load balancer controls to reject unusually long Sec-WebSocket-Extensions headers and malformed quoted extension parameters.
• Monitor Ruby application workers for CPU spikes correlated with WebSocket handshake requests or HTTP 400/500 responses involving Sec-WebSocket-Extensions.
• Review historical access logs for suspicious repeated WebSocket upgrade attempts with oversized or malformed Sec-WebSocket-Extensions headers.
• Ensure application performance monitoring alerts detect worker saturation, request queue growth, and event-loop blocking conditions.