Summary
Budibase constructs MySQL and MSSQL column-renaming statements by directly interpolating column names into raw SQL without applying identifier-quoting helpers. If an attacker can create a specially named column and a Budibase builder later renames it, injected SQL may execute with the datasource user's privileges.
Affected context
The vulnerability occurs in Budibase deployments that connect to MySQL or MSSQL datasources and support column renaming through the builder interface. It requires a column name containing a quote character that is retained by schema introspection, followed by a rename operation involving that column. MySQL deployments using multiple-statement connections have a broader impact because additional statements may be processed in the same request.
Exploit preconditions
- Attack surface: Budibase datasource schema-management and column-rename
functionality
- Required access: DDL rights on the connected MySQL or MSSQL datasource, or
another trusted path capable of creating a suitably named column
- Trigger point: A builder user or workflow renames the affected column
through the Budibase API or interface
- Why exploitation is possible: The column name is inserted into a raw DDL
statement without context-appropriate identifier quoting, allowing a quote
character to terminate the intended identifier or literal
Why this happens
The underlying bug is SQL injection caused by treating schema-derived identifiers as trusted SQL text. The column-rename implementation omits the project's database-specific identifier-quoting helpers and directly interpolates names into MySQL and MSSQL statements. A quote within a stored column name can therefore change the structure of the generated query, which maps to CWE-89.
Potential impact
- An attacker may read data accessible to the datasource user.
- An attacker may alter or delete database records.
- An attacker may create, modify, or remove database objects where privileges allow.
- MySQL deployments may permit stacked statements when multiple statements are enabled.
- The Budibase row and table permission model may be bypassed for database actions performed through the datasource account.
General mitigation guidance
Mitigation focuses on separating identifiers from SQL syntax and reducing trust in schema-derived names. Column names should be passed through database-specific, allowlisted identifier-quoting routines rather than interpolated into raw queries, while values should use parameterized statements. Schema operations can also enforce strict identifier policies, minimize or disable multiple-statement execution where it is unnecessary, and use datasource accounts with only the DDL and data privileges required. Additional controls may include validating names at ingestion and limiting which identities can perform schema changes.
How teams detect issues like this
Detection can include static-analysis rules for string interpolation in SQL construction, especially where identifiers are assembled into DDL. Code review should flag raw query paths that omit database-specific quoting helpers, enable multiple statements, or use schema metadata without validation. Dynamic testing can exercise quote-containing identifiers in isolated datasources and verify that generated statements remain a single intended operation. CI policy checks and automated code-review tools may help enforce parameterization and identifier-handling standards.
