CVE-2026-61789: DBHub MCP server's read-only mode can be bypassed on MySQL and MariaDB, upgrade to 0.22.6
DBHub, Bytebase's database MCP server, misreads double dashes when checking SQL in read-only mode before 0.22.6. On MySQL and MariaDB, a double dash followed by a non-space character can hide a write or DROP statement that the database then runs, so anyone who can steer the assistant's SQL, including through prompt injection, can change or drop data. PostgreSQL isn't affected.
What it is
scanSingleLineComment in src/utils/sql-parser.ts treats every -- as a comment, but MySQL and MariaDB only do so when it is followed by whitespace, a control character or the end of the line (CWE-436).
The read-only check validates the split statements, while the MySQL and MariaDB connectors run the original string with multipleStatements enabled.
A -- followed by a non-space character can hide a write or DDL statement from the validator, and the database runs it as a minus operator plus a second statement.
Impact is limited by the database account's own privileges.
How to check
- Check the DBHub version in your MCP config (npx @bytebase/dbhub or the Docker image). Before 0.22.6 is affected.
- Check whether you rely on its read-only mode with a MySQL or MariaDB connection.
How to fix
- Upgrade DBHub to 0.22.6 or later.
- Connect DBHub with a database user that only has read permissions, so read-only doesn't depend on the SQL checker.
Sources
- criticalCVE-2026-62863: any web page can drive the MoLing computer-use MCP server in SSE mode, upgrade to 0.5.0
- criticalCVE-2026-93680 and CVE-2026-110186: IBM fixes a 9.8 authentication bypass and unauthenticated code execution in Langflow up to 1.12.8, upgrade to 1.13.0
- criticalCVE-2026-104339 and 30 more: IBM's Langflow 1.12.4 and 1.12.5 bulletins fix unauthenticated RCE, three 9.9 code execution bugs, SSRF and path traversal
- criticalCVE-2026-114612: LiteLLM proxy lets an internal user forge an admin token and run commands