Before version 2.8.1, Deno's WebSocket API was intended to enforce the --deny-net network restrictions by validating the hostname of an outgoing connection. The implementation, however, failed to re‑check the IP addresses that the hostname resolved to, allowing an attacker to craft a domain that passes the hostname check yet points to a denied IP address. This flaw enabled a sandbox bypass via WebSocket connections, turning the network restrictions into a no‑op. The vulnerability, a DNS rebinding issue (CWE‑918), was corrected in Deno 2.8.1.

Versions of Deno released before 2.8.1 are vulnerable. The fix was introduced in Deno 2.8.1. All products that run unmodified Deno code prior to that version are impacted.

The CVSS score of 5.2 indicates moderate severity, and there is no EPSS score or KEV listing, suggesting that zero‑day exploitation data is not known. The attack requires that the attacker be able to execute code that calls the Deno WebSocket API; this could occur in a local script or a compromised web page that the user is allowed to run in Deno. Since the vulnerability allows circumventing the deny‑net restrictions, an attacker who can trigger the WebSocket can potentially access any resource reachable from the host, increasing the impact to confidentiality and availability of internal services. The likely attack vector is a malicious script run within the Deno runtime, or an application that internally invokes the WebSocket API with attacker‑controlled input, inferred from the described behavior.