CVE-2026-100683: Budibase before 3.45.0 SQL Injection via column-rename DDL
Budibase (@budibase/server) before 3.45.0 builds MySQL and MSSQL column-rename DDL in packages/backend-core/src/sql/sqlTable.ts by interpolating identifiers directly into a raw query string (backtick-quoted for MySQL, a single-quoted sprename literal for MSSQL) without applying the project's quoteMySqlIdentifier / quoteSqlServerIdentifier helpers. An attacker with DDL rights on a connected MySQL/MSSQL datasource can create a column whose name contains a backtick (MySQL) or single quote (MSSQL) plus additional SQL; Budibase's schema introspection stores the name verbatim, and when a Budibase builder later renames that column through the UI (POST /api/tables with rename.old), the embedded quote character terminates the identifier and the injected SQL is executed. Because the MySQL connection is opened with multipleStatements: true, stacked statements run as Budibase's datasource user, allowing arbitrary reads, writes, or destructive operations on the connected database outside Budibase's row/table permission model. Fixed in 3.45.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@budibase/serverto a version that resolves this vulnerability.Fixed in 3.45.0
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Budibase deployments before 3.45.0 are exposed when they use a connected MySQL or MSSQL datasource and an attacker has DDL rights on that datasource. Exploitation also requires a Budibase builder to rename the attacker-created column through the UI.
What access and interaction are required to exploit it?
The attacker must be able to create a column with a crafted name containing a backtick on MySQL or a single quote on MSSQL. A builder must then submit a column rename through POST /api/tables using _rename.old, causing Budibase to build and execute the unsafe DDL.
What is the impact if exploitation succeeds?
Injected SQL executes using Budibase's datasource database user. For MySQL, stacked statements can run because the connection enables multipleStatements, allowing arbitrary reads, writes, or destructive database operations outside Budibase's row and table permission model.
How can administrators mitigate the issue if they cannot upgrade immediately?
Remove or tightly restrict DDL privileges for untrusted users on connected MySQL and MSSQL datasources. Avoid renaming columns through the Budibase UI when datasource schemas may contain attacker-controlled column names.
How can I identify a potentially affected deployment?
Check whether @budibase/server is earlier than 3.45.0 and whether it connects to MySQL or MSSQL. Review datasource schemas for column names containing backticks on MySQL or single quotes on MSSQL, especially where those names could have been created by users with DDL access.