CVE-2026-100683 in server
Summary
by MITRE • 09/26/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified involves a critical SQL injection flaw within the Budibase application platform, specifically affecting versions prior to 3.45.0. This security issue stems from improper handling of database identifiers during Data Definition Language operations for MySQL and Microsoft SQL Server datasources. The root cause lies in the file packages/backend-core/src/sql/sqlTable.ts, where column rename commands are constructed by directly interpolating user-supplied or schema-derived identifier strings into raw query statements. For MySQL connections, these identifiers are wrapped in backticks, while MSSQL uses single quotes within sp_rename literals. Crucially, this process bypasses the application's designated sanitization functions, quoteMySqlIdentifier and quoteSqlServerIdentifier, which are designed to escape special characters that could break out of identifier contexts. This oversight creates a pathway for attackers who possess Data Definition Language privileges on an integrated database to inject malicious SQL code through carefully crafted column names.
The exploitation mechanism relies on the attacker creating a table or modifying existing structures to include a column name containing specific delimiters, such as a backtick in MySQL or a single quote in MSSQL, followed by additional SQL syntax. When this tainted schema information is stored verbatim during Budibase's introspection phase, it remains unescaped within the application's internal state. The vulnerability triggers when an administrator or user with sufficient privileges attempts to rename this column via the web interface using the POST /api/tables endpoint with the _rename.old parameter. At this point, the system constructs a new DDL statement by combining the stored identifier with the new name. Because the original identifier contained unescaped delimiters, it terminates the intended string context and allows the injected SQL payload to execute as part of the same query batch or subsequent statements.
The operational impact of this vulnerability is severe due to the configuration of the database connections used by Budibase. Specifically, MySQL connections are established with the multipleStatements option enabled, which permits the execution of stacked queries within a single command string. This setting allows an attacker not only to manipulate the schema but also to execute arbitrary SQL commands against the connected database using the privileges of the datasource user account. Consequently, this can lead to unauthorized data exfiltration, modification or deletion of critical records, and potentially further compromise of the underlying infrastructure if the database user has elevated permissions beyond those required for normal application operation. The vulnerability effectively bypasses Budibase's row-level and table-level permission models because the injection occurs at the database driver level before these application-layer security controls can be applied to individual data rows or tables.
This flaw aligns with CWE-89, which classifies Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. Furthermore, from a tactical perspective related to the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Data Manipulation and potentially Credential Access if sensitive data is exfiltrated through stacked queries. The ability to execute arbitrary commands via stacked statements also touches upon aspects of Defense Evasion by bypassing application-level access controls. To mitigate this risk, organizations running Budibase must upgrade immediately to version 3.45.0 or later, where the issue has been resolved by ensuring that all database identifiers are properly sanitized using the appropriate quoting helpers before being embedded in SQL statements. Additionally, it is recommended to review datasource configurations and disable multipleStatements for MySQL connections if stacked queries are not strictly required for application functionality, thereby reducing the attack surface even further.