CVE-2026-31818: 
JavaScript vulnerability analysis and mitigation

CVE-2026-31818 is a critical Server-Side Request Forgery (SSRF) vulnerability in Budibase's REST datasource connector, classified under CWE-918 and CWE-1188. It affects all self-hosted Budibase instances running versions prior to 3.33.4 — believed to be the vast majority of deployments — due to the BLACKLIST_IPS environment variable not being set in any official deployment configuration. The vulnerability was published on April 3, 2026, with the fix merged on March 13, 2026 and released in version 3.33.4. It carries a CVSS v3.1 base score of 9.6 (Critical) (Github Advisory).

The root cause is an insecure default initialization (CWE-1188) in packages/backend-core/src/blacklist/blacklist.ts. When BLACKLIST_IPS is unset, blackListArray is initialized as an empty array, causing isBlacklisted() to unconditionally return false — bypassing all SSRF protection. The REST integration in packages/server/src/integrations/rest.ts calls blacklist.isBlacklisted(url) before executing fetch(url, input), but since the check always returns false, any URL — including internal Docker network hostnames like http://couchdb-service:5984 — is fetched without restriction. Exploitation requires only a low-privilege Builder role (app-level) to create a REST datasource, or QUERY WRITE permission to execute pre-existing queries. The official Docker Compose hosting/.env template omits BLACKLIST_IPS entirely, with no hardcoded fallback for RFC1918, localhost, or cloud metadata ranges (Github Advisory, Fix PR).

A low-privileged authenticated attacker can force the Budibase server to make arbitrary HTTP requests to internal services, crossing the security boundary between the application layer and infrastructure layer. This enables full exfiltration of CouchDB contents — including bcrypt password hashes, admin email addresses, JWT secrets, API encryption keys, and all application data — as well as read/write access to MinIO object storage and service discovery of Redis and other Docker-networked services. Through CouchDB's HTTP API, an attacker can also modify user records to escalate privileges, create new admin accounts, or delete databases, and on cloud-hosted instances can retrieve IAM credentials via the cloud metadata endpoint (http://169.254.169.254/latest/meta-data/) to pivot into cloud infrastructure (Github Advisory).

A detailed proof-of-concept with step-by-step HTTP requests, specific endpoints, payloads, and actual response data demonstrating full CouchDB credential exfiltration is publicly available in the official security advisory (Github Advisory). The EPSS score is approximately 0.016% (4th percentile), and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. The vulnerability can also be chained with CVE-2026-25040 (a separate Budibase privilege escalation) to achieve full instance takeover starting from a Creator-level account.

1. Authenticate: Log in to a vulnerable Budibase instance with a Builder-level account (or any account with QUERY WRITE permission on an existing query). Obtain a valid session cookie via POST /api/global/auth or the login UI.
2. Create a malicious REST datasource: Send a POST /api/datasources request with the internal CouchDB URL as the datasource target:

POST /api/datasources HTTP/1.1
Host: <budibase-host>:10000
Content-Type: application/json
Cookie: budibase:auth=<session>
x-budibase-app-id: <app-id>

{"datasource": {"name": "Internal CouchDB", "source": "REST", "type": "datasource", "config": {"url": "http://couchdb-service:5984", "defaultHeaders": {}}}}

The server returns HTTP 201 with the created datasource ID — no validation error occurs. 3. Confirm internal connectivity: Create and execute a query against the datasource targeting GET / to confirm CouchDB is reachable and retrieve its version information. 4. Enumerate databases: Execute a query to GET /_all_dbs with CouchDB admin credentials (default: budibase:budibase, Base64-encoded as Authorization: Basic YnVkaWJhc2U6YnVkaWJhc2U=) to list all internal databases. 5. Exfiltrate credentials and secrets: Query GET /global-db/_all_docs?include_docs=true&limit=20 to retrieve all user records including admin email addresses, bcrypt password hashes, JWT secrets, and API encryption keys. 6. Pivot to other services: Target http://minio-service:9000 for object storage access, use differential error responses to map other internal services (e.g., Redis on port 6379), or target http://169.254.169.254/latest/meta-data/ on cloud-hosted instances to retrieve IAM credentials. 7. Escalate or persist: Use CouchDB's HTTP API (PUT/POST) to modify user records, create new admin accounts, or alter application data for persistent access (Github Advisory).

• Network: Outbound HTTP requests from the Budibase server process to internal Docker network hostnames (e.g., couchdb-service:5984, minio-service:9000, redis-service:6379) or cloud metadata IP 169.254.169.254; unusual HTTP traffic on internal ports not normally accessed by the application tier.
• Logs: Budibase API access logs showing POST /api/datasources requests with internal hostnames or RFC1918 IP addresses in the request body; POST /api/v2/queries/<id> executions shortly after datasource creation by low-privilege accounts; CouchDB access logs showing requests authenticated with the default budibase:budibase credentials originating from the Budibase application container rather than expected internal processes.
• Application: New REST datasources configured with internal network URLs (e.g., http://couchdb-service:5984, http://10.x.x.x/, http://169.254.169.254/) visible in the Budibase datasource list; unexpected new admin user accounts or modified user records in CouchDB's global-db database.
• File System: Unexpected changes to CouchDB documents in global-db (e.g., new _id entries with admin.global: true); MinIO bucket contents accessed or modified outside normal application workflows.

Upgrade Budibase to version 3.33.4 or later, which adds a hardcoded default CIDR blocklist covering RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), localhost (127.0.0.0/8), link-local/cloud metadata (169.254.0.0/16), and IPv6 equivalents, enforced even when BLACKLIST_IPS is unset (Budibase Release, Fix PR). As a temporary workaround before upgrading, explicitly set the BLACKLIST_IPS environment variable in your deployment configuration to include all private IP ranges and the cloud metadata endpoint. Additionally, restrict the Builder role to trusted users only, and consider network-level controls (e.g., firewall rules or Docker network policies) to prevent the Budibase application container from reaching internal infrastructure services directly.

The vulnerability received coverage from The Hacker Wire, which published an article specifically on the SSRF bypass (The Hacker Wire), and SecurityOnline.info covered it as part of a broader Budibase critical vulnerability report (SecurityOnline). The vulnerability was also noted on Bluesky and Mastodon by security community accounts. The advisory credits researcher Moonster8282 for the discovery and report (Github Advisory).