CVE-2026-49411 Overview
CVE-2026-49411 is an access control weakness [CWE-284] in the Deno JavaScript, TypeScript, and WebAssembly runtime. Versions prior to 2.8.0 check network permissions against the original hostname string before name resolution and fail to re-check after resolution. Attackers can supply numeric aliases of IP addresses, such as the decimal integer 2130706433 or the hexadecimal form 0x7f000001, to reach denied destinations through node:net.connect or node:http.request using the { host, port } options form. The flaw lives in the Node.js compatibility TCP path and is fixed in Deno 2.8.0.
Critical Impact
Code running under restrictive Deno permissions can bypass --allow-net allowlists and connect to internal or loopback services that should remain unreachable.
Affected Products
- Deno runtime versions prior to 2.8.0
- Applications using the node:net compatibility module under Deno
- Applications using the node:http compatibility module with { host, port } request options
Discovery Timeline
- 2026-06-23 - CVE-2026-49411 published to NVD
- 2026-06-23 - Last updated in NVD database
Technical Details for CVE-2026-49411
Vulnerability Analysis
The vulnerability resides in Deno's Node.js compatibility layer, which exposes the node:net and node:http APIs to user code. When a script calls net.connect({ host, port }) or http.request({ host, port }), Deno consults its network permission list to decide whether the destination is allowed. The check compares the literal host string supplied by the caller against the configured allowlist before the host is resolved to an IP address. After the runtime resolves the value to an actual address, no second permission check occurs against the resolved IP.
This time-of-check to time-of-use gap allows callers to launder a denied destination through any string form that parses to a permitted-looking value but resolves to a denied one. The decimal integer 2130706433 and the hexadecimal literal 0x7f000001 both resolve to 127.0.0.1, yet neither matches a textual 127.0.0.1 entry in the permission allowlist during the pre-resolution check.
Root Cause
The root cause is improper access control [CWE-284] driven by a missing post-resolution re-check. Permission enforcement trusts the unresolved hostname token instead of the address the runtime ultimately dials. Numeric IP aliases supported by the underlying socket layer broaden the set of strings that map to the same destination, defeating string-based allowlist comparisons.
Attack Vector
A local attacker, or untrusted code loaded into a Deno process with restricted --allow-net permissions, calls node:net.connect or node:http.request with a numeric alias of a forbidden host. The permission engine sees an unfamiliar string, the socket layer resolves it to the real IP, and the connection proceeds. Typical targets include loopback services, cloud metadata endpoints, and other internal addresses the operator explicitly excluded from the allowlist. Exploitation requires local access and low privileges, with no user interaction.
No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-v8fw-85r8-5m23 for vendor technical details.
Detection Methods for CVE-2026-49411
Indicators of Compromise
- Outbound TCP connections from Deno processes to internal or loopback addresses that should be blocked by --allow-net
- Source code or runtime telemetry showing host values passed as decimal integers or 0x-prefixed hexadecimal strings to node:net or node:http APIs
- Deno runtime versions earlier than 2.8.0 reported by package inventory or runtime version probes
Detection Strategies
- Inventory Deno installations across developer workstations, build agents, and servers and flag any version below 2.8.0
- Perform static analysis of Deno workloads for calls to net.connect, http.request, or https.request that accept untrusted host values without numeric-form validation
- Correlate process telemetry from the Deno binary with connection events to denied subnets, including 127.0.0.0/8, 169.254.169.254, and RFC1918 ranges
Monitoring Recommendations
- Log all outbound connections initiated by Deno processes and alert on destinations outside the documented allowlist
- Capture command-line arguments for Deno processes to confirm --allow-net scope and detect overly permissive invocations
- Track DNS and direct-IP resolution events tied to Deno PIDs for follow-up investigation
How to Mitigate CVE-2026-49411
Immediate Actions Required
- Upgrade Deno to version 2.8.0 or later on all hosts running untrusted or third-party code
- Audit Deno applications that rely on --allow-net allowlists for hostnames rather than IP CIDR ranges
- Restrict outbound network egress from Deno workloads at the host or network layer as defense in depth
Patch Information
Deno 2.8.0 fixes the issue by re-checking permissions against the resolved destination after hostname resolution in the Node.js compatibility TCP path. Refer to the GitHub Security Advisory GHSA-v8fw-85r8-5m23 for the official fix details.
Workarounds
- Validate or normalize any caller-supplied host value before passing it to node:net or node:http, rejecting non-standard numeric forms
- Enforce egress restrictions at the OS firewall or container network policy so denied destinations are unreachable regardless of runtime permission state
- Avoid loading untrusted code into Deno processes that hold any --allow-net grant until the runtime is patched
# Upgrade Deno to the patched release
deno upgrade --version 2.8.0
# Verify the installed version
deno --version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
