high · 7.6Jul 24, 2026

Budibase MySQL DESCRIBE Backtick Injection via multipleStatements

Shubham Kandhare
Security Engagement Manager, SecureLayer7

The Budibase MySQL connector lets a malicious table name break out of a DESCRIBE query and execute arbitrary SQL during routine schema discovery, because backticks in table names are never escaped…

Package@budibase/server
Ecosystemnpm
Affected<= 3.38.1
Budibase MySQL DESCRIBE Backtick Injection via multipleStatements

The problem

Budibase's MySQL integration hardcodes multipleStatements: true on every connection (packages/server/src/integrations/mysql.ts, line 172). During schema introspection it builds a DESCRIBE query by directly interpolating the table name into a backtick-quoted identifier with no escaping (line 305).

An attacker who can create a table in the target database names it to contain a closing backtick followed by a semicolon and a second SQL statement. When any Budibase administrator opens or refreshes that datasource, the malicious table name is read from INFORMATION_SCHEMA.TABLES and injected verbatim into the query.

The second statement executes in the same round trip. The attacker does not need to touch Budibase at all, only the underlying database.

Proof of concept

A working proof-of-concept for this issue in @budibase/server, with the exact payload below.

sql
-- Step 1: attacker creates this table in the MySQL database
CREATE TABLE `foo\`; DROP TABLE users; -- ` (id INT);

-- Step 2: Budibase introspection builds and executes:
DESCRIBE `foo`; DROP TABLE users; -- `;

The root cause is two cooperating decisions: multipleStatements: true is set unconditionally on the connection config, and table names sourced from INFORMATION_SCHEMA are string-interpolated into a backtick-delimited identifier without doubling embedded backticks.

MySQL's identifier quoting rule is that a backtick inside a backtick-quoted name must be escaped as two consecutive backticks (` `). Because Budibase skips that step, an attacker-controlled backtick in the table name immediately closes the identifier, and the rest of the name becomes raw SQL.

With multipleStatements enabled, the injected statement after the semicolon fires in the same connection round trip.

The patch (commit 2c61f389, PR #18989) sanitizes tableName before interpolation by replacing every backtick with a doubled backtick, and separately removes multipleStatements: true from the default connection config so the attack surface is eliminated at both layers.

CWE-89.

The fix

Upgrade @budibase/server to 3.39.18 or later. The fix in commit 2c61f389c9986c91ddd8ae161c2b5e8ec21c60ac applies two independent controls: embedded backticks in table names are now doubled before interpolation into DESCRIBE, and multipleStatements is no longer enabled by default on MySQL connections.

Reporter not attributed.

References: [1][2][3][4][5]

Related research