EUVD-2026-38542
GHSA-83pc-3rw9-qpwj
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Attacker code must already execute inside the Deno sandbox (AV:L/PR:L); sandbox escape to restricted network justifies S:C; no availability impact applies.
Primary rating from Vendor (https://github.com/denoland/deno).
CVSS VectorVendor: https://github.com/denoland/deno
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Lifecycle Timeline
2DescriptionCVE.org
Summary
When a WebSocket connection was opened, Deno checked the destination hostname against --deny-net rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely.
Impact
Code running under --deny-net could connect to hosts that the user intended to block. In practice this means network isolation rules - for example, blocking access to localhost or internal services - could be silently circumvented by a malicious or compromised dependency.
Deno.connect and fetch() were not affected by this specific issue (a companion advisory covers fetch()).
Who is affected
Users who:
- run untrusted or third-party code with
deno run, and - rely on
--deny-netto restrict which hosts that code can reach.
If you do not use --deny-net, or if you only run fully trusted code, you are not affected.
Workaround
No workaround is available short of upgrading. If upgrading immediately is not possible, avoid granting --allow-net to untrusted code that also has --deny-net restrictions you depend on for security.
AnalysisAI
WebSocket connections in Deno 2.8.0 and earlier silently bypass --deny-net network sandbox rules by exploiting a missing post-DNS-resolution IP check - the runtime validates the destination hostname but never validates the IP address that hostname resolves to, enabling a classic DNS-rebinding-style SSRF (CWE-918) within the permission system. Any script running under deno run with --deny-net restrictions can weaponize an attacker-controlled domain to reach blocked hosts such as localhost or cloud metadata endpoints (e.g., 169.254.169.254). No public exploit has been identified at time of analysis, and the issue is specific to the WebSocket API; Deno.connect and fetch() are addressed in a companion advisory.
Technical ContextAI
Deno (pkg:rust/deno) implements a capability-based permission system where --deny-net blocklists specific hostnames or IP ranges to restrict outbound network access from untrusted scripts. For WebSocket connections, the enforcement logic performed a single hostname-level match against the blocklist prior to DNS resolution. After DNS resolution, the runtime did not re-validate the resulting IP addresses against the same deny rules - the TCP connection was established directly to the resolved IP without a second permission check. This gap is classified under CWE-918 (Server-Side Request Forgery), because a malicious script can cause the runtime to make network connections to destinations the user explicitly intended to forbid. The root cause is architecturally equivalent to a DNS rebinding attack: the checked identity (hostname) and the connected identity (IP) diverge, and only the former is verified. The issue is isolated to the WebSocket code path; Deno.connect and fetch() have separate (and separately patched) IP validation logic.
RemediationAI
Upgrade Deno to version 2.8.1 or later, which is the vendor-released patch confirmed in GHSA-83pc-3rw9-qpwj (https://github.com/denoland/deno/security/advisories/GHSA-83pc-3rw9-qpwj). The vendor explicitly states no configuration-level workaround exists. As a compensating control where an immediate upgrade is not possible, remove --allow-net from any invocation of untrusted code that also relies on --deny-net for security - this eliminates the attack surface entirely by denying all network access, though it will break any functionality that requires legitimate outbound connectivity. A second compensating control is to enforce network isolation at the OS layer (e.g., Linux network namespaces, container egress firewall rules, or iptables rules blocking internal CIDRs) rather than relying solely on Deno's runtime permission system. OS-level controls are not bypassable by script-layer DNS tricks and provide a defense-in-depth layer regardless of patch status.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today