Server: Budibase: SSRF via DNS rebinding in the REST datasource integration (CVE-2026-73410)
Affects @budibase/serverSource GCVE Database
Mentioned vulnerabilities
CVSS 8.5 High : patch @budibase/server soon.
Data as of 08/12/2026, 20:13:11 UTC
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:HWhat to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| npm@budibase/server | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Until an official fix is released, restrict access to REST datasource configuration to fully trusted users only. Monitor for unusual internal service access patterns initiated via REST datasources. Avoid using untrusted hostnames in REST datasource configurations. Follow Budibase vendor advisories for updates and apply official patches once available.
Description
### Summary Budibase's central outbound-fetch guard (`fetchWithBlacklist`) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and **pinning** the connection to the validated IP. The pin is implemented as a Node `http(s).Agent` (`makePinnedAgent`). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding. The REST datasource integration (`@budibase/server`) calls `fetchWithBlacklist` but performs the actual request with **undici**'s `fetch`. undici does not support the Node `agent` option — it is silently ignored — and instead uses its own `dispatcher`, which re-resolves the hostname's DNS at connection time. As a result, **the validated/pinned IP is never used on the REST datasource path**, and the DNS-rebinding protection that CVE-2026-54353 added is silently defeated for the single most-used outbound path in Budibase. An authenticated user who can configure/run a REST datasource (e.g. a builder/tenant) can use a rebinding hostname (public IP during validation, internal IP at connect) to make the server issue arbitrary, full-response HTTP requests to internal-only services — cloud metadata (IAM credential theft), the internal CouchDB/Redis/MinIO, and other internal endpoints — reading and, because REST datasources allow arbitrary method/body, writing or destroying internal data. ### Details **The guard pins the validated IP via a Node agent** — `packages/backend-core/src/utils/outboundFetch.ts`: - `resolveSafePinnedIp(url)` resolves the hostname and checks every address against `isBlacklisted`, returning a single `pinnedIp` (lines ~39–53). - `makePinnedAgent(url, ip)` builds a **Node** `http.Agent`/`https.Agent` whose `lookup` always returns `pinnedIp`, so a node-fetch connection can only reach the validated IP (lines ~55–68). - `fetchWithBlacklist` passes that agent into the request: `fetchFn(nextUrl, { ...nextRequest, agent: makePinnedAgent(nextUrl, pinnedIp) })` (lines ~186–192). Each redirect hop is re-validated and re-pinned in the loop. **The REST integration overrides the transport with undici, which ignores `agent`** — `packages/server/src/integrations/rest.ts`: - `fetch` is imported from **`undici`** (top-of-file import block, ~line 30). - The request is made by overriding `fetchFn` (lines ~767–793): ```ts const setDispatcher = (requestInput, requestUrl) => ({ ...requestInput, dispatcher: getDispatcher({ rejectUnauthorized, url: requestUrl }), }) ... response = await coreUtils.fetchWithBlacklist(url, input, { fetchFn: async (requestUrl, requestInput) => fetch(requestUrl, setDispatcher(requestInput, requestUrl)), // undici.fetch }) ``` The options object reaching `undici.fetch` is `{ ...nextRequest, agent: <pinned Node Agent>, dispatcher: <getDispatcher result> }`. **undici uses `dispatcher` and ignores `agent`.** **The dispatcher does no IP pinning** — `packages/backend-core/src/utils/fetch.ts`: - `getDispatcher` → `createDispatcher` → (no proxy env) → `createDirectAgent` = `new Agent({ connect: { rejectUnauthorized } })` (lines ~109–114, ~161–172, ~183). This is a plain undici `Agent` with **no `connect.lookup` / no pin**, so undici resolves the hostname's DNS itself at connect time. **Net effect (TOCTOU / DNS rebinding):** `fetchWithBlacklist` validates the hostname → safe public IP and builds a pinned Node agent; the REST path then connects via undici, which re-resolves the same hostname independently. With a rebinding domain (TTL 0: public IP during validation, `127.0.0.1` / `169.254.169.254` / internal IP at connect), the request lands on an internal service — exactly the gap CVE-2026-54353's pin was meant to close. **Scope of impact / why it's REST-specific:** `rest.ts` is the only caller that overrides `fetchFn` with undici. All other outbound sinks (automation `outgoingWebhook`/`n8n`/`make`/`zapier`/`discord`/`slack`, and AI-extract's `processUrlFile`) use the default node-fetch-based `fetchWithBlacklist`, which **does** honor the pinned agent and is **not** affected. REST datasource queries are the most common outbound path, and the response body is returned to the caller (full-response SSRF, not blind). ### PoC The PoC drives the **real, unmodified** guard code (`outboundFetch.ts` + `fetch.ts`, copied verbatim — sha256 verified) and reproduces the exact `rest.ts` call pattern. Only the `../blacklist` module is stubbed to model the rebinding **input** (validation observes a safe public IP). Requires Node 18+. ```bash # prerequisite: a Budibase checkout; set BB to its path export BB=/path/to/budibase mkdir ssrf-poc && cd ssrf-poc SRC="$BB/packages/backend-core/src" # 1) Copy the REAL guard code, verbatim (sha proves no edits) mkdir -p real/utils real/blacklist cp "$SRC/utils/outboundFetch.ts" real/utils/ cp "$SRC/utils/fetch.ts" real/utils/ # 2) Scenario stub = the rebinding INPUT: validation sees a safe, non-blacklisted public IP cat > real/blacklist/index.ts <<
Impact
An authenticated user with permission to configure and run REST datasources can exploit this vulnerability to perform SSRF attacks that bypass DNS rebinding protections. This enables unauthorized access to internal-only services, including cloud metadata services (risking credential theft), internal databases (CouchDB, Redis, MinIO), and other internal endpoints. The attacker can read sensitive data and potentially modify or destroy internal data due to the ability to use arbitrary HTTP methods and request bodies. This compromises confidentiality, integrity, and availability of internal resources.
Weaknesses
References
- github.com/Budibase/budibase/security/advisories/GHSA-v42f-v8xc-j435 (opens in a new tab)
- github.com/Budibase/budibase/pull/19178 (opens in a new tab)
- github.com/Budibase/budibase/commit/1fecb3fc3497e8db7b60b42cc514ce304ffe3a41 (opens in a new tab)
- github.com/Budibase/budibase/commit/5758bdb242802ca20c4ed0dc579e4330ee898ef3 (opens in a new tab)
- github.com/Budibase/budibase/commit/586802b5706367520d14245e18a7d0cabab0be11 (opens in a new tab)
- github.com/Budibase/budibase (opens in a new tab)
- github.com/Budibase/budibase/releases/tag/3.39.30 (opens in a new tab)