Summary
Budibase contains a server-side request forgery vulnerability in AI table generation because attachment URLs are fetched without the protections applied by the safer request helper. An authenticated builder user may cause the server to request internal resources, potentially exposing responses through a presigned object-storage URL.
Affected context
The vulnerability affects Budibase deployments using the AI table generation endpoint and its attachment-processing workflow. Risk arises when an authenticated builder can submit content that causes the server to process an attacker-controlled attachment URL, and when the server has network access to internal services or cloud metadata endpoints.
Exploit preconditions
- Attack surface: The Budibase AI table generation API and its attachment URL handling
- Required access: Authenticated builder-level access capable of invoking AI table generation
- Trigger point: Server-side processing of an attachment URL supplied through the AI table workflow
- Why exploitation is possible: The affected function uses a direct HTTP client without the internal URL blacklist or equivalent egress restrictions
- Additional condition: The server environment must be able to reach a sensitive internal or metadata service
Why this happens
The underlying issue is inconsistent enforcement of outbound request controls. The attachment upload path uses a raw HTTP request function instead of the application's restricted request helper, allowing attacker-influenced URLs to be fetched from the server's network position.
This maps to CWE-918: Server-Side Request Forgery, where externally influenced input controls a server-side request without sufficient destination validation or network policy enforcement.
Potential impact
- The server may access internal services that are not publicly reachable
- Cloud instance metadata responses may be disclosed
- Temporary credentials or other sensitive tokens could be exposed
- Internal service information may be returned through generated object-storage links
- Attackers could use the server as a foothold for reconnaissance or limited lateral movement
General mitigation guidance
Mitigation generally focuses on making outbound requests secure by default and reducing trust in user-controlled URLs.
Common defensive patterns include:
- Route all server-side fetches through a centrally enforced, allowlisted request helper
- Validate URL schemes, hosts, ports, redirects, and resolved IP addresses
- Block loopback, link-local, private, and other restricted network ranges
- Apply egress network policies that prevent application workloads from reaching sensitive metadata and management endpoints
- Avoid returning fetched response content through user-accessible storage or download links unless strictly required
- Run application services with least-privilege cloud identities and minimal network permissions
- Treat authenticated builder input as untrusted and enforce authorization at each request boundary
How teams detect issues like this
Organizations can identify similar SSRF risks through:
- Static analysis searches for direct HTTP clients receiving user-controlled URLs
- Code review checks for bypasses of centralized URL validation or blacklist helpers
- Tests covering private, loopback, link-local, redirect, DNS-rebinding, and alternate IP representations
- Runtime monitoring of outbound requests to internal ranges and cloud metadata services
- Egress firewall and service-mesh policies that alert on or deny restricted destinations
- Automated security review tools that flag server-side request construction without destination controls
