Budibase CVE-2026-31818: Brief Summary of a Critical SSRF via Insecure Default Configuration

Introduction

A default configuration oversight in Budibase's REST datasource connector left every standard deployment wide open to server-side request forgery. The flaw carries a CVSS score of 9.6. The IP blacklist meant to prevent outbound requests to internal services never activated, because the environment variable that controls it was not set in any official deployment template.

Budibase is an open-source, low-code platform designed to help engineers build forms, portals, and approval apps. Founded in Belfast in 2019 and backed by $9.25 million in seed funding, the platform lets users connect to external data sources including Postgres, MySQL, and REST APIs. Because it sits in the low-code space, it is frequently deployed in enterprise environments where it has direct network access to internal services and databases.

Technical Information

CVE-2026-31818 maps to two CWE classifications: CWE-918 (Server-Side Request Forgery) and CWE-1188 (Insecure Default Initialization of Resource). Together, these two weaknesses make the vulnerability both critical and trivially exploitable.

The Blacklist Mechanism and Its Failure

Budibase's REST data source feature allows users to configure connections to external APIs through the platform's Workspace Settings under Connections to APIs. To mitigate SSRF risk, the platform implements an IP blacklist controlled by the BLACKLIST_IPS environment variable. According to Budibase's hosting settings documentation, this variable is intended to specify IP addresses, hostnames, or CIDR subnets that the outbound REST query integration is prevented from connecting to.

The problem is that BLACKLIST_IPS is not set by default in any of the official deployment configurations. When the variable is empty or undefined, the blacklist function unconditionally returns false, so every outbound request from the REST connector passes through without any IP validation. The protection exists in the code but does nothing in any default installation.

Attack Flow

Exploitation requires authenticated access to the Budibase platform with permissions to configure REST datasources. The attack proceeds as follows:

1. An authenticated user navigates to Workspace Settings and configures a new REST datasource connection.
2. The user points the REST endpoint at an internal target, such as http://169.254.169.254/latest/meta-data/ (AWS metadata service), http://127.0.0.1:6379/ (a local Redis instance), or any RFC1918 address hosting internal services.
3. When the request is executed, Budibase's blacklist function evaluates the target IP against the loaded blacklist entries.
4. Because BLACKLIST_IPS was never set, the blacklist is empty, and the function returns false (indicating the IP is not blacklisted).
5. The request proceeds to the internal target, and the response is returned to the attacker through the Budibase interface.

No special tooling is required. The platform's own UI provides the complete attack surface.

Post-Patch Behavior

Version 3.33.4 introduces a default blacklist that activates when BLACKLIST_IPS is not explicitly configured. The default blocked ranges are:

For self-hosted environments that legitimately need to reach internal APIs, the default blacklist is disabled only when SELF_HOSTED is set to 1 and BLACKLIST_IPS is explicitly defined. Setting BLACKLIST_IPS to an empty value disables the blacklist completely and reintroduces the original vulnerability. Requests to internal services that resolve to blocked ranges will fail with a generic "Cannot connect to URL" error unless the override is properly configured.

Affected Systems and Versions

All versions of Budibase prior to 3.33.4 are affected. This includes every official deployment configuration (Docker, Kubernetes, and other supported methods) where the administrator did not set the BLACKLIST_IPS environment variable manually. The vulnerability is present whether the deployment runs in the cloud or is self-hosted, because the default configuration ships without this variable in all cases.

The fix is available in version 3.33.4 and later. Budibase's security policy states that only the latest major version receives security patches, so no backports to older release lines should be expected.

Vendor Security History

Budibase maintains a responsible disclosure policy via huntr.dev and provides a dedicated security contact email. Its security policy, documented in the repository's SECURITY.md, explicitly states that only the latest major version will be patched for security vulnerabilities. That is a practical problem for organizations that cannot upgrade quickly.

Budibase drew a noticeable amount of security research in early 2026. Other vulnerabilities, including CVE-2026-33226 (another SSRF flaw) and CVE-2026-31816, have been documented in vulnerability databases and security bulletins during this period. The cluster of SSRF-related findings suggests that researchers have been focusing on the REST connector's security controls.

Updates to community-curated templates for the nuclei scanning engine indicate that automated scanning for Budibase vulnerabilities is under way. That makes it more likely that researchers and threat actors alike will find unpatched instances.

References

• GitHub Security Advisory GHSA-7r9j-r86q-7g45
• Fix Commit: Block internal REST targets by default
• Pull Request #18236: fix: block internal REST targets by default
• Budibase Release 3.33.4
• GitHub Issue #18299: "Cannot Connect to URL" for local REST datasource
• Budibase Hosting Settings Documentation
• Budibase REST API Documentation
• Budibase SECURITY.md
• Budibase GitHub Repository