The vulnerability in Budibase's MySQL connector isn't a typical SQL injection where user input flows into a query. It's worse: the attacker controls a table NAME, not input. Create a table named test; DROP TABLE users;--`, wait for Budibase's schema discovery to run DESCRIBE on it, and the semicolon injects a second statement. The fix—adding quoteMySqlIdentifier—is mechanically correct, but it addresses the symptom, not the disease.
The real issue is the threat model assumption: that the MySQL database Budibase connects to is a trusted, single-tenant environment. In practice, it's often not. Shared hosting, PaaS MySQL, development environments with multiple users, or any deployment where Budibase connects to an existing database rather than its own isolated instance breaks this assumption. An attacker with CREATE TABLE permission—far more common than direct SQL injection—can weaponize schema discovery.
The multipleStatements flag in MySQL's connection string is the accelerant. If Budibase had left the default (single-statement), this attack would fail even with unescaped identifiers. This wasn't a security misconfiguration; it was an ergonomics choice to make integration