Description

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 sp_rename 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.0",
  "pubDate": "2026-09-26T14:16:52.567Z",
  "pubdate": "2026-09-26T14:16:52.567Z",
  "executiveSummary": "A critical SQL injection vulnerability exists in Budibase (@budibase/server) versions prior to 3.45.0, specifically within the column renaming DDL generation process. The flaw arises from improper sanitization of database identifiers during schema modification operations.\nThe vulnerability allows an authenticated attacker with DDL permissions on a connected MySQL or MSSQL datasource to execute arbitrary SQL commands. By crafting a malicious column name containing delimiter characters (backticks for MySQL or single quotes for MSSQL), an attacker can escape the identifier context and inject malicious SQL statements.\nBecause the MySQL driver is configured with multipleStatements: true, the injected payload can include stacked queries, resulting in full control over the connected database. This bypasses Budibase's internal row and table-level access controls, potentially leading to unauthorized data extraction, modification, or destructive operations. The impact is significant, as it grants the attacker the same database privileges as the service account configured for the Budibase datasource connection.",
  "technicalDetails": "The vulnerability resides in packages/backend-core/src/sql/sqlTable.ts, where the application constructs DDL statements for column renaming operations. The root cause is the failure to utilize established security helpers—quoteMySqlIdentifier and quoteSqlServerIdentifier—when processing user-provided column names. Instead, the application performs direct interpolation of identifiers into raw SQL query strings.\nThe attack flow begins with an attacker exploiting the application's schema introspection mechanism. Since Budibase stores column names verbatim, an attacker with DDL rights can define a column with a malicious name string. For MySQL, this payload incorporates backtick characters (`) to terminate the intended identifier context, while for MSSQL, the payload uses single quotes (') to break out of the sp_rename literal string.\nWhen a user triggers a column rename operation via the POST /api/tables endpoint, the backend processes the old column name (_rename.old) without adequate escaping. The injected SQL characters break the intended SQL structure, allowing the execution of arbitrary, stacked queries. In the case of MySQL, the server configuration enables the multipleStatements: true flag, facilitating the execution of secondary, malicious queries appended to the legitimate DDL command.\nThis vulnerability is restricted to environments where the attacker possesses sufficient privileges to create columns on the connected datasource. Once triggered, the injected queries execute under the security context of the Budibase datasource user. Consequently, the attacker can perform operations far exceeding the intended scope of Budibase's application-layer permission model, including reading sensitive configuration tables, modifying arbitrary data, or dropping database objects, effectively resulting in full database compromise."
}