CVE-2026-49860: Deno: WebSocket API sandbox bypass via missing post-DNS check
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-net to 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.
Other sources
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, 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. This vulnerability is fixed in 2.8.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/denoto a version that resolves this vulnerability.Fixed in 2.8.1 - Upgrade
Upgrade
denoto a version that resolves this vulnerability.Fixed in 2.8.1 - Configuration
Avoid granting `--allow-net` to untrusted code that would otherwise rely on `--deny-net` for security, since the issue involves bypassing `--deny-net` via hostname resolution during WebSocket connections (fixed in Deno 2.8.1).
Deno runtime (network access controls) --allow-net = do not grant --allow-net to untrusted code that also has network-deny rules - Configuration
Workaround described: rely on `--deny-net` to restrict which hosts code can reach; note that in versions prior to 2.8.1 a WebSocket opened could bypass this restriction due to missing post-DNS IP re-check.
Deno runtime --deny-net = use to restrict which hosts untrusted code can reach (but note bypass is fixed only by upgrading)
Event History
Frequently Asked Questions
What is the severity of CVE-2026-49860?
The severity of CVE-2026-49860 is medium with a score of 5.2.
How does CVE-2026-49860 affect Deno's WebSocket connections?
CVE-2026-49860 allows an attacker-controlled script to potentially exploit the WebSocket connection by using a crafted domain name that bypasses hostname checks.
What is the potential risk associated with CVE-2026-49860?
CVE-2026-49860 is classified as a Server-Side Request Forgery (SSRF) vulnerability, which can lead to unauthorized access to sensitive information.
How can I mitigate the risks of CVE-2026-49860?
To mitigate CVE-2026-49860, ensure that WebSocket connections are configured to validate resolved IP addresses against your specified network access rules.
When was CVE-2026-49860 published?
CVE-2026-49860 was published on June 16, 2026.