7.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-44726

CVE-2026-44726: Deno: TLS retry copies stale upgrade hook, risking plaintext traffic

Deno is a JavaScript, TypeScript, and WebAssembly runtime. From 2.0.0 until 2.7.8, a flaw in Deno's Node.js tls compatibility layer could cause a TLS client to transmit application data in plaintext after a connection retry. When `autoSelectFamily was enabled and the first address-family attempt failed, the socket reinitialization path reused a stale TLS upgrade hook that was bound to the original, failed handle. As a result, the replacement TCP connection was never upgraded to TLS, and any data the application wrote before the secureConnect event travelled over the network unencrypted. A network attacker positioned to cause the initial connection attempt to fail (for example, by dropping IPv6 traffic on a dual-stack host) could deterministically trigger the fallback path and observe or tamper with traffic that the application believed was TLS-protected. This vulnerability is fixed in 2.7.8.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-44726

CVE-2026-44726:

7.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
deno	rust	>= 2.0.0, < 2.7.8	2.7.8

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability exists in Deno's Node.js compatibility layer for node:tls and node:https. When a TLS connection is attempted with autoSelectFamily: true (the default), Deno tries to connect to available IP addresses for a host. If the first attempt fails (e.g., an attacker dropping packets for an IPv6 address), Deno's logic attempts to fall back and try the next address (e.g., IPv4).

This fallback mechanism involves reinitializing the underlying network socket. The vulnerability lies in this reinitialization process. The function Socket.prototype[kReinitializeHandle] in ext/node/polyfills/net.ts was responsible for this. It would copy the TLS upgrade hook (afterConnectTls) from the old, failed socket handle to the new one.

However, the afterConnectTls hook, defined in the TLSSocket constructor (ext/node/polyfills/_tls_wrap.js), was implemented as an arrow function that captured the original socket handle. Because of this, when the fallback occurred and the hook was called on the new connection, it was still operating on the context of the old, failed handle.

As a result, the startTls function was never correctly called for the new, successful TCP connection. The connection was never upgraded to TLS. The application, believing it had a secure TLS socket, would then write data (like HTTP headers with authentication tokens) to the socket, which would be transmitted in plaintext over the network.

The fix involves two parts:

In TLSSocket.constructor, the afterConnectTls hook was changed from an arrow function to a regular function that uses this to refer to the current handle, ensuring it always operates on the active connection.
In Socket.prototype[kReinitializeHandle], the logic was updated to not just copy the hook, but to also rebuild the entire promise-based state (upgrading, afterConnectTlsResolve, etc.) that tracks the TLS upgrade process. This ensures the new handle is properly configured for a fresh TLS handshake.

An attacker on the network path could deterministically trigger this vulnerability by selectively dropping connection attempts to the first IP address resolved for a dual-stack host, forcing the fallback to an address they control, and then intercepting the resulting plaintext traffic.

Vulnerable functions

Socket[kReinitializeHandle]

ext/node/polyfills/net.ts

This function is responsible for reinitializing a socket handle during connection retry. The vulnerable version copied the `afterConnectTls` hook from the old, failed handle to the new one. This hook, however, was bound to the stale handle's context. When executed, it failed to upgrade the new connection to TLS, causing subsequent data to be sent in cleartext. The fix involves rebuilding the entire TLS upgrade state for the new handle, not just copying the hook.

TLSSocket

ext/node/polyfills/_tls_wrap.js

The TLSSocket constructor defines the `afterConnectTls` hook. In the vulnerable version, this was an arrow function that captured the `handle` variable from its lexical scope. When a connection failed and the socket was reinitialized, this hook was copied to the new handle but still referenced the original, stale handle. As a result, the `startTls` function was called on the wrong handle, and the new connection was never upgraded to TLS.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.