Two flaws in Bytebase's DBHub database MCP server disclosed

Two security advisories published on 24 September 2026 describe critical weaknesses in DBHub, an open-source database MCP server from Bytebase that connects AI agents to Postgres, MySQL, SQL Server, Oracle, MariaDB and SQLite. Both issues are fixed in version 0.22.5, according to the National Vulnerability Database entry for the first flaw.

The first issue, tracked as CVE-2026-61742, concerns DBHub's HTTP transport mode. According to the GitHub advisory, starting DBHub with the documented --transport http --port 8080 option exposes an MCP endpoint with no authentication. The server tries to protect itself from browser-based attacks by comparing the hostname in the Origin header with the hostname in the Host header, rejecting the request only when the two differ. The advisory says this equality check does not stop DNS rebinding, a technique where an attacker-controlled domain name is first pointed at the attacker's own server and then re-pointed at an address the victim can reach.

Once rebinding happens, both headers contain the same attacker-controlled hostname, so DBHub accepts the request and runs MCP tool calls. The researcher who reported it notes that this means a malicious website can invoke DBHub's tools directly from the victim's browser "without prompt injection or model involvement" — no AI model needs to be tricked. With the default demo configuration, the advisory says this allows reading and writing the demo SQLite database; against a real configured database it can read, enumerate and potentially write data, depending on the tool permissions and database credentials in use. The reporter recommended a severity of High, rising to Critical when HTTP transport is wired to production or broadly privileged credentials. Version 0.21.2 was the version tested.

The second advisory, CVE-2026-61788, says DBHub's read-only mode does not work. Setting readonly = true on the execute_sql tool is meant to put the connection into a read-only state, but according to the advisory the code that would apply that setting — including PostgreSQL's default_transaction_read_only option and SQLite's read-only open mode — is gated on a configuration value that is never populated. The TOML config loader rejects a source-level readonly field, and the --readonly command line flag was removed, so the check is always false and the database-level protection never runs.

That leaves only a classifier that inspects the first keyword of each SQL statement. The advisory says any SELECT that writes through a function call passes it. Examples given include setval to tamper with sequences using an ordinary role, and, with a privileged role, lo_export to write files on the server, pg_read_file to read host files such as /etc/passwd, and dblink_exec combined with COPY ... TO PROGRAM to run shell commands. The advisory says the project's own read-only test suite covers none of these cases.

The second issue affects all released versions up to and including 0.22.2, on both stdio and HTTP transports, for PostgreSQL and SQLite. The advisory notes the HTTP transport is unauthenticated and binds to 0.0.0.0 by default, so the flaw is reachable by any network caller of the /mcp endpoint, a malicious MCP client, or untrusted content that reaches an agent through prompt injection. The reporter's suggested fixes include binding to loopback by default, adding explicit allowed-host and allowed-origin policies, and requiring an authentication token before dispatching JSON-RPC calls.