GHSA-QQF5-X7MJ-V43P: SQL Injection Vulnerabilities in Budibase Database Connectors

The Budibase low-code platform exposes database integration connectors to facilitate rapid application development. These connectors allow developers to hook into external datasources, introspect schemas, and design custom database interactions. Specifically, the integrations for PostgreSQL, Microsoft SQL Server, and MySQL reside in the backend repository under packages/server/src/integrations/. This component functions as an intermediary layer, translating user configuration and schema layouts into database queries.

The primary vulnerability lies in how the Budibase backend handles identifier metadata, specifically schema names and table names. Database identifiers cannot be parameterized using standard prepared statement placeholders, which typically only accept value literals. Consequently, developers must manually escape these identifier strings before incorporating them into SQL commands. The lack of robust validation and custom escaping allows malicious values to bypass intended constraints and alter SQL logic.

An attacker must possess administrative privileges to edit datasource configurations to trigger the PostgreSQL and Microsoft SQL Server vulnerabilities directly. However, the MySQL vulnerability presents a unique threat vector where a malicious database catalog can trigger the exploit. During standard metadata introspection, Budibase queries the list of tables from the database and passes unescaped table names into subsequent metadata queries. This permits blind SQL injection via compromised or untrusted database servers.

The scope of execution transitions from the low-code application environment to the target database context. Depending on database configuration, successful exploitation can result in full database compromise, data exfiltration, or lateral movement. In highly privileged database environments, this can lead to remote code execution on the underlying database host.

The fundamental flaw across all three database connectors is improper identifier neutralization (CWE-89). When building dynamic SQL statements, Budibase relies on ES6 template string interpolation and array mapping. This design assumes that schema and table names are safe identifiers, overlooking the potential for embedding structural string delimiters.

In the PostgreSQL connector, the application parses user-defined schemas from the configuration settings by splitting on commas and mapping each value inside double quotes. The double quote is the standard ANSI SQL delimiter for identifiers, but it must be escaped by doubling the character if it appears within the identifier itself. Because Budibase lacks this escaping step, entering a schema name with a trailing double quote terminates the identifier wrapper. Since node-postgres processes raw string queries using the simple query protocol, the engine accepts and processes multiple SQL statements separated by semicolons within a single payload.

In the Microsoft SQL Server integration, the SQL generation routine retrieves column definitions using a dynamic SELECT query targeting INFORMATION_SCHEMA.COLUMNS. The schemaName and tableName values are directly interpolated into single-quoted string literals. If a user provides a schema name containing a single quote, the literal is terminated prematurely. The MS SQL Server parser then processes any appended SQL statements, which may include stored procedures or administrative functions.

In the MySQL connector, the DESCRIBE statement is wrapped with backticks to handle identifiers that might be reserved words or contain special characters. However, if the table name contains a backtick, it is not escaped, which allows the table name to break out of the backticks. Because the MySQL connector explicitly configures multipleStatements: true during connection initialization, the database driver supports executing multiple sequential queries separated by semicolons, enabling arbitrary query chaining.

// VULNERABLE CODE: packages/server/src/integrations/postgres.ts
const search_path = this.config.schema
  .split(",")
  .map(item => `"${item.trim()}"`) // Vulnerable to double quote escape
await this.client.query(`SET search_path TO ${search_path.join(",")};`)
 
// PATCHED CODE: packages/server/src/integrations/postgres.ts
const search_path = this.config.schema
  .split(",")
  .map(item => `"${item.trim().replace(/"/g, '""')}"`) // Patched by doubling double-quotes
await this.client.query(`SET search_path TO ${search_path.join(",")};`)

The code snippet above demonstrates the vulnerability within the PostgreSQL connector. In the vulnerable implementation, the map function simply wraps each trimmed schema item in double quotes. When an attacker supplies a payload containing an unescaped double quote followed by administrative SQL commands, the double quote closes the identifier, and the semicolon acts as a statement separator. The patched implementation mitigates this by applying a global regular expression replacement (replace(/"/g, '""')) that doubles any double-quote character, satisfying the SQL escaping convention for identifiers.

// VULNERABLE CODE: packages/server/src/integrations/mysql.ts
// File: packages/server/src/integrations/mysql.ts (Line 172)
this.config = { ...config, multipleStatements: true, ... }
 
// File: packages/server/src/integrations/mysql.ts (Line 305)
{ sql: `DESCRIBE \`${tableName}\`;` } // Vulnerable to backtick escape
 
// PATCHED CODE: packages/server/src/integrations/mysql.ts
// File: packages/server/src/integrations/mysql.ts (Line 305)
const escapedTableName = tableName.replace(/`/g, '``'); // Patched by doubling backticks
{ sql: `DESCRIBE \`${escapedTableName}\`;` }

The MySQL integration vulnerability is particularly severe because the driver establishes a database connection with multipleStatements: true enabled. This setting allows the driver to send batch queries to the database server in a single network round-trip. The vulnerable DESCRIBE statement interpolates the tableName directly within backticks. In the patched code, Budibase intercepts the table name and applies a regex replacement (replace(//g, '``')`) to double any backticks inside the identifier, neutralizing the injection vector.

While these regex replacements resolve the direct attack vectors, they represent a string-manipulation approach to SQL safety. A more comprehensive defense-in-depth practice would entail utilizing parameterization libraries or native database escaping APIs, such as pg-format for PostgreSQL. However, the implemented fixes successfully prevent syntax-level escapes under typical operational configurations.

An attacker must meet specific requirements depending on the database engine. For PostgreSQL and MS SQL Server, the attacker must have administrative access to the Budibase management panel. This allows them to configure or modify existing connection options. For MySQL, the attacker can leverage a rogue database server to execute a blind injection against the Budibase application itself.

To exploit the PostgreSQL vector, the attacker edits the "Schema" configuration field. They input a string structured to terminate the double quotes and append a payload: public"; CREATE TABLE pwned AS SELECT usename, passwd FROM pg_shadow; --. When Budibase attempts to connect, it triggers SET search_path. The database driver executes this as two separate queries, creating the pwned table and populating it with user credentials.

For Microsoft SQL Server, the target must have xp_cmdshell enabled, or the database user must have sufficient privileges to enable it. The attacker injects the payload dbo'; EXEC xp_cmdshell('whoami'); -- into the Schema configuration field. During the subsequent metadata discovery loop, Budibase executes the command string, which triggers the stored procedure and runs arbitrary shell commands on the host machine.

The MySQL vector does not require direct control of Budibase configuration if Budibase can be enticed to connect to a malicious MySQL instance. The attacker sets up a MySQL database containing a table named foo; DROP TABLE users; --. When the Budibase server queries the table list during introspection, it stores this malformed table name. When the server later issues a DESCRIBEstatement using the unescaped table name, the nested query executes, resulting in the deletion of theusers` table.

The impact of these injection vulnerabilities is rated as High, with an overall CVSS score of 8.4. Because Budibase is a low-code platform designed to connect multiple business systems, a compromise of the database integrations can result in widespread lateral movement. An attacker can pivot from the low-code editor to critical backend data stores.

The confidentiality impact is high, as arbitrary SELECT commands can be injected to retrieve stored credentials, session tokens, and business-critical data. In PostgreSQL, accessing tables like pg_shadow or writing database data to external locations allows attackers to harvest database hashes. In MS SQL and MySQL, reading the system tables can expose the entire schema layout and other configuration settings.

The integrity and availability impacts are equally severe. Attackers can execute DDL and DML statements to alter, delete, or corrupt database tables. Commands such as DROP TABLE or TRUNCATE can cause complete data loss, while modification commands can insert rogue records or backdoors.

The scope metric is set to "Changed" because exploitation allows the attacker to step outside the security boundaries of the Budibase application itself. In MS SQL environments where xp_cmdshell is enabled, the database engine executes commands under the context of the SQL Server service account, potentially allowing full host OS takeover.

The primary and recommended remediation is to upgrade Budibase to version 3.39.19 or higher. This release integrates proper escaping for double quotes, single quotes, and backticks across all affected database connectors. If immediate patching is not possible, organizations should restrict administrative privileges in the Budibase platform. Since most of these vectors require altering connection schemas, minimizing the number of users with administrative access limits the attack surface.

Applying the principle of least privilege to database connection credentials serves as an important secondary defense. The database user accounts assigned to Budibase should only possess the permissions strictly required for application function. For example, disabling superuser privileges on PostgreSQL and disabling xp_cmdshell globally on Microsoft SQL Server prevents the execution of arbitrary system-level commands.

Network security controls can also help detect and block potential exploit attempts. Web Application Firewalls should monitor HTTP request payloads directed to /api/datasources for the presence of dynamic SQL injection characters, such as trailing double-quotes or unescaped single-quotes followed by SQL keywords. Implementing these defensive layers ensures that even if a connector is targeted, the blast radius of the attack is significantly reduced.