Budibase's server-side HTTP request functionality has a DNS rebinding SSRF vulnerability affecting two paths. The OpenAPI query import path validates hostnames against a blacklist but then performs a separate fetch without pinning the DNS resolution, allowing an attacker-controlled hostname to resolve to a public IP during validation and to 127.0.0.1 during the fetch. The REST datasource/query execution path uses a fetch helper that pins DNS resolution via a Node http.Agent, but when using the undici HTTP client with a custom dispatcher, the hostname is re-resolved at connection time, bypassing the DNS pinning. This allows authenticated users with builder/query privileges to reach loopback or private network HTTP services that should be blocked. The vulnerability affects Budibase versions up to and including 3.38.1 and is present in the latest master and release 3.39.14. The root cause is a validate-then-fetch gap and incomplete enforcement of DNS pinning in the undici fetch path. The vendor recommends routing OpenAPI imports through the pinned fetch helper and enhancing fetchWithBlacklist() to enforce pinned connections for all transports, including undici.

An authenticated attacker with builder or query privileges can exploit this vulnerability to perform SSRF attacks targeting loopback (127.0.0.1) or private network HTTP services from the Budibase server process. This bypasses existing outbound fetch protections designed to block such internal requests. The impact includes potential unauthorized access to internal services, which may lead to information disclosure or further internal network compromise. The CVSS 3.1 vector indicates network attack vector, low attack complexity, privileges required, no user interaction, scope change, high confidentiality impact, low integrity impact, and no availability impact.

No official patch or fix is currently available. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended mitigation is to route OpenAPI query imports through the pinned outbound fetch helper to eliminate the validate-then-fetch gap. For REST datasource/query execution, fetchWithBlacklist() should be enhanced to pin DNS resolution for all supported transports, including providing a dispatcher for undici that enforces pinned IP addresses or rejecting custom fetch functions that do not enforce this. Until fixes are released, restrict builder-level user privileges to trusted users only and monitor for suspicious internal HTTP requests if possible.