Read-only mode in DBHub database MCP server can be bypassed

A flaw in DBHub, an open-source database connector for AI assistants built by Bytebase, allowed attackers to run write and destructive commands against databases that were supposed to be in read-only mode. The issue, tracked as CVE-2026-61789, affects every version before 0.22.6 and was published to the US National Vulnerability Database on 30 October 2026.

DBHub is an MCP server, meaning a piece of software that exposes tools to an AI assistant using the Model Context Protocol. It supports Postgres, MySQL, SQL Server, Oracle, MariaDB and SQLite. Its read-only mode is meant to be a guardrail: the assistant can query data but not change it.

According to the advisory, that guardrail could be defeated on the MySQL and MariaDB connectors because of a disagreement between DBHub's SQL parser and the databases themselves. DBHub's parser, in a function that scans for single-line comments, treats every double dash as the start of a comment. MySQL and MariaDB are stricter: they only treat a double dash as a comment if it is followed by whitespace, a control character or the end of the line.

That gap matters because of how the two halves of DBHub handle a submitted query. The read-only check splits the input into statements and validates each one. The MySQL and MariaDB connectors, however, hand the original unsplit string to the database with the multiple-statements option switched on. A double dash followed immediately by a non-whitespace character therefore looks like a comment to the validator, which ignores everything after it, while the database reads the dashes as two minus operators and goes on to execute the statement that follows.

The practical result, the advisory says, is that anyone able to influence the SQL the assistant sends can slip a write or a destructive schema change past the check. That includes prompt injection, where malicious instructions are planted in content the assistant reads, such as a document, a web page or a database row. The damage is limited only by the privileges of the database account DBHub is configured with. The advisory states the bypass can be used to modify or drop database data.

PostgreSQL is not affected through this route. The advisory explains that Postgres parses double dashes the same way DBHub's checker does, and its connector executes split statements individually rather than passing the original string through.

The issue is fixed in DBHub 0.22.6. The fix was delivered through a pull request and commit on the project's GitHub repository, and the advisory was published by the project under the GitHub Security Advisory identifier GHSA-j656-3hf2-fvjc. Users on earlier versions who connect DBHub to MySQL or MariaDB should upgrade.

The case is a reminder of a pattern that keeps recurring in agent tooling: a safety check and the system it protects must parse input identically. If the validator and the executor read the same string differently, the check becomes advisory rather than enforced. It also shows the value of least-privilege database accounts, since the advisory notes the impact is bounded by what the connecting account is permitted to do.