CVE-2026-55517: Deno WebSocket Client Denial-of-Service Vulnerability
Deno, a modern JavaScript/TypeScript runtime, has a flaw in how it processes WebSocket connection responses. When a remote server sends back specially crafted response headers containing non-ASCII bytes, Deno crashes entirely rather than handling the malformed data gracefully. An attacker controlling a WebSocket server could exploit this to deny service to any Deno client that connects to it. The issue affects Deno versions before 2.7.5 and is resolved in that release.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 4.3 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
- Weaknesses (CWE)
- CWE-248
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-23 / 2026-06-29
NVD description (verbatim)
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.
1 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-55517 is a denial-of-service vulnerability in Deno's WebSocket client implementation. During the WebSocket handshake, Deno parses the Sec-WebSocket-Protocol and Sec-WebSocket-Extensions response headers with an unsafe assumption that their byte values fall within the printable ASCII range (0x00-0x7F). When a remote WebSocket server responds with headers containing bytes in the non-visible ASCII range (0x80-0xFF), the parser panics and terminates the entire Deno process. This occurs because the code does not validate or sanitize header bytes before processing, violating CWE-248 (Uncaught Exception). The vulnerability requires network access and user interaction (a Deno program must initiate the WebSocket connection), but no authentication or privileges are needed from the attacker's perspective.
Business impact
For organizations running Deno-based applications or services, this vulnerability creates an availability risk. Any user or service connecting to a malicious or compromised WebSocket endpoint will experience an unexpected process crash, disrupting whatever work was in progress. In production environments, this could trigger cascading failures if the crashed process handles critical operations. The impact is amplified in scenarios where Deno services are exposed to untrusted WebSocket servers or where user input influences which servers applications connect to. Patch deployment is straightforward and carries no backward-compatibility concerns.
Affected systems
All Deno installations prior to version 2.7.5 are affected. This includes any JavaScript, TypeScript, or WebAssembly application running on vulnerable Deno versions that uses the WebSocket client API (either directly or through a library). The vulnerability is triggered only when a program initiates an outbound WebSocket client connection, so server-side WebSocket listeners are not affected. Organizations should inventory Deno deployments and verify version numbers across development, staging, and production environments.
Exploitability
Exploitation is straightforward for an attacker who can control or intercept a WebSocket server endpoint. No special tools, authentication, or user privileges are required—only the ability to respond to a WebSocket handshake with a crafted response header. The attack requires user interaction in the sense that a Deno program must actively connect to the attacker's server, but this is a low bar in environments where applications consume external WebSocket APIs or where user-supplied URLs determine connection targets. Once triggered, the crash is reliable and immediate. However, real-world exploitation is somewhat limited by the attacker's need to position themselves as a WebSocket endpoint that a target application will connect to.
Remediation
Upgrade Deno to version 2.7.5 or later. This release fixes the header parsing logic to properly validate and handle non-ASCII bytes in Sec-WebSocket-Protocol and Sec-WebSocket-Extensions headers without panicking. Verify against the vendor advisory that your deployed version corresponds to 2.7.5 or a later stable release. No configuration changes or application code modifications are required.
Patch guidance
Patching requires updating your Deno binary. If you use a version manager (like dvm or asdf), update to Deno 2.7.5 or later using its standard update mechanism. If you manage Deno binaries directly, download the 2.7.5 release from the official Deno repository and replace your current binary, ensuring you test in a non-production environment first. Verify the patched version by running `deno --version`. No data migration, configuration changes, or rollback risks are associated with this update. Given the low CVSS score and the simplicity of patching, a standard change-management process is appropriate rather than emergency protocols.
Detection guidance
Monitor for unexpected Deno process terminations or crashes, particularly in applications that use WebSocket clients. Log collection from Deno processes may show panic messages or stack traces mentioning WebSocket header parsing. In network monitoring, look for WebSocket handshake responses containing non-ASCII bytes in header fields—though this is more relevant for identifying malicious servers than for incident response. If you suspect exploitation, review application logs for WebSocket connection attempts to external or suspicious endpoints around the time of crashes. Patching to 2.7.5 will automatically resolve the condition.
Why prioritize this
This vulnerability should be addressed promptly but does not warrant emergency response. While exploitable with low complexity, it requires either a user to connect to an attacker-controlled server or an attacker to intercept a legitimate WebSocket connection. The CVSS score of 4.3 (MEDIUM) reflects limited availability impact in most scenarios. However, applications that connect to untrusted or user-specified WebSocket endpoints face higher risk and should patch first. The patch is non-disruptive and carries no compatibility risks, making it a straightforward maintenance task.
Risk score, explained
The CVSS 3.1 score of 4.3 reflects a network-accessible, low-complexity denial-of-service vulnerability with no authentication required and no scope expansion. The score is held at MEDIUM rather than HIGH because the impact is limited to availability and requires either user interaction (a program must connect to the malicious server) or a specific attacker positioning (as a WebSocket endpoint). Availability impact is rated LOW because the vulnerability crashes only the affected Deno process, not the broader system, and there is no data loss or confidentiality/integrity compromise.
Frequently asked questions
Does this affect WebSocket servers built with Deno?
No. The vulnerability is in Deno's WebSocket client implementation, triggered during outbound connections. Deno-based WebSocket servers that receive connections are not affected. Only programs that initiate WebSocket client connections are at risk.
Can this be exploited if our Deno app only connects to internal or trusted servers?
The risk is very low in that scenario. Exploitation requires the attacker to control or intercept the WebSocket endpoint. If your application only connects to internal servers you fully control, your exposure is minimal. However, if applications connect to third-party APIs, user-supplied URLs, or any external endpoint, the risk is higher.
What happens when Deno crashes due to this vulnerability?
The entire Deno process terminates abruptly. Any in-flight operations are interrupted, and the program must be restarted. In production, this could disrupt service availability. Process managers (like systemd or PM2) can auto-restart crashed Deno processes, but this results in downtime and potential data loss if operations were not persisted.
Is there a workaround if we cannot patch immediately?
The most practical workaround is to restrict or validate which WebSocket endpoints your Deno applications connect to. Avoid connecting to untrusted servers or accepting user-supplied WebSocket URLs without validation. However, patching to 2.7.5 is strongly preferred, as the patch is simple and carries no risk.
This analysis is provided for informational purposes and does not constitute professional security advice. Organizations should verify all technical claims against official Deno security advisories and release notes before taking action. CVSS scores and severity ratings are industry-standard assessments but should be evaluated in the context of your specific environment and risk tolerance. Patch testing in a non-production environment is always recommended before enterprise deployment. For the most current information, consult the official Deno repository and security documentation. Source: NVD (public-domain), retrieved 2026-07-29. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-12644MEDIUMts-deepmerge Denial of Service via Prototype Method Injection
- CVE-2026-45554MEDIUMNiceGUI Static Asset Route Log Flooding Vulnerability
- CVE-2026-45676MEDIUMOpenTelemetry eBPF Instrumentation ELF Parser Denial of Service
- CVE-2026-46411MEDIUMFlashMQ Authentication DoS via Write Buffer Overflow
- CVE-2026-45685HIGHOpenTelemetry eBPF Instrumentation MongoDB Parser DoS (v0.1.0–0.8.x)
- CVE-2026-46545HIGHNimiq State Sync Denial-of-Service Vulnerability (CVSS 7.5)
- CVE-2026-49406MEDIUMDeno Path Traversal in BYONM Module Resolution
- CVE-2026-49411MEDIUMDeno Permission Bypass via Numeric IP Aliases in Node.js Compatibility Layer