SafeFetch's DNS-rebinding connection pin is a silent no-op under Bun

[sroussey]

SafeFetch.server.ts documents four protections in its header, the fourth being:

4. Connection pinning via an undici Agent whose connect.lookup hook returns the pre-resolved IP — this prevents a second DNS lookup at connect time and defeats DNS rebinding (TOCTOU).

Under Bun that protection does nothing. Bun resolves undici to its own built-in compatibility shim, whose Agent is an inert stub: the dispatcher option passed to undiciFetch is ignored outright, so the request goes through Bun's ordinary fetch and the OS resolver runs again at connect time — exactly the second lookup the pin exists to prevent.

This matters because it is runtime-dependent and passes review either way: the protection is genuine under Node, and @workglow/sec ships a #!/usr/bin/env bun CLI.

Reproducer

Pin connect.lookup at a black-hole address. If the dispatcher were honored the request could not reach 127.0.0.1.

import { Agent, fetch as undiciFetch } from "undici";

const server = Bun.serve({ port: 0, fetch: () => new Response("served") });
const dispatcher = new Agent({
  connect: { lookup: (_h, _o, cb) => cb(null, "192.0.2.1", 4) },
});

const res = await undiciFetch(`http://localhost:${server.port}/`, {
  dispatcher,
  redirect: "manual",
  signal: AbortSignal.timeout(3000),
});
console.log(res.status, await res.text());

bun  (1.3.11): status: 200 body: served   => dispatcher IGNORED
node (22.22.2): failed => dispatcher honored: fetch failed

What Bun's Agent actually is:

own props:   ["_events","_eventsCount","_maxListeners"]
proto props: ["constructor"]

An EventEmitter with a constructor and nothing else — no close, no dispatch, no connection pool.

Related: the closeAgent comment is wrong in the same way

/**
 * Close an undici {@link Agent} if it exposes a `close` method.
 * Bun can load undici in a way where `Agent` instances lack `close` on the
 * prototype ...
 */
function closeAgent(dispatcher: Agent): void {
  void dispatcher.close?.().catch(() => {});
}

Under Bun close is not merely sometimes absent, it is always absent, so closeAgent is unconditionally a no-op there. That is currently harmless — the stub holds no sockets, so there is nothing to free — and I want to be explicit that this is not a leak, because it is easy to read it as one:

• 5,000 un-closed Agents driven through the real fetch path on Bun 1.3.11: RSS 40MB → 57MB (the step is first-1000 warmup), heapUsed flat at 1–2MB across the run and after a forced GC.
• Descriptor count tracks peak concurrent requests (~2 per in-flight request), is flat across repeated rounds at fixed concurrency, and returns to baseline after ~20s idle. That is Bun's own fetch pool, not the Agents.

So the bug here is the security no-op, not resource retention. The comment should say the Bun path never closes and never needs to, rather than implying a best-effort cleanup that sometimes succeeds.

Suggested direction

Not obviously a small fix, since the pin is the mechanism:

1. Detect at load whether dispatcher is honored (the probe above is cheap and deterministic) and, when it is not, either fall back to a re-validating lookup or refuse to register serverSafeFetch as providing rebinding protection — the important part being that the failure is stated rather than silent.
2. Alternatively resolve and connect to the pinned IP directly with Host/SNI preserved, which does not depend on dispatcher support.

Happy to take this if you want a direction picked.

[sroussey]

Re-tested on Bun 1.4 — unchanged, the issue stands

Tested against 1.4.0-canary.1+a5c86aec7. (bun upgrade --canary fails on the 1.3.11 build in this container — it errors This command updates Bun itself, and does not take package names even for a bare bun upgrade — so the canary came from the install script: BUN_INSTALL=<dir> bash install.sh canary.)

1. The dispatcher is still ignored. Same black-hole-pin reproducer from the issue body:

bun 1.4.0-canary.1+a5c86aec7 : status: 200 body: served  => dispatcher IGNORED
bun 1.3.11                   : status: 200 body: served  => dispatcher IGNORED
node 22.22.2                 : failed => dispatcher honored: fetch failed

2. Agent is still an inert stub, byte-for-byte the same shape as on 1.3.11:

close: undefined | in: false
own props:   ["_events","_eventsCount","_maxListeners"]
proto props: ["constructor"]

3. Still not a leak. 5,000 un-closed Agents driven through the real fetch path:

	1.3.11	1.4.0-canary
RSS before	40MB	28MB
RSS after 5,000	56MB	39MB
RSS after forced GC	57MB	38MB
heapUsed throughout	1–2MB	1–2MB

Flat on both; the step is first-1000 warmup.

4. Descriptor behaviour is also unchanged, which matters only because it is the thing this is most often mistaken for. Driving the real serverSafeFetch against a slow local server:

concurrent requests	peak fds (1.3.11)	peak fds (1.4.0-canary)
40	98	92
200	418	412

~2 descriptors per in-flight request on both, flat across repeated rounds at fixed concurrency, returning to baseline once the pool idles. That is Bun's own fetch pool tracking concurrency, not Agents accumulating.

So 1.4 does not close the gap: the DNS-rebinding pin remains inactive on Bun, and the fix still has to come from our side — either the load-time probe that states the failure rather than swallowing it, or connecting to the pinned IP directly with Host/SNI preserved.

---

Generated by Claude Code