Greptile Summary

This PR fixes a complete attachment download failure on Node 24+ BlueBubbles deployments: the SSRF guard was injecting a bundled undici 8.x Agent as dispatcher into init, which then crashed Node's built-in fetch (undici 7.x) with invalid onRequestStart method. The fix strips dispatcher before forwarding init to blueBubblesFetchWithTimeout.

• The SSRF hostname validation (resolvePinnedHostnameWithPolicy) still runs before fetchImpl is called, so host-allowlist and private-network checks are preserved.
• However, stripping the pinned dispatcher means Node's fetch performs a fresh DNS lookup at connection time, removing the DNS-rebinding protection the pinned dispatcher was designed to provide. For typical BlueBubbles (LAN) deployments the risk is low, but it is a genuine regression in the SSRF guard's defence-in-depth.

Confidence Score: 4/5

Safe to merge for fixing the crash, but the DNS-rebinding regression in the SSRF guard warrants acknowledgment before landing.

The fix correctly resolves a complete attachment download failure. The one concern worth addressing is that stripping the pinned dispatcher removes DNS-rebinding protection — a real (if low-risk for LAN BlueBubbles setups) security regression relative to the guard's design. A style cleanup on the redundant casts is also suggested but non-blocking.

extensions/bluebubbles/src/attachments.ts — specifically the fetchImpl lambda and how it interacts with the SSRF guard's dispatcher lifecycle.

This is a comment left during a code review.
Path: extensions/bluebubbles/src/attachments.ts
Line: 131-141

Comment:
**DNS pinning bypassed by stripping dispatcher**

Stripping `dispatcher` fixes the undici compatibility crash, but the pinned dispatcher exists specifically to prevent DNS rebinding: it resolves the hostname, validates the IP, then pins the TCP connection to that exact IP so a mid-flight DNS change can't redirect the request to a private/blocked address. After this change, Node's built-in `fetch` does a fresh DNS lookup at connection time, making the validated-but-not-yet-connected window susceptible to rebinding.

In practice the risk is low for BlueBubbles (user-owned server, typically LAN), but it is a real security regression relative to the intent of the SSRF guard. A safer approach is to pass a `lookupFn` (or an `allowedHostnames`-scoped hostname check) that `blueBubblesFetchWithTimeout` can honour, or to open a seam in `blueBubblesFetchWithTimeout` that accepts a pre-resolved IP so the guard's resolution result can be reused without injecting an undici dispatcher.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/bluebubbles/src/attachments.ts
Line: 132-138

Comment:
**Redundant casts and optional chain on a known object**

`safeInit` is already `Record<string, unknown>` (TypeScript infers this from the rest-spread of a `Record<string, unknown>`), so the `as Record<string, unknown>` re-assertion on line 137 and the `?.` optional chain are both no-ops. The final `as RequestInit` assertion is also unverified — any extra unknown keys survive the spread. A narrower, explicit pick would be safer:

```suggestion
        const { dispatcher: _d, ...safeInit } = (init ?? {}) as Record<string, unknown>;
        return await blueBubblesFetchWithTimeout(
          resolveRequestUrl(input),
          {
            ...safeInit,
            method: (safeInit.method as string | undefined) ?? "GET",
          } as RequestInit,
          opts.timeoutMs,
        );
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(bluebubbles): strip SSRF dispatcher ..." | Re-trigger Greptile}

Same root cause in the Slack extension — submitted #64022 with the equivalent fix for createSlackMediaFetch(). This dispatcher version collision pattern likely affects any extension that receives init from fetchWithSsrFGuard and delegates to a different fetch path.

The merged Slack fix (#62239) solved this same problem without the DNS-pinning regression — instead of stripping dispatcher, it routes through fetchWithRuntimeDispatcher (bundled undici's fetch) which is compatible with the bundled undici's dispatcher:

fetchImpl: async (input, init) => {
  const useFetch = init && "dispatcher" in init
    ? fetchWithRuntimeDispatcher
    : globalThis.fetch;
  return await useFetch(
    resolveRequestUrl(input),
    { ...init, method: init?.method ?? "GET" },
  );
},

This closes the rebinding window that the Greptile review flagged — the dispatcher stays intact so the SSRF guard's pinned connection is preserved. I hit this bug on a BlueBubbles + Node 25.6.0 setup and confirmed this approach works (attachments download, DNS pinning intact).

Also makes the redundant casts a non-issue since init passes through unmodified.

Closing in favor of a cleaner approach that uses fetchWithRuntimeDispatcher (matching the Slack fix #62239) instead of stripping the dispatcher. New PR incoming.