Deno: WebSocket API sandbox bypass via missing post-DNS check

Vulnerability

In Deno, when a WebSocket connection is opened, the hostname provided is checked against --deny-net rules, but the IP addresses that hostname resolves to are not re-checked after DNS resolution [1][2]. This allows an attacker-controlled script to use a domain name that passes the hostname check yet resolves to a denied IP, effectively bypassing the network restriction. The affected functionality is the WebSocket API; Deno.connect and fetch() are not affected by this specific issue [1]. All versions of Deno prior to the fix (exact version not disclosed in the available references) are vulnerable.

Exploitation

To exploit this vulnerability, an attacker must be able to execute untrusted or third-party code with deno run while --deny-net is active [1][2]. The attacker crafts a domain name that does not match any denied hostname pattern (e.g., a domain that resolves to 127.0.0.1 but is not literally localhost) and uses it in a WebSocket connection. Since Deno only validates the hostname string at the time of the request and does not re-validate the resolved IP addresses, the connection proceeds to the blocked network endpoint. No additional privileges or user interaction are required beyond running the malicious script.

Impact

A successful exploit allows code running under --deny-net to connect to hosts that the user intended to block, such as localhost or other internal services [1][2]. This circumvents network isolation rules, potentially leading to information disclosure or further exploitation of internal services. The attacker gains the ability to make outbound WebSocket connections to denied IP addresses, breaking the sandbox restrictions intended by --deny-net.

Mitigation

No workaround is available short of upgrading Deno to a version that includes the fix (the exact fixed version is not yet published in the available references) [1][2]. If immediate upgrade is not possible, users should avoid granting --allow-net to untrusted code that also has --deny-net restrictions they depend on for security. The advisory does not list any EOL status or inclusion in the CISA KEV catalog.