Budibase CVE-2026-72855

Exploitation requires an authenticated Budibase account with builder-level or higher privileges - specifically access to the OpenAPI query import endpoint or the REST datasource/query execution feature. The attacker must control DNS infrastructure capable of returning different IP addresses across successive resolution queries for the same hostname (DNS rebinding), with TTL set low enough to allow the second resolution to occur before the connection attempt. The Budibase server's DNS resolver must not cache the first (public) response through the connection phase - standard low-TTL DNS rebinding configurations satisfy this. Exploitation is strictly limited to authenticated builder-level users; unauthenticated access and viewer-level accounts cannot reach either affected code path. No user interaction beyond the attacker's own authenticated actions is required.

The CVSS 4.0 score of 8.4 reflects network-accessible exploitation (AV:N), low attacker privilege (PR:L - builder-level account), high confidentiality impact on both the vulnerable system (VC:H) and subsequent systems (SC:H, reflecting internal services reachable via SSRF), with low integrity impact and no availability impact. The PR:L constraint is the primary limiting factor: only users with builder or query privileges can trigger either affected path. In multi-tenant or enterprise Budibase deployments where builder access is granted to partially-trusted users, this is a meaningful attack surface. No EPSS data was provided, and no CISA KEV listing is present, so broad active exploitation is not confirmed. However, the GHSA advisory contains complete reproduction steps and observed proof-of-concept output (loopback canary responses), meaning any motivated builder-level user can reliably exploit this. The SSRF impact is significant: internal cloud metadata endpoints (e.g., 169.254.169.254), internal admin APIs, and other loopback services on the Budibase host are reachable. This is a real priority for deployments where builder access is not strictly controlled to fully trusted personnel.

An attacker holding a Budibase builder-level account controls a DNS hostname configured to return 8.8.8.8 on the first resolution (passing the blacklist validation guard) and 127.0.0.1 on the second resolution (the actual HTTP connection). The attacker submits this hostname as an OpenAPI import URL or configures it as a REST datasource; Budibase validates against the public IP, then connects to the loopback address, returning responses from internal services such as local admin APIs or cloud instance metadata endpoints. The GHSA advisory documents this exact scenario with observed canary response output, confirming reliable reproducibility.