CVE-2026-48146: Budibase OAuth2 SSRF Vulnerability

CVE-2026-48146 Overview

CVE-2026-48146 is a Server-Side Request Forgery (SSRF) vulnerability in Budibase, an open-source low-code platform. The flaw resides in the OAuth2 token fetch function located at packages/server/src/sdk/workspace/oauth2/utils.ts. This function calls fetch(config.url) directly without any blacklist enforcement. A safe wrapper named fetchWithBlacklist() exists elsewhere in the codebase but was not applied to the OAuth2 token endpoint. Users holding the BUILDER role can direct the OAuth2 token URL to internal network services, including CouchDB and cloud metadata endpoints. The vulnerability is fixed in Budibase 3.39.0.

Critical Impact
An authenticated BUILDER user can reach internal services and exfiltrate sensitive data such as cloud instance metadata and database contents.

Affected Products

Budibase versions prior to 3.39.0
packages/server OAuth2 token fetch component
Self-hosted and cloud Budibase deployments running vulnerable releases

Discovery Timeline

2026-05-27 - CVE-2026-48146 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-48146

Vulnerability Analysis

The vulnerability is classified as Server-Side Request Forgery [CWE-918]. Budibase ships a defensive utility, fetchWithBlacklist(), that filters outbound HTTP requests to block access to internal IP ranges and metadata endpoints. This wrapper is used consistently across automation steps, plugin downloads, and object store interactions. The OAuth2 token fetch path bypassed this control by invoking raw fetch(config.url) against a user-controlled URL. The OAuth2 configuration is editable by any account with the BUILDER role, which is a standard application development role rather than a server administrator role.

Root Cause

The root cause is missing input validation on the OAuth2 token endpoint URL. The token fetch code path did not call fetchWithBlacklist() and therefore did not enforce the existing IP and hostname denylist. The application trusted the configured token URL without restricting destinations to public, non-internal hosts.

Attack Vector

An authenticated attacker with the BUILDER role creates or edits an OAuth2 configuration and sets the token URL to an internal target. Examples include http://169.254.169.254/latest/meta-data/ to retrieve cloud instance metadata or http://localhost:5984/ to query the local CouchDB instance. When Budibase performs the OAuth2 token exchange, the server issues the request from its own network context. Response data is returned through the OAuth2 flow, allowing the attacker to exfiltrate credentials, tokens, and database contents from services that trust the Budibase host. See the GitHub Security Advisory for additional technical detail.

Detection Methods for CVE-2026-48146

Indicators of Compromise

Outbound HTTP requests from the Budibase server to RFC1918 ranges, 127.0.0.1, or 169.254.169.254
OAuth2 configurations referencing non-public hostnames or loopback addresses in the token URL field
Unexpected reads against the local CouchDB port 5984 originating from the application process
Audit log entries showing OAuth2 configuration edits followed by token exchange attempts

Detection Strategies

Inspect stored OAuth2 configurations and flag any token URL whose host resolves to private, loopback, or link-local addresses
Monitor application logs for OAuth2 token requests that return non-OAuth response payloads such as JSON metadata documents
Correlate BUILDER role activity with outbound network connections from the Budibase host

Monitoring Recommendations

Enable egress logging on the Budibase host and alert on connections to cloud metadata IPs
Review user role assignments and track creation of new BUILDER accounts
Retain OAuth2 configuration change history for forensic review

How to Mitigate CVE-2026-48146

Immediate Actions Required

Upgrade Budibase to version 3.39.0 or later
Audit existing OAuth2 configurations and remove any entries pointing to internal hosts
Restrict BUILDER role assignment to trusted personnel only
Rotate any cloud instance credentials and database secrets that may have been exposed through the Budibase host

Patch Information

The issue is fixed in Budibase 3.39.0. The patch routes the OAuth2 token fetch through the existing fetchWithBlacklist() wrapper, applying the same destination filtering used by other outbound HTTP calls. Refer to the GitHub Security Advisory GHSA-g6qx-g4pr-92v7 for release details.

Workarounds

Place the Budibase server behind an egress firewall that blocks access to cloud metadata endpoints and internal management ranges
Use IMDSv2 with hop-limit enforcement on AWS to prevent SSRF retrieval of instance credentials
Run Budibase in a network segment isolated from sensitive internal services until the upgrade is applied

bash

# Configuration example: block metadata and loopback egress from the Budibase host
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP