GHSA-j656-3hf2-fvjc: DBHub: read-only bypass via MySQL comment parsing

The read-only mode can be bypassed on the MySQL and MariaDB connectors. In read-only mode a caller can still execute arbitrary write and DDL statements (for example DROP TABLE), which defeats the protection that read-only mode is meant to provide when a database is exposed to an AI agent. Root cause The problem is a mismatch between how DBHub's SQL parser handles single-line comments and how MySQL and MariaDB actually parse them. In src/utils/sql-parser.ts, scanSingleLineComment treats "--" as the start of a comment no matter what character follows it. MySQL and MariaDB only begin a "--" comment when the two dashes are followed by whitespace, a control character, or the end of the line. Otherwise the dashes are read as two minus signs and the rest of the line is ordinary SQL. The read-only check in src/tools/execute-sql.ts splits the input and validates each statement with isReadOnlySQL, but the connector then executes the original, unmodified string. The MySQL and MariaDB connectors open their connection pool with multipleStatements: true (src/connectors/mysql/index.ts:54 and src/connectors/mariadb/index.ts:53) and run the whole string in a single call. Because of this, the following payload: SELECT 1--1;DROP TABLE victim is seen by DBHub as a single SELECT statement, since everything after "--" is treated as a comment and the read-only check passes. MySQL and MariaDB instead parse it as "SELECT 1 - -1" followed by "DROP TABLE victim" and execute both statements. Proof of concept 1) DBHub's own parser. Running splitSQLStatements and isReadOnlySQL from this repository on the payload returns a single statement and readOnly = true, so the query is allowed in read-only mode. The same code correctly rejects "SELECT 1; DROP TABLE victim", which confirms that the "--1" is what gets through. 2) Execution. Connecting to MariaDB 11.4 with mysql2 and multipleStatements: true (the same option the connector uses) and sending the payload returns 2 for the first statement, which confirms "--" was not treated as a comment, and then drops the table. The table exists before the call and is gone afterwards. Impact Read-only mode is the control operators rely on to let an assistant read from a database without being able to change it. With this bypass, anyone who can influence the SQL the assistant sends, most realistically through prompt injection in content the assistant reads, can perform writes and destructive DDL against MySQL and MariaDB. PostgreSQL is not affected by this path, because it treats "--" as a comment regardless and executes each split statement individually. Affected code (current main, commit e99c3aa9, package version 0.22.3) - src/utils/sql-parser.ts — scanSingleLineComment does not require whitespace after "--" - src/tools/execute-sql.ts — validates the split statements but executes the original string - src/connectors/mysql/index.ts and src/connectors/mariadb/index.ts — multipleStatements: true Suggested fix The most reliable fix is to stop executing the original string: run only the statements that were validated, and disable multipleStatements on the MySQL and MariaDB connections unless it is genuinely required. As defense in depth, make the comment scanner dialect-aware so that for MySQL and MariaDB "--" only starts a comment when it is followed by whitespace, a control character, or the end of the line, similar to the handling already in place for MySQL conditional comments.

An attacker plants a hidden instruction in a support ticket or web page that a database-connected assistant later reads. The instruction makes the agent run a query such as "SELECT 1--1;DROP TABLE customers" through DBHub. DBHub's parser sees one harmless SELECT and allows it in read-only mode, while MariaDB parses "--1" as arithmetic and executes the DROP TABLE as a second statement. The attacker has destroyed or altered production data without any direct database access.