CVE-2026-31818: Budibase SSRF Vulnerability

CVE-2026-31818 Overview

CVE-2026-31818 is a critical Server-Side Request Forgery (SSRF) vulnerability in Budibase, an open-source low-code platform. The vulnerability exists in Budibase's REST datasource connector, where the platform's SSRF protection mechanism is rendered completely ineffective due to a configuration issue. The BLACKLIST_IPS environment variable is not set by default in any of the official deployment configurations, causing the blacklist function to unconditionally return false and allow all requests through without restriction.

Critical Impact

Attackers with low-level platform access can bypass SSRF protections to access internal network resources, cloud metadata services, and sensitive internal APIs, potentially leading to full infrastructure compromise.

Affected Products

• Budibase versions prior to 3.33.4
• All official Budibase deployment configurations (Docker, Kubernetes, etc.)
• Self-hosted Budibase instances without manual BLACKLIST_IPS configuration

Discovery Timeline

• 2026-04-03 - CVE-2026-31818 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-31818

Vulnerability Analysis

This SSRF vulnerability stems from a fundamental design flaw in how Budibase implements its IP blacklisting mechanism. The REST datasource connector is intended to prevent requests to internal network addresses, but the protection is ineffective by default. When users configure REST API datasources within their Budibase applications, the platform should validate and block requests targeting internal IP ranges such as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. However, because the BLACKLIST_IPS environment variable is never initialized in official deployment templates, the blacklist validation logic short-circuits and permits all outbound requests.

An authenticated attacker with low privileges can exploit this vulnerability to make the Budibase server send HTTP requests to arbitrary internal resources. This could enable access to cloud instance metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), internal microservices, databases, or administrative interfaces that should not be externally accessible. The scope change indicated in the vulnerability assessment means successful exploitation can impact resources beyond the vulnerable component itself.

Root Cause

The root cause is an insecure default configuration in the SSRF protection mechanism. The blacklist.ts module checks the BLACKLIST_IPS environment variable to determine which IP ranges to block. When this variable is empty or undefined—which is the default state in all official deployment configurations—the blacklist function unconditionally returns false, effectively disabling all SSRF protections. This represents a classic case of security controls that exist in code but are not enabled by default, creating a false sense of security.

Attack Vector

The attack is network-based and requires only low-level authenticated access to the Budibase platform. An attacker can create or modify a REST datasource to target internal network addresses. Since the blacklist check fails open, the Budibase server will make the request on behalf of the attacker. This can be weaponized to:

1. Access cloud provider metadata services to steal IAM credentials
2. Scan internal network infrastructure
3. Interact with internal services that trust requests from the Budibase server
4. Exfiltrate sensitive data from internal resources

The following patch shows how the vulnerability was addressed by implementing a default blacklist of private IP ranges:

 import env from "../environment"
 import { promisify } from "util"
 
-let blackListArray: string[] | undefined
+const DEFAULT_BLACKLIST = [
+  "127.0.0.0/8",
+  "10.0.0.0/8",
+  "172.16.0.0/12",
+  "192.168.0.0/16",
+  "169.254.0.0/16",
+  "0.0.0.0/8",
+  "::1/128",
+  "fc00::/7",
+  "fe80::/10",
+] as const
+
+let blackList: net.BlockList | undefined
 const performLookup = promisify(dns.lookup)
 
-async function lookup(address: string): Promise<string[]> {
-  if (!net.isIP(address)) {
-    // need this for URL parsing simply
-    if (!address.startsWith("http")) {
-      address = `https://${address}`
-    }
-    address = new URL(address).hostname
+function getIpVersion(address: string): "ipv4" | "ipv6" {
+  return net.isIP(address) === 6 ? "ipv6" : "ipv4"
+}
+

Source: GitHub Commit

Detection Methods for CVE-2026-31818

Indicators of Compromise

• Outbound HTTP/HTTPS requests from Budibase servers to internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Requests to cloud metadata endpoints such as 169.254.169.254 originating from Budibase application containers
• Unusual REST datasource configurations targeting internal hostnames or IP addresses
• Unexpected access logs showing Budibase server IPs accessing internal services

Detection Strategies

• Monitor egress traffic from Budibase deployments for connections to RFC 1918 private address spaces
• Implement network segmentation alerts when Budibase containers attempt to reach sensitive internal services
• Review Budibase audit logs for REST datasource creation or modification events targeting internal URLs
• Deploy Web Application Firewall (WAF) rules to detect SSRF patterns in outbound request parameters

Monitoring Recommendations

• Enable verbose logging for the Budibase REST datasource connector to capture all outbound request URLs
• Set up alerts for DNS resolution requests from Budibase servers for internal domain names
• Monitor for access attempts to cloud metadata services (AWS, GCP, Azure) from application containers
• Implement network flow analysis to baseline and alert on anomalous outbound connection patterns from Budibase infrastructure

How to Mitigate CVE-2026-31818

Immediate Actions Required

• Upgrade Budibase to version 3.33.4 or later immediately
• If immediate upgrade is not possible, manually set the BLACKLIST_IPS environment variable with private IP ranges
• Audit existing REST datasources for any suspicious internal URL targets
• Review access logs for evidence of SSRF exploitation attempts

Patch Information

Budibase has released version 3.33.4 which addresses this vulnerability by implementing a default blacklist of private IP ranges. The fix ensures that SSRF protections are enabled out-of-the-box without requiring manual environment variable configuration. For detailed information, refer to the GitHub Security Advisory GHSA-7r9j-r86q-7g45 and Pull Request #18236.

Workarounds

• Manually configure the BLACKLIST_IPS environment variable with appropriate private IP CIDR ranges if upgrading is not immediately feasible
• Implement network-level egress filtering to block Budibase servers from reaching internal IP ranges
• Deploy a reverse proxy or firewall in front of Budibase to inspect and filter outbound requests
• Restrict Budibase server network access using container network policies or security groups

# Configuration example - Set BLACKLIST_IPS environment variable for Docker deployments
docker run -d \
  -e BLACKLIST_IPS="127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16,0.0.0.0/8" \
  budibase/budibase:3.33.4

# For Kubernetes deployments, add to your deployment spec:
# env:
#   - name: BLACKLIST_IPS
#     value: "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16,0.0.0.0/8"