DBHub provides a machine‑to‑machine administration interface for several database engines. When the server is started with HTTP transport, an unauthenticated MCP endpoint is exposed. The server attempts to mitigate browser‑origin access by comparing the Origin and Host headers and echoing the validation into the Access‑Control‑Allow‑Origin header. However, this check does not stop DNS rebinding; an attacker can cause a victim’s browser to send requests to DBHub with both headers containing an attacker‑controlled hostname. The server then accepts the request and dispatches the requested MCP tool, allowing the attacker’s webpage to execute arbitrary SQL statements without authentication or prompts. In the default demo configuration this permits reading and writing the demo SQLite database; in normal installations the same mechanism can read, enumerate, and potentially modify any configured database depending on granted tool permissions and credentials. The flaw arises from missing authentication checks (CWE‑306) and inadequate split‑brain protection (CWE‑346).

Bytebase DBHub version 0.22.5 and earlier when launched with the --transport http flag, exposing the HTTP port (such as 8080). The vulnerability applies to all supported database engines – Postgres, MySQL, SQL Server, Oracle, MariaDB, and SQLite – as long as the HTTP transport mode is enabled.

The CVSS score of 9.3 indicates high severity. Attackers need only control a DNS hostname that rebinds to the DBHub instance and access to the victim’s browser that can reach the exposed HTTP port. No credentials are required; the exploit is deterministic and straightforward. Because the vulnerability is not yet listed in the CISA KEV catalog, the business impact remains undetermined, but the potential for data theft, modification, or privilege escalation at the database level is significant. EPSS score: not available.