CVE-2026-73410: Budibase SSRF Vulnerability

CVE-2026-73410 Overview

Budibase is an open-source low-code platform affected by a server-side request forgery (SSRF) vulnerability rooted in a time-of-check to time-of-use (TOCTOU) race condition [CWE-367]. Versions prior to 3.40.0 validate an outbound REST target address once, then re-resolve the hostname when the request executes. A builder can abuse DNS rebinding to redirect a validated public destination to an internal address at request time. The flaw exists because packages/backend-core/src/utils/outboundFetch.ts pinned the address through a Node agent, but the REST integration used getDispatcher from packages/backend-core/src/utils/fetch.ts, causing undici to ignore that agent. Version 3.40.0 fixes the issue.

Critical Impact
An authenticated builder can pivot Budibase's REST integration to internal network resources with full response access and arbitrary HTTP methods, enabling access to cloud metadata, internal APIs, and adjacent services.

Affected Products

Budibase versions prior to 3.40.0
packages/backend-core/src/utils/fetch.ts (undici getDispatcher path)
packages/server/src/integrations/rest.ts REST integration

Discovery Timeline

2026-08-17 - CVE-2026-73410 published to NVD
2026-08-17 - Last updated in NVD database

Technical Details for CVE-2026-73410

Vulnerability Analysis

The vulnerability is a classic TOCTOU flaw manifesting as SSRF via DNS rebinding. Budibase's outbound fetch layer resolves a REST target hostname, validates the returned IP address against internal-range denylists, and passes the URL down to the HTTP client for execution. The validated IP is not carried forward to the actual connection, so the DNS lookup happens a second time inside undici.

Between the two lookups, an attacker-controlled authoritative DNS server returns a public IP for validation and a private IP (for example, 127.0.0.1, 169.254.169.254, or an RFC1918 host) for the connection. The REST integration then executes any HTTP method against the internal target and returns the full response body to the requester.

Root Cause

The makePinnedAgent helper in packages/backend-core/src/utils/outboundFetch.ts used a custom lookup function on a Node http.Agent or https.Agent. However, the REST integration in packages/server/src/integrations/rest.ts fetched requests through undici via getDispatcher in packages/backend-core/src/utils/fetch.ts. Undici does not honor Node agent lookup functions, so it performed its own hostname resolution and bypassed the pinned IP entirely.

Attack Vector

An authenticated builder configures a REST datasource pointing at an attacker-controlled domain. The domain's DNS is set up to answer with a low TTL, alternating between a public IP that passes validation and an internal IP such as a cloud metadata endpoint. When Budibase executes the query, undici re-resolves the hostname and connects to the internal address. The response is returned to the builder with no filtering.

typescript

   return addresses[0]
 }
 
-function makePinnedAgent(url: string, ip: string): http.Agent | https.Agent {
-  const protocol = new URL(url).protocol
-  const lookup: LookupFunction = (_hostname, _options, callback) => {
-    const family = ip.includes(":") ? 6 : 4
+// Always pin to the first resolved IP address to avoid DNS rebinding attacks.
+export function createPinnedLookup(ip: string): LookupFunction {
+  const family = ip.includes(":") ? 6 : 4
+  return (_hostname, _options, callback) => {
     if (typeof _options === "object" && _options?.all) {
       callback(null, [{ address: ip, family }])
       return
     }
     callback(null, ip, family)
   }
+}
+
+function makePinnedAgent(url: string, ip: string): http.Agent | https.Agent {
+  const protocol = new URL(url).protocol
+  const lookup = createPinnedLookup(ip)
   return protocol === "https:"
     ? new https.Agent({ lookup })
     : new http.Agent({ lookup })

Source: GitHub Commit 5758bdb

Detection Methods for CVE-2026-73410

Indicators of Compromise

Outbound DNS queries from Budibase servers with unusually low TTL responses resolving to alternating public and internal IPs.
Budibase REST integration requests targeting cloud metadata endpoints such as 169.254.169.254 or internal RFC1918 ranges.
Anomalous 200-response REST datasource results pulling data from hosts the Budibase workload should never contact.

Detection Strategies

Inspect Budibase audit logs for newly created or modified REST datasources pointing at unfamiliar or dynamic-DNS domains.
Correlate DNS resolver telemetry with egress connections from the Budibase host to flag same-hostname resolutions that map to both public and internal addresses within a short window.
Alert on any egress from the Budibase server to link-local, loopback, or metadata service addresses.

Monitoring Recommendations

Enable and centralize DNS query logging for the Budibase workload, retaining records long enough to reconstruct rebinding sequences.
Monitor process-level network activity for the Node.js process running Budibase, focusing on connections initiated by the REST integration.
Track privileged builder role assignments, since exploitation requires an authenticated builder account.

How to Mitigate CVE-2026-73410

Immediate Actions Required

Upgrade Budibase to version 3.40.0 or later on all self-hosted deployments.
Restrict builder role membership to trusted operators until the patch is applied.
Place the Budibase server behind an egress firewall that blocks traffic to internal ranges and cloud metadata endpoints.

Patch Information

The fix is delivered in Budibase 3.40.0. Commit 5758bdb introduces createPinnedLookup and threads the validated IP through to the undici dispatcher, ensuring the address used for validation is the same address used for the connection. Details are documented in GitHub Security Advisory GHSA-v42f-v8xc-j435 and the GitHub Commit Details.

Workarounds

Block outbound access from the Budibase host to 169.254.0.0/16, 127.0.0.0/8, and internal RFC1918 ranges at the network layer.
Force outbound HTTP traffic through a forwarding proxy that performs its own IP validation and rejects private destinations.
Disable or tightly restrict the REST datasource integration for non-administrative users until the upgrade is complete.

bash

# Example egress restriction for a Budibase container using iptables
iptables -A OUTPUT -m owner --uid-owner budibase -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner budibase -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner budibase -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner budibase -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner budibase -d 127.0.0.0/8 -j REJECT