CVE-2026-49860: 
Rust Analisi e mitigazione delle vulnerabilità

CVE-2026-49860 is a sandbox bypass vulnerability in the Deno JavaScript/TypeScript runtime affecting its WebSocket API, allowing network restriction rules to be silently circumvented. When a WebSocket connection is initiated, Deno validates the destination hostname against --deny-net rules but fails to re-validate the resolved IP addresses after DNS resolution, enabling a DNS rebinding-style bypass. All Deno versions up to and including 2.8.0 are affected; the issue is patched in version 2.8.1. It carries a CVSS v3.1 base score of 5.2 (Moderate) (GitHub Advisory, Deno Advisory). The vulnerability was originally published on May 27, 2026, and added to the GitHub Advisory Database on June 16, 2026.

The root cause is classified as CWE-918 (Server-Side Request Forgery), specifically a missing post-DNS resolution check in Deno's WebSocket connection handling code. When new WebSocket(url) is called, Deno checks the hostname in the URL against configured --deny-net deny-list rules, but does not subsequently verify that the IP address the hostname resolves to is also permitted — a classic TOCTOU (time-of-check/time-of-use) pattern. An attacker-controlled script can register a domain that passes the hostname check but resolves to a blocked IP (e.g., 127.0.0.1 or an internal RFC-1918 address), effectively bypassing network isolation. Notably, Deno.connect and fetch() are not affected by this specific issue; a companion advisory addresses the fetch() variant (GitHub Advisory, Deno Advisory).

Successful exploitation allows code running under --deny-net restrictions to establish WebSocket connections to hosts the operator intended to block, including localhost and internal network services. This breaks network isolation guarantees, potentially exposing internal APIs, metadata services (e.g., cloud instance metadata endpoints), or other sensitive services to a malicious or compromised third-party dependency. The confidentiality and integrity impacts are rated low, with no availability impact, but the scope change (S:C) reflects that the affected component can influence resources outside its security boundary (GitHub Advisory).

1. Prepare a malicious domain: Register or control a domain (e.g., bypass.attacker.com) and configure its DNS to resolve to a denied IP address such as 127.0.0.1 or an internal network address (e.g., 192.168.1.1).
2. Craft a malicious script: Write a Deno script that opens a WebSocket connection to the attacker-controlled domain: new WebSocket('ws://bypass.attacker.com:8080/').
3. Deliver the script: Introduce the malicious script as a dependency or supply it directly to a victim who runs untrusted code via deno run --allow-net --deny-net=localhost,192.168.0.0/16 malicious_script.ts.
4. Bypass hostname check: Deno validates bypass.attacker.com against the --deny-net rules — the hostname passes because it is not explicitly listed.
5. Connect to denied IP: DNS resolution returns the denied IP (e.g., 127.0.0.1); Deno does not re-check the resolved IP against --deny-net rules and establishes the WebSocket connection to the internal/localhost service.
6. Exfiltrate or interact: The attacker's script communicates with the internal service (e.g., a local admin panel, cloud metadata endpoint, or database) via the established WebSocket connection, exfiltrating data or performing unauthorized actions (GitHub Advisory, Deno Advisory).

• Network: Unexpected outbound WebSocket connections (ws:// or wss://) from a Deno process to internal IP ranges (e.g., 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (e.g., 169.254.169.254).
• Network: DNS queries for domains that resolve to RFC-1918 or loopback addresses originating from a Deno runtime process.
• Logs: Deno process network activity logs showing WebSocket upgrade requests to hostnames that do not match expected allow-listed destinations.
• Process: Deno child processes spawned with both --allow-net and --deny-net flags executing scripts from third-party or unverified sources.

Upgrade Deno to version 2.8.1 or later, which introduces post-DNS resolution validation for WebSocket connections against --deny-net rules (GitHub Advisory). No configuration-based workaround fully mitigates the issue. As an interim measure, avoid granting --allow-net to untrusted code that also relies on --deny-net restrictions for security isolation. Users who do not use --deny-net or who only run fully trusted code are not affected and do not need to take immediate action (Deno Advisory).