CVE-2026-48153: Server-Side Request Forgery in Budibase OAuth2 SDK

Budibase is an open-source low-code platform designed to build internal business applications. To facilitate integration with third-party service providers, Budibase implements an OAuth2 software development kit (SDK) within its backend subsystem. This integration pipeline allows administrators and low-privileged application builders to establish data sources that query external APIs on behalf of the platform.

The architecture exposes an attack surface where user-provided target endpoints are processed by server-side code. Server-Side Request Forgery (SSRF) represents a critical risk in such multi-tenant and low-code applications because the server executing these requests typically resides within a sensitive corporate intranet or a private virtual private cloud (VPC) environment. Without strict validation of outbound destinations, attackers can utilize the platform as a proxy to reach isolated resources.

CVE-2026-48153 identifies an implementation flaw where the outbound HTTP validation system is bypassed when retrieving access tokens. The vulnerability lies within the token exchange phase of the OAuth2 SDK, where the application issues a raw HTTP POST request to a user-controlled endpoint. This bypass facilitates arbitrary server-side requests targeting internal hosts, local loops, and cloud infrastructure metadata endpoints.

To protect against Server-Side Request Forgery, Budibase implements a centralized defense mechanism based on the blacklist.isBlacklisted(url) helper function. This routine resolves the target hostname and compares the resulting IP addresses against defined exclusion lists. These exclusion lists contain IPv4 and IPv6 loopback addresses, private IP ranges as defined in RFC 1918, and link-local addresses commonly associated with cloud provider metadata services.

The primary root cause of CVE-2026-48153 is the direct instantiation of the raw node-fetch library inside the OAuth2 SDK's token acquisition routine, bypassing the secure outbound fetch wrapper. The fetchToken function was designed to directly perform the HTTP POST request using unmodified library methods. This design decision completely removed the request execution sequence from the centralized validation pathway, meaning the target URL was never tested against blacklist.isBlacklisted.

Furthermore, the system relies on the Joi schema validation library to assert the structure of user-supplied parameters during data source definition. The validation schema assigned to the OAuth2 Token URL field was configured to check only that the input conformed to a basic URI format. It did not enforce scheme-specific constraints, host-level whitelists, or domain sanitization, allowing an attacker to input arbitrary IP addresses and local loopback strings.

Prior to the patch, the fetchToken function accepted user-defined configurations and executed requests directly. The code structure directly invoked raw node-fetch instead of using the custom client wrapper, as shown in the vulnerable code path:

// Vulnerable Implementation
import fetch from 'node-fetch';
 
async function fetchToken(config) {
  const { tokenUrl, clientId, clientSecret, code } = config;
  // Direct call using raw node-fetch bypasses blacklist checks
  const response = await fetch(tokenUrl, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code,
      client_id: clientId,
      client_secret: clientSecret
    })
  });
  return response.json();
}

The remediation introduced in version 3.39.0 forces all OAuth2 outbound requests to leverage the internal, hardened request wrapper. This secure wrapper validates target addresses prior to TCP handshake initiation, as demonstrated in the patched structure:

// Patched Implementation
import { safeFetch } from '../utils/http'; // Standardized wrapper enforcing blacklist
import { blacklist } from '../utils/security';
 
async function fetchToken(config) {
  const { tokenUrl, clientId, clientSecret, code } = config;
  
  // Enforce blacklist validation before execution
  if (blacklist.isBlacklisted(tokenUrl)) {
    throw new Error('Restricted destination address');
  }
 
  // Route request through safeFetch wrapper
  const response = await safeFetch(tokenUrl, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code,
      client_id: clientId,
      client_secret: clientSecret
    })
  });
  return response.json();
}

The logical execution flow before and after the application of this remediation is mapped below:

Exploitation of CVE-2026-48153 requires network access to the Budibase management panel and credentials corresponding to a builder role. This authorization level is typically granted to developers who are tasked with constructing internal application interfaces. An attacker with these privileges can navigate to the data sources configuration panel to establish a mock OAuth2 server connection.

The attacker configures the Token Endpoint parameter to point to a targeted resource in the internal subnet. In a cloud environment, such as Amazon Web Services (AWS), the targeted URL would point to the link-local metadata address http://169.254.169.254/latest/meta-data/iam/security-credentials/. The backend server accepts this configuration without raising schema errors because the input satisfies the loose URI validation rules defined in the Joi schema.

Once the configuration is active, the attacker triggers the token retrieval process by initiating an authentication flow. The Budibase container establishes a TCP connection to the cloud metadata endpoint and sends an HTTP POST request containing URL-encoded client details. Although the request method is POST, many metadata endpoints and internal HTTP services process incoming payloads and return response data to the requesting client.

The backend server receives the HTTP response containing the requested metadata or sensitive credentials. Depending on how the integration handles the response payload, the output may be logged in error blocks, returned directly to the client interface, or reflected within the workspace context. This information leakage allows the attacker to compromise credentials or proceed with internal network reconnaissance.

The ability to force the Budibase backend to communicate with arbitrary internal addresses shifts the security boundary from the application container to the host network. Because the platform is often containerized and deployed within internal virtualization environments, this SSRF provides an avenue for lateral movement. The Common Vulnerability Scoring System (CVSS) scores this issue as 8.5, noting a Scope change (S:C), reflecting this transition.

Attackers can target unauthenticated microservices that are listening on the local loopback interface or within the virtual network. For example, a default Budibase deployment may run a CouchDB instance or a Redis server on localhost. These services are often configured without authentication under the assumption that they are unreachable from the public internet. An attacker can exploit the SSRF to issue administrative commands or retrieve data from these local databases.

If the Budibase container is executed with permissive IAM roles in a public cloud, the exploitation of the Instance Metadata Service can lead to full node compromise. Access to AWS temporary security credentials allows the attacker to impersonate the container host. This credentials theft can lead to unauthorized access to cloud resources, databases, and code repositories, elevating the attack from a local application compromise to a broad infrastructure breach.

The primary remediation path is upgrading the Budibase application to version 3.39.0 or higher. This update replaces the insecure node-fetch integration within the OAuth2 SDK with the native, secured transport client that strictly respects blacklist boundaries. Additionally, the update hardens the underlying Joi schemas used to validate incoming configuration variables.

If upgrading immediately is not technically feasible, administrators should enforce strict egress filtering at the network virtualization layer. Implementing network security groups or iptables rules can prevent the Budibase container from initiating outbound connections to the host's link-local addresses and private IP ranges. The following iptables rule blocks egress traffic to the metadata IP address:

iptables -A OUTPUT -d 169.254.169.254 -j DROP

Furthermore, administrative teams must audit current data source definitions for anomalous configuration profiles. Database queries should be executed to identify any OAuth2 configurations referencing IP addresses rather than public domain names. Restricting user provisioning to ensure that only trusted personnel are assigned the builder privilege minimizes the risk of unauthorized configuration manipulation.