CVE-2026-49860: Deno Runtime Auth Bypass Vulnerability

CVE-2026-49860 Overview

CVE-2026-49860 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] affecting the Deno JavaScript, TypeScript, and WebAssembly runtime in versions prior to 2.8.1. When a WebSocket connection is opened, Deno checks the destination hostname against --deny-net rules but does not re-check the IP addresses the hostname resolves to. An attacker-controlled script can use a specially crafted domain that passes the hostname check yet resolves to a denied IP address, bypassing the network restriction entirely. The issue is fixed in Deno 2.8.1.

Critical Impact
A sandboxed Deno script can bypass --deny-net controls and open WebSocket connections to internal hosts intended to be unreachable, enabling SSRF against private services.

Affected Products

Deno runtime versions prior to 2.8.1
Applications relying on Deno --deny-net to restrict WebSocket destinations
Multi-tenant or sandboxed Deno execution environments

Discovery Timeline

2026-06-23 - CVE-2026-49860 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-49860

Vulnerability Analysis

Deno enforces network egress restrictions through the --deny-net permission flag, which accepts hostnames, IPs, or CIDR ranges. When a script initiates a WebSocket handshake, the runtime evaluates the target hostname string against the deny list. The flaw lies in the omission of a second check after DNS resolution returns concrete IP addresses.

An attacker who controls a domain can configure its DNS records to point to an IP address that is present on the deny list, such as 127.0.0.1, 169.254.169.254, or an internal RFC 1918 address. The hostname itself does not match any deny rule, so the check passes. Deno then resolves the hostname and connects the WebSocket to the denied IP, defeating the sandbox boundary.

This behavior falls under [CWE-918] Server-Side Request Forgery because the runtime acts as a confused deputy: it uses attacker-influenced input to reach resources the caller could not access directly.

Root Cause

The permission check operates only on the textual hostname provided to the WebSocket API. The post-resolution IP comparison performed for HTTP fetches is not applied to the WebSocket code path, leaving a parity gap between transport handlers.

Attack Vector

Exploitation requires the ability to execute Deno code in a process configured with --allow-net plus selective --deny-net entries. A malicious script issues new WebSocket("wss://attacker.example/") where attacker.example resolves to a denied internal address. The WebSocket connects to the internal service, allowing the script to probe or interact with hosts intended to be blocked. Technical details are available in the GitHub Security Advisory.

Detection Methods for CVE-2026-49860

Indicators of Compromise

Deno processes running versions earlier than 2.8.1 with --allow-net combined with --deny-net flags.
Outbound WebSocket connections from Deno workloads to internal RFC 1918 addresses or cloud metadata endpoints such as 169.254.169.254.
DNS queries from Deno hosts resolving external domains to loopback or link-local addresses.

Detection Strategies

Inventory Deno runtime versions across build agents, edge functions, and serverless workloads and flag any below 2.8.1.
Correlate DNS resolution logs with WebSocket connection telemetry to identify external hostnames resolving to internal IPs.
Inspect application logs for WebSocket handshake errors or unusual wss:// destinations originating from sandboxed code.

Monitoring Recommendations

Forward Deno process telemetry, DNS logs, and network flow data to a centralized analytics platform for correlation.
Alert on egress connections from Deno workloads to cloud metadata services and internal management subnets.
Track changes to --deny-net configurations in container images and CI/CD pipelines.

How to Mitigate CVE-2026-49860

Immediate Actions Required

Upgrade Deno to version 2.8.1 or later on every host, container image, and CI runner that executes untrusted code.
Audit existing deployments using --deny-net to confirm they enforce the intended boundary after upgrade.
Block egress from Deno workloads to cloud metadata IPs and internal management ranges at the network layer.

Patch Information

The vulnerability is fixed in Deno 2.8.1. The fix re-checks resolved IP addresses against --deny-net rules before completing the WebSocket connection. Refer to the GitHub Security Advisory GHSA-83pc-3rw9-qpwj for the official remediation notes.

Workarounds

Enforce network egress restrictions at the host firewall or service mesh level rather than relying solely on Deno --deny-net.
Run untrusted Deno scripts inside network namespaces that cannot reach internal subnets or metadata services.
Disable WebSocket APIs where not required by overriding the global WebSocket constructor before loading untrusted code.

bash

# Configuration example: upgrade and verify Deno runtime
deno upgrade --version 2.8.1
deno --version

# Run with stricter egress restrictions enforced outside Deno
iptables -A OUTPUT -m owner --uid-owner deno -d 169.254.169.254 -j DROP
iptables -A OUTPUT -m owner --uid-owner deno -d 10.0.0.0/8 -j DROP