CVE-2026-49411

Deno's network permission model is designed so that --deny-net rules apply to the resolved IP address of a destination, not just the literal string supplied by the caller. That means --deny-net=127.0.0.1 (or --deny-net=127.0.0.0/8) is expected to block any attempt to reach loopback, regardless of how the hostname is spelled.

On affected versions, the Node.js compatibility TCP path checked the permission against the original hostname string before resolution and then did not re-check after resolution. A caller could therefore pass a numeric alias of an IP address (for example the decimal integer 2130706433 or the hex form 0x7f000001, both of which resolve to 127.0.0.1) and reach the denied destination through node:net.connect or node:http.request's { host, port } options form.

The native Deno.connect(), fetch(), and URL-string variants of node:http.request("http://...") were not affected, because they either re-checked permissions after resolution or normalized the hostname through the URL parser before checking.

Proof of concept

Run on Deno 2.7.14, with a local TCP listener on 127.0.0.1:<PORT>:

import net from "node:net";

// --allow-net + --deny-net=127.0.0.0/8
// (or even --deny-net=127.0.0.1:<PORT>)
net.connect({ host: "2130706433", port: PORT });     // CONNECTED ❌
net.connect({ host: "0x7f000001", port: PORT });     // CONNECTED ❌
net.connect({ host: "127.0.0.1",  port: PORT });     // denied ✅

The same primitive reached the loopback HTTP listener through node:http when the destination was passed as options rather than as a URL string:

import http from "node:http";

// options-form host, bypasses the deny rule on affected versions
http.request({ hostname: "2130706433", port: PORT, path: "/" }).end();

// URL-string form, correctly denied (URL parser normalizes the host)
http.request(`http://2130706433:${PORT}/`).end();

The server-side log showed the bypassed requests arriving from 127.0.0.1 with the numeric alias preserved in the Host header.

Not affected

• Programs that do not use --deny-net at all (the bug is specifically about deny rules being bypassed; allow rules were always checked against the original string).
• Native Deno networking APIs (Deno.connect, Deno.connectTls, fetch, ...), these already re-checked permissions after resolution as of PR #33203.
• URL-string callers such as fetch("http://2130706433/") or node:http.request("http://2130706433/"), the URL parser normalized the hostname to its dotted-quad form before the permission check ran.
• Calls that do not provide host/hostname (e.g. connecting by IP literal or by a name that the deny rule already matches verbatim).

Workarounds

If you cannot upgrade immediately, reduce exposure by:

• Preferring an --allow-net allowlist over a --deny-net denylist. An allowlist denies numeric aliases by default because they don't match the listed hostnames; only the destinations you've explicitly permitted can be reached.
• Validating untrusted host input before passing it to node:net.connect / node:http.request. Reject hostnames that are purely decimal integers (/^\d+$/) or begin with 0x, as these are the alias forms exploited by the bypass.
• Avoiding the Node options-host path for sensitive calls in favour of URL-string forms, which are normalized by the URL parser before the permission check.

A program that intentionally allows broad outbound network access but uses --deny-net to carve out protected destinations, typically loopback, private/internal ranges, or cloud-instance metadata IPs, could be made to reach those denied destinations from less-trusted code (a dependency, plugin, or attacker-controlled input) that funnels through node:net.connect({ host }) or node:http.request({ hostname }).

The CVSS vector reflects this as a local-attack-vector, permissions-required confidentiality impact: the attacker needs to be able to run code inside the Deno process, and the demonstrated primitive is "reach an explicitly denied IP." It does not by itself exfiltrate data or execute code; the further impact depends on what the now-reachable endpoint exposes.

The confirmed scope is IPv4 numeric hostname aliases reaching a denied resolved IP through the Node TCPWrap / options-host path. URL strings, node:http2, undici, and IPv6 numeric/mapped-address variants were not exhaustively tested by the reporter.

CVE-2026-49411 has a CVSS score of 6.5 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.8.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-49411? CVE-2026-49411 is a medium-severity security vulnerability in deno (rust), affecting versions <= 2.7.14. It is fixed in 2.8.0.
2. How severe is CVE-2026-49411? CVE-2026-49411 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of deno are affected by CVE-2026-49411? deno (rust) versions <= 2.7.14 is affected.
4. Is there a fix for CVE-2026-49411? Yes. CVE-2026-49411 is fixed in 2.8.0. Upgrade to this version or later.
5. Is CVE-2026-49411 exploitable, and should I be worried? Whether CVE-2026-49411 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-49411 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-49411? Upgrade deno to 2.8.0 or later.