Description

Budibase before 3.40.0 contains server-side request forgery vulnerabilities in OpenAPI query import and REST query execution that allow authenticated builder-level users to bypass DNS pinning protections through DNS rebinding attacks. Attackers can configure hostnames that resolve to public addresses during validation but resolve to loopback or private addresses during actual connection, allowing access to blocked internal HTTP services.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-13T22:17:24.753Z",
  "pubdate": "2026-08-13T22:17:24.753Z",
  "executiveSummary": "Budibase before 3.40.0 contains server-side request forgery (SSRF) vulnerabilities in OpenAPI query import and REST query execution components. The vulnerability allows authenticated builder-level users to bypass existing DNS pinning protections via DNS rebinding attacks. Attackers can leverage this flaw to access blocked internal HTTP services, internal networks, or loopback interfaces that should otherwise be restricted.\nThe risk implication involves unauthorized exposure and interaction with internal infrastructure that resides behind network perimeters or cloud metadata services. Exploitation requires authenticated access with builder-level privileges within the Budibase platform. Attackers must control an authoritative DNS server capable of manipulating Time-To-Live (TTL) responses to facilitate the DNS rebinding mechanism, ensuring initial resolution passes validation checks while subsequent connection requests resolve to targeted internal addresses.",
  "technicalDetails": "The root cause of the vulnerability stems from a race condition or time-of-check to time-of-use (TOCTOU) discrepancy in how hostnames are validated against DNS pinning defenses during OpenAPI query import and REST query execution. When an authenticated builder-level user configures a target hostname, the application performs an initial DNS resolution to verify that the target address does not point to forbidden ranges, such as loopback or private IP spaces.\nDuring the actual HTTP connection phase, a second DNS resolution occurs. If the attacker configures their authoritative DNS server to return a public IP address during the initial validation check (with a short TTL) and a private or loopback IP address (such as 127.0.0.1 or internal RFC 1918 addresses) during the subsequent connection attempt, the DNS pinning protection is successfully bypassed.\nThe affected components are the OpenAPI query import and REST query execution modules within Budibase versions prior to 3.40.0. Attackers exploit this behavior by supplying specially crafted hostnames that exploit the TTL window. The payload behavior forces the underlying HTTP client to initiate connections to internal endpoints that were intended to be restricted by the application's security controls.\nAuthentication and privilege requirements mandate that the attacker possesses builder-level access to the Budibase instance. Network exposure involves the server-side infrastructure executing outbound HTTP requests on behalf of the user. Post-exploitation impact includes unauthorized reading of internal service responses, potential interaction with internal APIs, and information disclosure regarding internal network topologies."
}